WordPress There Has Been a Critical Error or White page of Death

Share this post

WordPress There Has Been a Critical Error or White page of Death

WordPress there has been a critical error or white page of death. In this post I’ll be covering what you’ll see when encountering the “there has been a critical error on your website” or the WordPress white screen of death, what causes these problems, how to identify the cause of these problems and how to fix these problems should your WordPress site be affected by the “there has been a critical error” or white page of death problem.

If you’re seeing “cannot establish database connection” error message (and have got here by accident) this post won’t be much help to you, and you’d be best to have a look at the post covering how to fix the error establishing database connection issue.

This post is orientated to using the cPanel hosting platform and your site being held in public_html (this may differ from how you’re operating).


The Quick way.

If you need a quick solution, firstly, enable wp-debug (wordpress’ debugging mode), then browse to your site’s wp-admin page to see an error.

The either disable the plugin that’s erroring, disable the theme that’s erroring, or reinstall wordpress core, or adjust your php ini according to what the error is that you see. Have some quick links:

If you struggle with any of the above, you’re most likely going to need to gain more of an idea of what’s causing the issue that you face, so reading what’s below is likely to be the best course of action for you to take.


What you’ll see.

If your site is erroring in a manner that’s critical, you’ll see an error message saying “There has been a critical error on your website”

Wordpress there has been a critical error or white page of death

Or, for older versions of WordPress (apply your updates people!) you might see a white page instead of the error message above.


What causes “there has been a critical error” or white page of death.

Both of these problems have the same cause. WordPress (or more accurately the PHP code that makes up your WordPress installation) is encountering an error when trying to generate page output. This is what the wordpress there has been a critical error message means.

The critical error being encountered prevents WordPress from generating page output.

There are numerous causes of the “there has been a critical error” message or white page of death. 

You might see advice along the lines of “disable plugins” or “switch to a default theme” when searching for solutions to this problem. Whilst that might help if it’s an issue with a plugin, or a problem with the theme, this advice isn’t going to help if the cause differs from these.

Consequently, it’s a much better idea to establish the cause, rather than taking a “try turning this off, if that doesn’t work, turn more things off” type approach.


How to establish the cause of the “there has been a critical error” or white page of death issue.

The first step to take when looking in to this issue, is to enable debugging (wp-debug) then browse to your site’s wp-admin page. This is covered in more depth in the post linked to above, or if you’re panicking and want to get things sorted out sooner rather than later, explicit instructions covering how to enable debugging in wordpress can be found here.

Once you’ve got an error displayed you can gain an idea of what’s causing the problem. In the error, you’l invariably see a path to the file that’s causing the error. These look like:

/home/hosting_username/document_root/wp-includes/filename.php

or

/home/hosting_username/document_root/wp-content/component/filename.php

For this to make a bit more sense, I’m going to have to tell you a bit about what exists where at file level in your WordPress.

Your entire WordPress installation exists in the document root of your domain. Within the document root of your domain (unless you’ve manually moved things about) you’ll see 3 directories (or folders):

wp-admin

wp-includes

wp-content

Both wp-admin and wp-includes are part of WordPress core. Everything you do in WordPress (installing plugins, installing themes, uploading pictures) all happens in wp-content.

The wp-content directory has multiple directories within, according to what you’ve installed. The PHP that’s specific to what you’ve installed is within the plugins and themes directories within wp-content:

/home/hosting_username/document_root/wp-content/plugins

And:

/home/hosting_username/document_root/wp-content/themes

Within the themes and plugins directories mentioned above are directories for each plugin and theme you’ve installed, for example:

/home/hosting_username/document_root/wp-content/themes/divi

or

/home/hosting_username/document_root/wp-content/plugins/Elementor

Due to the above, once you’ve enabled debugging in WordPress, you can establish what part of the site is causing the error quite quickly, just by looking at the file path in the error message.

If, for example, the error shows a path of:

/home/hosting_username/document_root/wp-content/plugins/ninja-forms

