White screen of death after deploying

Anytime I deploy to staging or production I get a white screen of death on the frontend. I can log in to the admin panel fine. It tends to go away after I edit something or change themes.

Any thoughts on why this is happening or how to fix it?

Thanks

Well white screen just means there’s PHP errors happening. Either adjust your PHP error settings to display them, or check your server logs. We can’t help debug without knowing what the errors are.

I’m not seeing any errors in the server’s error log or any PHP errors.

I’ve been trying to diagnose this problem a while and had to take a break. When I came back after about 30 minutes I reloaded the site and it worked fine.

So:

  • Deploy to Staging and I get white screen of death with no errors.
  • I let it sit for ~30 minutes and it works without any intervention
    from me.
  • I have all the plugins deactivated.

I’m not sure how much I can do in this situation.

It’s either PHP errors or a problem with your web server and PHP setup (FPM). But make sure your PHP is configured to display errors, or try changing the configs in Bedrock like WP_DEBUG_DISPLAY and WP_DEBUG which are turned off on staging and production.

I have always found it to be caused by a space at the end of functions.php or another of the functions files - like the one where you put the custom posts etc - start there!

Thanks for the help.

It turns out that it’s an issue with themes - whenever I deploy I get the following error:

ERROR: The theme directory "twentyfourteen" does not exist.

I have confirmed that the directory does exist and there are no PHP or server errors.

The problem resolves if I switch to another theme and then switch back again.

I do get 5 commands that fail during the deploy process, but everything completes and seems to work other wise:

Sorry, I couldn’t format that better.

DEBUG [6226347d] Running /usr/bin/env [ -L /home/<path-to-home-dir>/releases/20140409180603/.env ] on example.com DEBUG [6226347d] Command: [ -L /home/<path-to-home-dir>/releases/20140409180603/.env ] DEBUG [6226347d] Finished in 0.261 seconds with exit status 1 (failed). DEBUG [d529ff03] Running /usr/bin/env [ -f /home/<path-to-home-dir>/releases/20140409180603/.env ] on example.com DEBUG [d529ff03] Command: [ -f /home/<path-to-home-dir>/releases/20140409180603/.env ] DEBUG [d529ff03] Finished in 0.270 seconds with exit status 1 (failed). INFO [075e587d] Running /usr/bin/env ln -s /home/<path-to-home-dir>/shared/.env /home/<path-to-home-dir>/releases/20140409180603/.env on example.com DEBUG [075e587d] Command: ( WP_ENV=staging /usr/bin/env ln -s /home/<path-to-home-dir>/shared/.env /home/<path-to-home-dir>/releases/20140409180603/.env ) INFO [075e587d] Finished in 0.282 seconds with exit status 0 (successful). DEBUG [cb8d4997] Running /usr/bin/env [ -L /home/<path-to-home-dir>/releases/20140409180603/.htaccess ] on example.com DEBUG [cb8d4997] Command: [ -L /home/<path-to-home-dir>/releases/20140409180603/.htaccess ] DEBUG [cb8d4997] Finished in 0.247 seconds with exit status 1 (failed). DEBUG [d252ee1a] Running /usr/bin/env [ -f /home/<path-to-home-dir>/releases/20140409180603/.htaccess ] on example.com DEBUG [d252ee1a] Command: [ -f /home/<path-to-home-dir>/releases/20140409180603/.htaccess ] DEBUG [d252ee1a] Finished in 0.260 seconds with exit status 1 (failed). INFO [afd69719] Running /usr/bin/env ln -s /home/<path-to-home-dir>/shared/.htaccess /home/<path-to-home-dir>/releases/20140409180603/.htaccess on example.com DEBUG [afd69719] Command: ( WP_ENV=staging /usr/bin/env ln -s /home/<path-to-home-dir>/shared/.htaccess /home/<path-to-home-dir>/releases/20140409180603/.htaccess ) INFO [afd69719] Finished in 0.271 seconds with exit status 0 (successful). INFO [2fa30054] Running /usr/bin/env mkdir -pv /home/<path-to-home-dir>/releases/20140409180603/web/app on example.com DEBUG [2fa30054] Command: ( WP_ENV=staging /usr/bin/env mkdir -pv /home/<path-to-home-dir>/releases/20140409180603/web/app ) INFO [2fa30054] Finished in 0.250 seconds with exit status 0 (successful). DEBUG [04f619c1] Running /usr/bin/env [ -L /home/<path-to-home-dir>/releases/20140409180603/web/app/uploads ] on example.com DEBUG [04f619c1] Command: [ -L /home/<path-to-home-dir>/releases/20140409180603/web/app/uploads ] DEBUG [04f619c1] Finished in 0.256 seconds with exit status 1 (failed).

