How to fix a WordPress Crash

How to fix a WordPress Crash

Posted on Categories How ToTags

This article will show you how to quickly fix a WordPress white screen of death, or get unstuck from 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 still processing in the back end.

However, if you are still stuck you can open an FTP client and navigate to the home directory of the website, or where the wp-config.php files sits. Look for a file called .maintenance

If using Filezilla you can sort the file structure by date modified on the remote server by clicking on the date modified heading. It should appear at the top or bottom.

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

Use debugging to identify issues.

If you end up with a blank white screen simply update your wp-config.php and amend the line that switches debugging on to true, save to switch debugging on.

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

You can always add these other lines 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. This is more-useful in production situations.

define('WP_DEBUG_LOG', true);

The next two lines will tell WordPress whether or not to log script errors and save queries if they cause errors.

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

Here is the whole block again, 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 will be missing required files. Try re-uploading the old plugin and retry until the error is fixed. Note that some updates might not be compatible with older versions of WordPress, or in the case that a code is now using newer methods your PHP version may need to be updated before you can use it. Each update is different for each website.

When done don’t forget to switch debugging off.