You know the ninja forms plugin is erroring. You could simply disable the plugin by renaming the plugin folder using the file manager in your hosting account.

The same applies to your theme, so if you see an error that mentions:

/home/hosting_username/document_root/wp-content/themes/astra

You could take your theme out of effect (although a default theme needs to be present for this to work – WordPress won’t run without a theme) by renaming the folder of the problematic theme.

It’s possible that there may be components (such as plugins, themes or WordPress core – as above) erroring that aren’t actually a problem with the components themselves, but an issue with the underlying PHP configuration. Some of these aspects you’ll have control over in your hosting account, but some you may need to address by getting in touch with your hosting provider.

I’ll cover these next because they’re effectively upstream of your site.


PHP.ini related issues.

The php.ini file is used to define limits for PHP based applications (your WordPress is a PHP based application) being run within hosting accounts. Usually there’s some kind of php.ini editor or manager in hosting accounts. When using cPanel this is called the Multi PHP ini editor:

cpanel multi php ini editor

In the MultiPHP ini editor you’ll see a variety of directives that effectively state what the PHP application can do or use:

cPanel multi PHP manager settings

As you can see there’s a description covering what each directive does, so I won’t reiterate this, what I’ll do instead is let you know which of the above can be adjusted to address some of the errors you might see after enabling wp-debug (WordPress debugging).

max_execution_time:

Usually you’ll see a “server 500” error if this is too low. You may see a “Fatal Error: max_execution_time Exceeded” error after enabling wp-debug if this is to low.

Fix:

Increase the max_execution_time value to allow enough time for the problematic PHP script to run. Then save the change.

max_input_time:

Usually you’ll either just see something stop uploading or processing data (such as a CSV import). You may see a “Fatal Error: max_input_time Exceeded” message after enabling wp-debug if this is to low.

Fix: 

Increase the max_input_time value to allow enough time for the problematic PHP script to run. Then save the changes.

memory_limit:

Usually you’ll see a “server 500” error if this is too low. You may see a “Fatal Error: allowed memory size of XXXX bytes exhausted” message after enabling wp-debug if this is to low.

Fix: 

Increase the memory_limit value to allow PHP to use enough RAM for the problematic PHP script to run. Then save the changes.

BE CAREFUL: You need to put an M on the end of the number to specify MB, without this, you’re setting the amount of bytes(B), not megabytes (MB)… and there are 1024 bits in a byte. 50 would be 50 bytes, 50MB would be 50 megabytes which is 512000 bytes.

post_max_size / upload_max_filesize:

Usually you’ll either just see something stop uploading or processing data (such as a CSV import). Typically you’ll encounter a problem when uploading something big to your site if this is too low.

Fix: 

Increase the post_max_size value to allow enough RAM to cover the amount of input PHP needs to be able to handle it or increase the upload_max_filesize value to cover the size of what you’re uploading. Or both. Then save the changes.


Missing PHP modules.

In PHP, modules (also known as extensions) are additional pieces of software that provide extra functionality to the PHP interpreter. These modules enhance the core capabilities of PHP by adding support for specific features, protocols, and functionalities.

If your WordPress code relies on a specific module and this isn’t installed server side, this will cause critical errors.

The error messages you’re likely to see after enabling WordPress debugging that relate to this are:

Module not found

Extension not found

Library is missing 

Call to undefined function (this can also have other causes, such as code related issues specific to the erroring component).

Module xxxx is not installed

Some hosting providers provide facilities in the hosting accounts that they provide that allows you to instal PHP modules, but not all do. If yours doesn’t you’ll need to contact your hosting provider to request the missing module be installed.


Disable the plugin that’s erroring.

First things first. If you disable a plugin that’s erroring, you’re going to loose the functionality that the disabled plugin provided.

If you do decide to disable a plugin, you might try reinstalling it, then reconfiguring it, or bringing what it used to do back into effect to restore the respective functionality.

