2

I have migrated a site from:

  • Unknown OS (Was through BlueHost)
  • cPanel 11.52.6 (build 1)
  • Apache (v. 2.2.31)
  • PHP (v. 5.2.17)
  • MySQL (v. 5.5.42-37.1)
  • WordPress (v. 4.5.3)
  • CiviCRM (v. 4.6.9)

To:

  • CentOS release 6.8
  • cPanel 56.0 (build 25)
  • Apache (v. 2.4.18)
  • PHP (v. 5.6.22)
  • MySQL (v. 5.6.30)
  • WordPress (v. 4.5.3)
  • CiviCRM (v. 4.6.19)

I have followed the documentation found at https://wiki.civicrm.org/confluence/display/CRMDOC/Moving+an+Existing+Installation+to+a+New+Server+or+Location and have managed to get CiviCRM to run but with a hiccup. The initial loading of the CiviCRM dashboard takes a very long time, sometimes 5+ minutes, but after the initial load everything is incredibly fast and flawless. Seems to happen only when it is trying to establish a new session as if I clear cache and try to get back to the CiviCRM dashboard it reproduces the issue but the issue will not reproduce as long as the session isn't reset like logging out or clearing cache. I have also noticed that if you sit and let it load that the dashlets then will not load and just shows the spinning loading image and never actually loads but I am guessing these two issues are related.

I have also followed the recommendations found here: civicrm dashboard won't load and have not been able to fix it.

Also I have tried many things like clearing the cache, deleting CiviCRM and re-installing then importing the database and then using the CiviCRM database update utility and seems like nothing is solving the issue.

Snooping around in the Apache, PHP, MySQL, & CiviCRM log files I found only one error being reported that I know is related to the dashboard hanging at public_html/wp-content/plugins/files/civicrm/ConfigAndLog/ here is the pastebin: http://pastebin.com/TRTg0sHx

I feel as if I have tried everything and am out of ideas, any help as what to do to get this resolved would be greatly appreciated.

EDIT: Ignore "UPDATE (7/12/2016)", found out that this was a separate issue, sorry for the confusion.

UPDATE (7/12/2016): Decided to try a fresh cPanel account, fresh WordPress, and fresh CiviCRM installtion and only running the bare basics to see if the problem would still exist and it does. But on the new install these errors come up:

Warning: session_start(): open(/tmp/sess_c279ba138c878520b23fb7085f54a267, O_RDWR) failed: Permission denied (13) in /home/civicrmtest/public_html/wp-content/plugins/civicrm/civicrm.php on line 282

Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /home/civicrmtest/public_html/wp-content/plugins/civicrm/civicrm.php:282) in /home/civicrmtest/public_html/wp-content/plugins/civicrm/civicrm.php on line 282

Warning: Cannot modify header information - headers already sent by (output started at /home/civicrmtest/public_html/wp-content/plugins/civicrm/civicrm.php:282) in /home/civicrmtest/public_html/wp-includes/option.php on line 823

Warning: Cannot modify header information - headers already sent by (output started at /home/civicrmtest/public_html/wp-content/plugins/civicrm/civicrm.php:282) in /home/civicrmtest/public_html/wp-includes/option.php on line 824

The first two errors above show and then the dashboard takes forever to load and then once the dashboard loads the last two errors display. Also the dashlets do not load properly afterwards and keep the "Loading..." message with the twirling image.

Improve this question
2
  • Your latest update is a separate question, and would be better posted as such. That said - lines 2-4 are caused by line 1 - your temp directory is set to /tmp and you apparently don't have permission to write there. I would take this up with your webhost!
    – Jon G - Megaphone Tech
    Commented Jul 12, 2016 at 18:35
  • I have been reading up on this and you absolutely correct, seems as if the permissions were actually correct but the /tmp was full, flushing the /tmp removed the error. Thank you for pointing this out! :-)
    – LJB
    Commented Jul 12, 2016 at 19:03

4 Answers 4

Reset to default
2

https://issues.civicrm.org/jira/browse/CRM-16035 has now been fixed. So your best solution now would be to upgrade to CiviCRM 4.7.11 which will include an improved dashboard that no longer depends on server-to-self http requests.

This upgrade will be released in about 2 weeks. The new dashboard features are sponsored by WMF.

Read more about the issue at https://issues.civicrm.org/jira/browse/CRM-17663

