11

I just migrated a site from the development server on MediaTemple (gs) to the production server on EngineHosting (shared). The front-end of the site displays fine (except some random images aren't displaying), but I get white-screen of death after logging-in to the control panel. My system folder is above web root and I'm using Focus Lab Master Config. Here's what I've tried so far:

  • I cleared the cache before migrating.
  • I've enabled debugging in config.env.php, index.php, and admin.php, but no errors display.
  • I've cleared my .htaccess file.
  • I checked that my cache folder has 777 permissions.

Not sure what else to try at this point, though I suspect Master Config is the culprit. Suggestions?

EE 2.5.3

UPDATE: After suggestions from @Tyssen and @jackmcpickle, I removed Master Config, which revealed an extension error. So I disabled extensions via config.php and the Control Panel is displaying. But if I go to the extensions page, only the 1st party extensions show up, so I can't enable/disable 3rd party extensions one by one. What could be causing that?

UPDATE 2: The reason I couldn't see my 3rd party extensions is because my third_party_path config var was wrong. Unfortunately, once I fixed the path, I got WSoD in the CP again, even with extensions disabled. So we're back to square one again.

  • Have you tried disabling the master config and running with EE's default config files? – Tyssen Nov 20 '12 at 12:05
  • @Tyssen After doing that I got an error about an extension, so I disabled extensions in config.php and the control panel showed up. The trouble is that it doesn't seem to be one specific extension causing the problem, so I don't know what to do next. – kmgdev Nov 20 '12 at 17:14
  • Have you tried comparing the phpinfo output on both the dev and production server to see if there is any difference in php version / mode / main settings which might shed some light? – Tidy Nov 20 '12 at 17:42
  • @tidy Is there anything specific you suggest I look for? There are quite a lot of settings and I don't know what most of them do... – kmgdev Nov 20 '12 at 18:23
  • You say you got an error about an extension, so was it not that one particular one causing the problem? – Tyssen Nov 20 '12 at 21:11
24

Most WSoDs are caused by a PHP error that haults processing combined with configuration that prevents the error from being shows in the browser.

The fastest way to debug white screen errors is to turn on logging and startup errors. The instructions below assume you are running under Apache with an Override setting that will allow php_flag and php_value directions in your .htaccess file.

Of course, before changing any files make sure you have a backup of the database and files!

  1. Create a directory in your home directory named log and make it writeable:

    $ cd ~
    $ mkdir log
    $ chmod -R 777 log
    
  2. Create an .htaccess file in the root of your project with these lines in it:

    php_flag display_errors 1
    php_flag display_startup_errors 1
    php_value error_reporting 30719
    php_value error_log /home/USER/log/PROJECT.log
    php_flag log_errors 1
    
  3. I'd recommend putting the following line at the top of your front controllers (your root level /system/index.php, /index.php and /admin.php) so you can see what requests cause what log output:

    error_log($_SERVER['REQUEST_METHOD'] . ' ' . $_SERVER['PHP_SELF'] . ($_SERVER['QUERY_STRING'] ? '?' . $_SERVER['QUERY_STRING'] : ''));
    
  4. While making the request that crashes EE, watch the log file with:

    $ tail -f /home/USER/log/PROJECT.log
    

The htaccess file does a few things:

  1. Sets error reporting to the current E_ALL value (you cannot use constants in .htaccess).
  2. You should see any syntax errors - that's what display_startup_errors does
  3. If the code turns off display_errors anywhere (pretty common when you are using a lot of third party code) you should still see the errors in the log.

If this doesn't work, look in your codebase for the following things. ack works best for this - it's like grep on steroids - but you can instead use your text editor's Find in Files functionality to search through a local copy if you have FTP-only access.

Stuff to check for (each of these is a call that may or may not have arguments, just search for each word listed and take the recommended action):

  1. @include, @require - any of these will ignore syntax errors in the included files. Change these to not have the @ sign so that errors inside them will show up. I believe there is still at least one reference to @require in the Extensions.php file, although this might have been removed finally.
  2. @eval - less likely than the above but would also ignore syntax errors. This shouldn't be used by core EE but could be used by add-ons. Change to not have the @ sign.
  3. exit, die - obvious probably, but make sure there is an echo before any of these so that you can see which one caused the output to end (resulting in a White screen).
  4. log_errors - see if someone is turning off error logging for some reason.
  5. error_reporting - comment out all of these in third-party add-ons as well as the core. Any of these will disable error reporting to not match the settings provided above.
  6. ini_set('display_errors', '0') or ini_set('display_errors', 0) or ini_set('display_errors', false)- comment out all of these as well

If this still doesn't work, you can use a PHP debugger to trace through the code (such as XDebug and one of the many debugging GUI front-ends available such as PhpStorm), or add error_log() and error_log(print_r($something, true)) calls to write things to the log. This is a lot better than print or echo because it can't be erased or output buffered and gets written instantly to the log file.

Hope this helps.

  • Sadly, it's a shared hosting plan so I can't SSH into it. I tried adding a log directory above web root and modifying the .haccess code you provided, but that resulted in a 500 error. Your paragraph about .ack is totally incomprehensible to me, I have no idea what to do with that information. :) – kmgdev Nov 19 '12 at 21:37
  • It sounds like a lot of your issues stem from things you can't do because you are on a shared account, but your host should be able to help you get those things accomplished. I'd contact your host and ask them to help you solve the problem or accomplish the things being recommended here. – UltraBob Nov 19 '12 at 21:53
  • 1
    You basically want to look for those function calls in your code base - you can do this on a local copy using your text editor's Find In Files. I'll update the text to indicate this. – Isaac Raway Nov 19 '12 at 22:11
  • Also note that this assumes you are running under Apache with an Override setting that allows php_flag and php_value directions in your .htaccess file... if you aren't, and since you have FTP only there is probably a good chance you are not, the logging stuff won't work. – Isaac Raway Nov 19 '12 at 22:16
