SOLVED - White Screen of Death (Revo 2.2.2 through 2.2.4) - unknown cause

Hey all - I recently installed MODX 2.2.2 onto a Network Solutions server, and the install was completely successful. I spend an entire day putting together the backend for the site with no issues whatsoever. I set up Friendly URLS and disabled Register Globals via the php.ini file. I was able to use the manager and see the front end of the site with no issue whatsoever. However, the next morning I came back into the office and attempted to log into the manager, and I saw (and continue to see) the white screen of death. The same screen greets me on the front end.

I have tried emptying the cache manually (in core/cache), removing the Registered Globals setting, removing the .htaccess file that enables Friendly URLS, and a number of other things. I am completely in the dark as to what could have caused this - does anyone have ANY suggestions? I would love to not lose an entire days work if I can avoid it. [ed. note: designcouch last edited this post 14 years, 2 months ago.]

Odd, but upgrading to Revo 2.2.3 fixed the issue. Marking this one solved (for now), but would have loved to know the cause.

*BUMP*

Hey everyone. This problem has re-surfaced, and I am actually using MODX 2.2.4-pl now. It seems that randomly, the site ceases to function and I get a WSOD. I say randomly, as it happens when I haven't been touching the site for a few days, and affects both the front and backend. The only thing that solves the issue is a re-install of the entire MODX package over the existing one.

Does anyone have any issues or thoughts as to how in the world I can keep this from continuing to happen? Pretty please?

Any information from your MODX or environment error logs would be helpful. Without more information, it's going to be very difficult to diagnose the issue you are experiencing.

Jason,

I can give you the entire MODX error log below - but in my limited understanding, I don't see anything that could bring down the entire site (front and back end) in there. Especially since the error is happening when the site is not being touched. Perhaps you can? Also, I'm including all details pertinent to this site that I can think of. If you think it could be of help, I can include any other requested data.

Host: Network Solutions
PHP Version: 5.3.8
Server OS: Linux

MODX Error Log:

[2012-07-02 15:56:02] (ERROR @ /assets/components/bigbrother/connector.php) Error caching lexicon topic lexicon/en/bigbrother/mgr
[2012-07-02 15:56:02] (ERROR @ /assets/components/bigbrother/connector.php) Error caching lexicon topic lexicon/en/bigbrother/mgr
[2012-07-02 16:15:03] (ERROR @ /connectors/workspace/packages.php) MODX could not download the file. You must enable allow_url_fopen, cURL or fsockopen to use remote transport packaging.
[2012-07-02 16:15:03] (ERROR @ /connectors/workspace/packages.php) Could not transfer package archivist-1.2.3-pl.transport.zip to /data/18/1/98/7/1587985/user/1710850/htdocs/dev/core/packages/.
[2012-07-03 15:11:26] (ERROR @ /connectors/element/template.php) Error caching lexicon topic lexicon/en/core/template
[2012-07-03 15:29:40] (ERROR @ /index.php) `url~` is not a valid integer and may not be passed to makeUrl()
[2012-07-03 15:29:43] (ERROR @ /index.php) `url~` is not a valid integer and may not be passed to makeUrl()
[2012-07-03 15:30:19] (ERROR @ /index.php) `id` is not a valid integer and may not be passed to makeUrl()
[2012-07-03 15:30:22] (ERROR @ /index.php) `id` is not a valid integer and may not be passed to makeUrl()
[2012-07-03 15:30:43] (ERROR @ /index.php) `[[+id]]` is not a valid integer and may not be passed to makeUrl()
[2012-07-03 15:30:50] (ERROR @ /index.php) `[[+id]]` is not a valid integer and may not be passed to makeUrl()
[2012-07-03 17:06:01] (ERROR @ /connectors/resource/index.php) Error caching lexicon topic lexicon/en/core/resource
[2012-07-03 17:26:57] (ERROR @ /assets/components/bigbrother/connector.php) Error caching lexicon topic lexicon/en/bigbrother/mgr
[2012-07-04 15:22:11] (ERROR @ /assets/components/mxcalendars/connector.php) Could not load class: categoryid from mysql.categoryid.
[2012-07-04 15:22:23] (ERROR @ /assets/components/mxcalendars/connector.php) Could not load class: categoryid from mysql.categoryid.
[2012-07-04 15:22:23] (ERROR @ /assets/components/mxcalendars/connector.php) Could not load class: categoryid from mysql.categoryid.
[2012-07-04 15:23:56] (ERROR @ /assets/components/mxcalendars/connector.php) Could not load class: categoryid from mysql.categoryid.
[2012-07-04 15:27:17] (ERROR @ /assets/components/mxcalendars/connector.php) Could not load class: categoryid from mysql.categoryid.
[2012-07-05 09:59:50] (ERROR @ /assets/components/bigbrother/connector.php) Error caching lexicon topic lexicon/en/bigbrother/mgr
[2012-07-05 09:59:50] (ERROR @ /assets/components/bigbrother/connector.php) Error caching lexicon topic lexicon/en/bigbrother/mgr
[2012-07-05 10:00:13] (ERROR @ /connectors/workspace/packages.php) MODX could not download the file. You must enable allow_url_fopen, cURL or fsockopen to use remote transport packaging.
[2012-07-05 10:00:13] (ERROR @ /connectors/workspace/packages.php) Could not transfer package archivist-1.2.3-pl.transport.zip to /data/18/1/98/7/1587985/user/1710850/htdocs/dev/core/packages/.
[2012-07-05 10:00:30] (ERROR @ /connectors/workspace/packages.php) MODX could not download the file. You must enable allow_url_fopen, cURL or fsockopen to use remote transport packaging.
[2012-07-05 10:00:30] (ERROR @ /connectors/workspace/packages.php) Could not transfer package quip-2.3.1-pl.transport.zip to /data/18/1/98/7/1587985/user/1710850/htdocs/dev/core/packages/.
[2012-07-05 10:00:30] (ERROR @ /connectors/workspace/packages.php) MODX could not download the file. You must enable allow_url_fopen, cURL or fsockopen to use remote transport packaging.
[2012-07-05 10:00:30] (ERROR @ /connectors/workspace/packages.php) Could not transfer package taglister-1.1.7-pl.transport.zip to /data/18/1/98/7/1587985/user/1710850/htdocs/dev/core/packages/.
[2012-07-05 10:00:49] (ERROR @ /connectors/workspace/packages.php) MODX could not download the file. You must enable allow_url_fopen, cURL or fsockopen to use remote transport packaging.
[2012-07-05 10:00:49] (ERROR @ /connectors/workspace/packages.php) Could not transfer package archivist-1.2.3-pl.transport.zip to /data/18/1/98/7/1587985/user/1710850/htdocs/dev/core/packages/.
[2012-07-05 10:01:15] (ERROR @ /connectors/workspace/packages.php) MODX could not download the file. You must enable allow_url_fopen, cURL or fsockopen to use remote transport packaging.
[2012-07-05 10:01:15] (ERROR @ /connectors/workspace/packages.php) Could not transfer package archivist-1.2.3-pl.transport.zip to /data/18/1/98/7/1587985/user/1710850/htdocs/dev/core/packages/.
[2012-07-05 10:02:46] (ERROR @ /connectors/workspace/packages.php) MODX could not download the file. You must enable allow_url_fopen, cURL or fsockopen to use remote transport packaging.
[2012-07-05 10:02:46] (ERROR @ /connectors/workspace/packages.php) Could not transfer package archivist-1.2.3-pl.transport.zip to /data/18/1/98/7/1587985/user/1710850/htdocs/dev/core/packages/.
[2012-07-05 11:32:03] (ERROR @ /connectors/workspace/packages.php) MODX could not download the file. You must enable allow_url_fopen, cURL or fsockopen to use remote transport packaging.
[2012-07-05 11:32:03] (ERROR @ /connectors/workspace/packages.php) Could not transfer package archivist-1.2.3-pl.transport.zip to /data/18/1/98/7/1587985/user/1710850/htdocs/dev/core/packages/.