Improve this answer
4
  • Awesome, can't wait for the update! :-) Thank you for the help!!
    – LJB
    Commented Aug 12, 2016 at 20:20
  • Hello Coleman! I was able to finally resolve this issue. I found this small portion at the very bottom of wiki.civicrm.org/confluence/display/CRMDOC/… labelled Fire with NAT. Followed the instructions to edit the hosts file to point internal traffic going out to it's own domain to be redirected back to the internal IP and everything was automagically fixed! Thank you for all of your help, I appreciate it! :-)
    – LJB
    Commented Aug 26, 2016 at 19:57
  • @LJB, your link isn't complete - but for others searching for this solution: forum.civicrm.org/index.php?topic=34399.msg146033#msg146033
    – Jon G - Megaphone Tech
    Commented Aug 27, 2016 at 16:24
  • But also - just upgrade to 4.7.11 and this issue goes away!
    – Jon G - Megaphone Tech
    Commented Aug 27, 2016 at 16:24
2

I was able to finally resolve this issue.

I found this small portion at the very bottom of https://wiki.civicrm.org/confluence/display/CRMDOC/Installation+and+Configuration+Troubleshooting labelled Fire with NAT. Followed the instructions to edit the hosts file to point internal traffic going out to it's own domain to be redirected back to the internal IP and everything was automagically fixed! Thank you everyone for all your help, I appreciate it! :-)

Improve this answer
1

Try the following options and see if it solves the problem

  • Add your IP and domain to /etc/hosts file
  • Check if your firewall is blocking any AJAX calls
  • Check if any .htaccess file in any of the directories (mainly wp-admin directory) is blocking the AJAX call
Improve this answer
5
  • Hi, thanks for the suggestions. I have tried your three points and the issue still persists. I have added an update to my post with more information if you would like to try again! :-)
    – LJB
    Commented Jul 12, 2016 at 17:50
  • Have you recently disabled some dashlets? Is this happening to all users? or only to certain users? you can also use this sql statement to see dashlets in use: SELECT id, name, label, permission FROM civicrm_dashboard; It might also be that you have some civi components not enabled and the dashlet is loading
    – Kboy
    Commented Jul 12, 2016 at 20:18
  • @Kboy - There has not been any changes as far as dashlets being disabled. This is happening for all users on initial load of CiviCRM while it is trying to start a new session and the PHPSESSID cookie is not present. I have checked the Civi components and compared them to the current production site to the new migrated site and they are both running the same components. I have not tried your SQL query so I will try that. Thanks for the suggestion! :-)
    – LJB
    Commented Jul 14, 2016 at 14:20
  • @LJB, you can also try disabling the dashlets just by dragging them to the available Dashlets sections on the configure Dashboard after that re-enable one after another to find the problematic dashlet
    – Kboy
    Commented Jul 14, 2016 at 17:20
  • Hello Ghost! I was able to finally resolve this issue. I found this small portion at the very bottom of wiki.civicrm.org/confluence/display/CRMDOC/… labelled Fire with NAT. Followed the instructions to edit the hosts file to point internal traffic going out to it's own domain to be redirected back to the internal IP and everything was automagically fixed! Thank you for all of your help, I appreciate it! :-)
    – LJB
    Commented Aug 26, 2016 at 19:57
1

We had a similar (but not identical) issue with one of our sites - dashlets would spin for ages before eventually timing out. Occasionally we would get some loads but it was sporadic.

We followed the direction in https://issues.civicrm.org/jira/browse/CRM-16035 to increase the pm.max_children.

I have no idea if this will fix your issue but, as it sounds similar, I thought I might as well throw it in the mix! Apologies if it doesn't help!

Improve this answer
4
  • I'm not sure if I understand what I have to do to be honest. Is this for nginx or Apache? Or does it matter since this seems to a config for php.. This server with the issue uses Apache. I found my php-fpm.conf at /usr/local/cpanel/etc but I do not see a config line for pm.max_children so I am not sure if I am in the correct spot. Will you please elaborate if possible?
    – LJB
    Commented Jul 14, 2016 at 14:16
  • Ours are nginx servers so this may not help at all but it was /etc/php5/fpm/pool.d/www.conf not in the /usr/ directory. Hope it helps!
    – Matt Lind
    Commented Jul 15, 2016 at 15:34
  • Hello Matt Lind! I was able to finally resolve this issue. I found this small portion at the very bottom of wiki.civicrm.org/confluence/display/CRMDOC/… labelled Fire with NAT. Followed the instructions to edit the hosts file to point internal traffic going out to it's own domain to be redirected back to the internal IP and everything was automagically fixed! Thank you for all of your help, I appreciate it! :-)
    – LJB
    Commented Aug 26, 2016 at 19:57
  • Great to hear you got this resolved @LJB ! Would you be able to update your question with your solution? It will be easier for people to find the solution rather than hunting through these comments =)
    – Matt Lind
    Commented Sep 5, 2016 at 10:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.