3

If it's a memory issue, add

# Increase PHP Memory
php_value memory_limit 32M

to your .htaccess on the root of the html folder.

  • Hi & welcome, could you expand on this answer a bit? Perhaps about how to tell if it's a memory related issue, or other ways you could increase the PHP memory_limit? Aim to make it as useful to later readers as to the OP... – Tom Davies Nov 29 '12 at 0:18
3

When I have had a WSoDs in the past it has often been due to third party extensions failing.

Try turning off extensions in config.php and work your way back from there. Also, make sure you third-party extensions are up to date.

  • Good suggestion, but it didn't seem to have any effect. – kmgdev Nov 20 '12 at 16:56
  • Scratch that, disabling extensions in Master Config didn't work for some reason, but when I removed Master Config and disabled extensions via config.php, it did. Now the issue is that it doesn't appear to be one specific extension causing the problem, so I'm not sure what to do next. – kmgdev Nov 20 '12 at 17:16
  • When you delete an extension it should throw an error for the missing extension once you have logged in and it is required. just try going through each one and prefixing each one with a "." to make it hidden. Then if it is required you can rename it back. – jackmcpickle Nov 21 '12 at 6:24
3

After uselessly beating my head against the wall on this, I just decided to clear all the files from the server, drop the database, and re-upload everything.

Now it works fine.

Thank you, thank you, THANK YOU to everyone for all of your excellent suggestions, and I'm really sorry for totally mangling this question.

  • kgrote, EngineHosting does support system folder above web root, in the normal way. I moved to this arrangement many months ago, and it works just fine. Probably just needs a fresh set of eyes... – narration_sd Nov 22 '12 at 7:52
  • On the fix by clean slate and fresh uploads, I've led many a person through those -- there are real problems with many FTP clients, and you can very easily end up with mangled files. I would think this to be a solved issue about 20 years ago, but quite apparently it is not. You just got caught yourself this time. I don't know any way to handle it but a steady hand, in the sense that EE pretty dependably works, in standard base configurations. – narration_sd Nov 22 '12 at 7:55
2

Not sure if this is possible on EngineHosting, but could you try re-booting your server instance? I've had this issue happen before while migrating sites and to fix it I just had to restart apache and everything worked great.

  • It's a shared plan, so I don't think I can re-boot. – kmgdev Nov 19 '12 at 21:24
  • 1
    Can you clarify why restarting Apache solved this issue? I cannot think of anything in ExpressionEngine that would ever require restarting Apache. – Isaac Raway Nov 19 '12 at 21:29
2

Before going crazy I'd also try clearing your browser cookies.

  • Good suggestion, but sadly it didn't work. – kmgdev Nov 19 '12 at 21:46
2

You don't say which version of EE you're using or what add-ons but from experience a common cause of this has been Image Sizer. The specific problem being large files causing out of memory errors. There have been occasions where it has caused a problem even when the files in question are not being directly accessed.

  • 1
    Actually, I did say what version of EE I'm using, and I'm not using Image Sizer. – kmgdev Nov 20 '12 at 16:39
  • You did! Sorry, my mistake. I totally missed that! – foamcow Nov 20 '12 at 20:43
0

I solved this by myself today removing expressionengine/cache and then watching the folder on login. Turns out it was a devotee accessory failing due to a disabled php function. But I could see it creating a folder in cache.

Check/disable your accessories and extensions to check they are not the issue. 90% of the time they are when moving servers.

EE version 2.5.5

-1

white screen usually points toward a memory issue.

  • What do you suggest I do about it? – kmgdev Nov 19 '12 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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