I need to ask, but did you filter out your home path or is it actually defined as <path-to-home-dir> in the cap configs? Although I’m guessing you edited it since it’s also example.com.

With linked_files they need to exist on the server before it works. So you’d need to manually make sure shared/.env and shared/.htaccess exist and it should work after that.

I’d probably make sure those errors are fixed and then see if you still have issues.

Yeah, I should have mentioned that - the home path and domain were filtered.

shared/.env and shared/.htaccess both exist on the server before the deploy process and are correctly linked in the current release after the deploy is finished.

I took a closer look and noticed that the files are being linked after the tests that fail:

DEBUG [35fb6e61] Running /usr/bin/env [ -f /home/<trimmed-path>/releases/20140410182521/.htaccess ] on example.com

DEBUG [35fb6e61] Command: [ -f /home/<trimmed-path>/releases/20140410182521/.htaccess ]

DEBUG [35fb6e61] Finished in 0.466 seconds with exit status 1 (failed).

 INFO [54e05673] Running /usr/bin/env ln -s /home/<trimmed-path>/shared/.htaccess /home/<trimmed-path>/releases/20140410182521/.htaccess on example.com

 DEBUG [54e05673] Command: ( WP_ENV=staging /usr/bin/env ln -s /home/<trimmed-path>/shared/.htaccess /home/<trimmed-path>/releases/20140410182521/.htaccess )
 
 INFO [54e05673] Finished in 0.330 seconds with exit status 0 (successful).

Oh I think that’s actually normal behaviour.

-f is checking if that file exists in the specific release dir. Although it says it fails, that just means the file doesn’t exist so it then properly creates the symlinks from shared to the new release.

So basically that’s all correct :slight_smile: and I’m back to not knowing what the problem is since I’ve never had that error about the theme.

Sorry about the thread-necro, but did you ever figure this out? I’m struggling with the same problem myself right now, and had no luck so far pin-pointing where the problem is.

Sorry, I don’t remember anymore.

After a while I figured out what was causing it in my case. $webroot_dirwas resolved to the current revision directory, which was cached/stored as a hard path for themes. When redeploying, this path would break. It would “resolve” when WordPress rechecked or figured out the path was broken. Manually overriding the variable so it would resolve to the current symlinked path instead seems to have solved most of my problems.

I am having this issue and would like to try you solution. Can you include the steps you took?

I am getting this same white screen when I deploy. I’ve tried to turn on errors by adding

ini_set('display_errors', 1);

to my environment file and even just editing my php.ini. Nothing gets displayed.

Can you let me know what I am doing wrong?

Check out this pull request. It solved the issue for me:

1 Like

Getting white screen now as well. Must be something else as downloaded bedrock last week.

Settings in my staging.php:

ini_set('display_errors', 1);
define('WP_DEBUG_DISPLAY', true);
define('SCRIPT_DEBUG', true);
define('DISALLOW_FILE_MODS', true); /

I can access /wp-admin but it doesn’t let me log in, throws no error, just reloads the page (if I intentionally input the wrong credentials I get an error message).

Try restarting nginx and php-fpm.

I’ve tried that aswell as rebooting the VPS instance. No luck.
I find it weird that /wp-admin is “working” but not the frontend?

Edit: Finally got in, not sure what locked me out of the backend.
I think the reason why the site was white was because twentyfifteen was activated, and it wasn’t present on the server.