I would start by disabling everything related to bigbrother and mxcalendar, as the errors reveal some significant problems with those extras.

Jason,

I'm using both of those addons on another site with none of the errors that I'm seeing here, and definitely no WSOD. It's really odd, as the setup of the two sites is VERY similar (the main differences are the hosting provider and the MODX version). Also, the client requires that I use a calendar on the site, so mxcalendar needs to stay. It drives a lot of the content on their site.

Does the WSOD go away when you manually delete all files in the core/cache directory?

Also, in my experience, the WSOD is most often caused by a plugin with an error in it. If E_NOTICE is on, newer versions of PHP will throw an E_NOTICE warning every time an undefined array index is referenced, which is fairly common in the code of many extras. That seems to crash MODX (though it probably shouldn't). The sites where it's working may have E_NOTICE off.

One way of diagnosing things is to temporarily set the 'disabled' field of plugins, one at a time, in the modx_plugins table and see if the problem goes away.


Also, looking at your error log, another possible explanation might be that the host has implemented suPHP or something similar and you need to change the permissions on the core/cache directory (and maybe other directories as well).




------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html [ed. note: BobRay last edited this post 14 years, 2 months ago.]

Thank you everyone for your help. I have FINALLY figured out the cause. The site that I have been having issues with is in a non-published development environment, so I had no way of seeing the issue, but here's what it was:

The client I am working for was really worked over by their previous web agency, and said agency was HORRIBLE at coding good, secure sites. They set up all accounts (hosting, Joomla admin etc) with laughably insecure usernames and passwords, and as such, their existing live site was compromised last month. The perpetrator gained access to the root level of the site, which in turn gave them access to not only the live site, but also my development site. They were inserting a base64 script into each PHP file that affected search engine users. Since my development site had no Search Engine visitors, the only effect that I saw was the confusing WSOD (since their inserted code caused an issue with the functioning of the MODX php files).

I am in the middle of cleaning all of this up, but I just wanted everyone to know that this was NOT a MODX issue.