If disabling a plugin is the required fix, what you’ll see in the file path in part of the displayed error is something like:

/home/hosting_username/ducument_root/wp-content/plugins/plugin_name

Obviously plugin_name will be the name of the plugin that”s erroring.

You can take the plugin out of effect by renaming the plugin’s directory (or folder) via the file manager in your hosting account.

To do this, open the file manager in your hosting account, then navigate to:

document root (usually public_html although this may differ if you’re not using cPanel or have a multisite hosting account) > wp-content > plugins (see the left hand highlighted area below), then right click on the directory (folder) of the plugin that’s erroring and click on “rename”:

Navigate to plugins directory

And you’ll then see something like this:

rename plugin directory

I’d suggest adding something to the end of the directory name as this makes the change easy to revert and also allows you to see what you’ve disabled easily. After specifying a new name, click “Rename file”:

Commit plugin directory name change

Changing the name of the plugin’s directory effectively disables the plugin by giving it a directory name that WordPress won’t be using.

In the context of the above, I’d rename the ics-calendar plugin directory to ics-calendar-disabled to disable the ICS Calendar plugin. I might do this if I saw an error that included the path:

public_html/wp-content/plugins/ics-calendar

The main thing to bear in mind, is that by disabling a plugin in this manner you’ll remove the functionality that this plugin provides, so part of your site won’t work as it did. You’d either need to reinstall the same plugin, then reconfigure it to do what the disabled plugin did, or replace the disabled plugin with one that provides the same functionality, then reconfigure the new plugin to do what the disabled plugin did.

Using the above as an example, I use the ICS Calendar plugin to embed a bookings calendar on a site, so the embedded booking calendar would stop functioning when I rename the ics-calendar plugin directory. To bring the contact form back in to effect I could reinstall the ICS Calendar plugin (or install an equivalent plugin that does the same thing), reconnect it to the external calendar then use the new short code provided to bring the embedded calendar back in to effect.


Disable the theme that’s erroring.

The process of disabling a theme that’s erroring is the same as the process to disable a plugin, the difference being that you’d rename the directory containing the problematic theme, rather than the problematic plugin.

Do be aware that this will only work to bring your site online if a default theme is also present, as WordPress can’t run without a theme. If you do have a default theme present, renaming a themes directory is an option, but if there is no default theme present you’re going to need to make one available at file level before disabling the problematic theme. You can find out how to bring a default theme in to effect in this section.

The other thing to bear in mind is that if you go ahead and disable the theme, WordPress will fall back on a default theme, which won’t include all the customisation you’ve carried out. This means that the appearance of your site will change considerably if you disable the theme your site uses.

To disable a theme, navigate to:

document root (usually public_html although this may differ if you’re not using cPanel or have a multisite hosting account) > wp-content > themes (see the left hand highlighted area below), then right click on the directory (folder) of the plugin that’s erroring and click on “rename”:

rename theme directory

You’ll then see something that looks like this:

Rename theme directory

I’d suggest adding something to the end of the directory name as this makes the change easy to revert and also allows you to see what you’ve disabled easily. After specifying a new name, click “Rename file”:

Commit theme directory name change

To bring your site back to how it was, you might then try and reinstall the theme you’ve just disabled. In theory this would bring the customisation back in to effect (as this is held in the site’s database). If issues persist, then you’re either going to have to:

  1. Use a different theme, and customise it to make it appear how you want it to, or
  2. Contact the theme developer for support.

Replacing parts of wordpress/FIx WordPress Core.

Replacing parts of WordPress can be used to fix WordPress core. If the path in error messages displayed after enabling wp-debug (WordPress debugging mode) include any mention of these in the file paths:

wp-includes

wp-admin

The problem you have with your site is specific to WordPress core. The easiest way to address this, is to replace the part that’s erroring.

You can also use this method to bring a default theme in to effect, should there be no default theme present in your WordPress installation.

