How to fix a WordPress Crash

How to fix a WordPress Crash

Posted on Categories How ToTags

In this article I would like to show you how you can quickly fix a WordPress white screen of death or when you get stuck on the screen that says “Briefly unavailable for scheduled maintenance. Check back in a minute“.

WordPress is Briefly unavailable for scheduled maintenance - Eggbox Designs Website Development company in Portsmouth UK
WordPress is Briefly unavailable for scheduled maintenance screenshot – no doubt many of you will have encountered this error before.

Normally if you leave it a while longer it should resolve if you try to navigate back to the w-admin screen and is literally still processing in the back end.

However if you are still stuck then to get rid of this screen you can open an ftp client and navigate to the home directory of the website or where the wp-config.php files sits and look for a file called .maintenance

If using Filezilla you can sort the file structure into date modified order on the remote server by clicking on the date modified heading, it should appear at the top or bottom depending on if the sort is then displayed top to bottom or vice-versa.

Simply delete this file and you should be able to see the dashboard, and you may see the updates have already been done. If not update again and running the updates one at a time.

Use debugging to identify issues

If you still have no luck and you have a blank white screen simply update your wp-config.php and where you see the line that switches debugging on, amend this to true and save to switch debugging on.

define('WP_DEBUG', true); // Turn debugging ON

You can always add these other lines in as well.

define('WP_DEBUG_DISPLAY', false); // Turn forced display OFF
define('WP_DEBUG_LOG', true); // Turn logging to wp-content/debug.log ON
/* SCRIPT_DEBUG is a related constant that will force WordPress to use the "dev" versions of core CSS and Javascript files rather than the minified versions that are normally loaded.
This is useful when you are testing modifications to any built-in .js or .css files. Default is false. */
define('SCRIPT_DEBUG', true);
define('SAVEQUERIES', true);

Our next line constant tells WordPress whether you should display error messages in the browser or not. We have this switched off in production situations.

define('WP_DEBUG_DISPLAY', false);

The next line will tell WordPress whether or not to log the errors to a file called debug.log under the wp-content directory or not. This is more-useful in production situations.

define('WP_DEBUG_LOG', true);

The next two lines will tell WordPress whether or not to also log script errors and save queries if they cause errors. In this situation this is also useful.

define('SCRIPT_DEBUG', true);
define('SAVEQUERIES', true);

Here is the whole block again, and this time we turned display errors on because it may be quicker to output the text and quickly fix our issues.

define('WP_DEBUG', true); // Turn debugging ON
define('WP_DEBUG_DISPLAY', true); // Turn forced display OFF
define('WP_DEBUG_LOG', true); // Turn logging to wp-content/debug.log ON
/* SCRIPT_DEBUG is a related constant that will force WordPress to use the "dev" versions of core CSS and Javascript files rather than the minified versions that are normally loaded.
This is useful when you are testing modifications to any built-in .js or .css files. Default is false. */
define('SCRIPT_DEBUG', true);
define('SAVEQUERIES', true);

Now you can check for errors and replace any files that could have caused an error, for example a plugin might not have downloaded/uploaded correctly and be missing required files. Try re-uploading the old one and/or trying again until the error is fixed. Note that some updates might not be compatible with older versions of WordPress, or in the case that some code is now using newer methods your PHP version may need to be updated before you can use it. Each update is different as each website.

When done don’t forget to switch debugging off.