Before you get started with this, it’s best to check that your hosting account has available disk space. If WordPress tries to update, and there’s not enough disk space to do so, this can cause a partial update to occur, which is a common cause of part of WordPress erroring.

You’ll need to ensure that you haven’t run out of disk space, and that you’re not close to your disk space limit to be able to carry out the fixes described here and to prevent the issue from occurring again in the future. You may need to contact your hosting provider to obtain more disk space.

The next thing to check is the version of WordPress that you’re using, as you’ll need to use the same version to replace parts of your WordPress installation. To check the version of WordPress you’re using browse to:

document_root/wp-includes

Then right click on the version.php file, then click on view:

View wp-version.php file

What you’re looking for in this file, are the numbers just to the right of:

$wp_version =

These tell you the version of WordPress you’re using:

Check WordPress version

In the example above, WordPress 6.2.2 is being used.

You’d then need to download the same version as the one you’re using from WordPress’ release page.

You’ll then need to upload this to your hosting account, then extract it, then start replacing the parts that are erroring.

It’s best to keep the WordPress you’re downloading and extracting separate from your site’s files to avoid confusion. So initially, within the file manage in your hosting account, create a new folder within the top level directory:

CPanel create new directory

Specify a sensible name for the new directory, then create the directory:

create new directory for upload

Then navigate to the new directory you’ve created, and click “upload”:

upload to newly created directory

Then click on “Select File”:

select file

Then browse to, and double click on the WordPress download you obtained from WordPress’ release site (as above):

Select wordpress zip file to upload

Then wait for the upload to complete (bar to go green), then click on the “go back to…” text:

go back to directory

You’ll then see the WordPress file you’ve uploaded in the directory you created a moment ago. Right click on this and then click on “Extract”:

Extract wordpress zip file

Then confirm the extraction:

Extract files

Then click “close” when the extraction results pop up appears:

Click close when extraction completes

And if you then double click the “wordpress” directory:

open wordpress directory

You’ll then see what looks like a WordPress installation:

see extracted wordpress core

At this point you can just drag and drop the extracted WordPress files over the top of your existing site files to replace parts of WordPress.

For example, if the site that’s erroring is held in the public_html directory, and the error mentions wp-includes in the path, you can drag and drop the wp-includes directory (the one that’s part of the WordPress installation you’ve just extracted) in to the public_html directory (then OK the “replace files” dialogue box), and you’ll replace the erroring wp-includes directory with a fresh good copy of wp-includes from the extracted WordPress:

drag and drop wordpress directories

And you can do the same with wp-admin.

For example, if the site that’s erroring is held in the public_html directory, and the error mentions wp-admin in the path, you can drag and drop the wp-admin directory (the one that’s part of the WordPress installation you’ve just extracted) in to the public_html directory (then OK the “replace files” dialogue box), and you’ll replace the erroring wp-admin directory with a fresh good copy of wp-admin from the extracted WordPress:

drag and drop wp-admin

And if you need to bring a default theme in to effect (so that you can then disable the theme you’re using should it be erroring), open the wp-content folder (within the extracted WordPress files):

open wp-content directory

Then open the “themes” directory:

open themes directory

Then drag and drop the twentytwetythree directory into public_html/wp-content/themes (assuming your site is held in public_html):

drag and drop theme directory

And you’ve just added a default theme, so then you can go ahead and rename your theme (if that’s what you needed to do) and when you do this, the default theme you’ve just added will come in to effect and you’ll then be able to access yoru WordPress.

Your site will look quite different with a default theme in effect, as any theme cusotmisation you’ve undertaken is specific to the theme you used, not the default theme. Reinstalling and reactivating the theme that your site was using may well bring this customisation back in to effect.


In Conclusion.

  • There are a lot of different causes to the “there has been a critical error” or white page of death problem.
  • Each cause has a different fix so its important to establish the cause of the issue.
  • Enabling debugging in WordPress will help you identify the cause of the issue.
  • It’s usually possible to overcome these issues by taking action in your hosting account or within WordPress’ file system.

Share this post

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top