free consultation
This is basically a situation where there is a problem that prevents WordPress from loading all the necessary scripts correctly. As of version 5.2, WordPress not only informs you of this error via a message, but also sends an email to your site administrator. Such a message contains detailed information about the plugin or theme that caused the problem, and a link to the WordPress recovery panel. This is a significant improvement over the previous situation, when the so-called “white screen of death” simply appeared.
See also Kadence or Elementor - which to choose?
Table of Contents:
A critical error in WordPress usually results from a malfunctioning plugin, script or code. It can appear after an update to one of these components or be the result of an infection. In the case of an infection, it is recommended to use the services of a specialist who can professionally help eliminate the problem.
It is important to update the site manually, as automatic updates can take away control of the process. This loss of control can be the potential cause of a sudden critical error, requiring quick intervention and repair.
In practice, a critical error can have various causes, but most often it occurs as a result of a plugin or theme update. It is these updates that often lead to the error, resulting in a system lockdown to prevent possible more serious consequences. As a result, the site displays a message like the one below.
You will discover more information by trying to log into the CMS administration panel. You will then see the following message, which also contains a suggestion:
These types of notifications are activated from WordPress version 5.2 and above. It is worth consulting your system administrator's emails to find information about the cause of the problem. Ignoring these messages may result in their repetition. However, keep in mind that the link to recovery mode is only active for 24 hours after receiving the message. Therefore, it is necessary to act quickly after receiving it. If you notice a problem after that time, you will have to wait for another e-mail or use FTP to disable the faulty plug-in (if you know its name).
So, if you don't have FTP credentials, add an FTP account using the hosting service's management panel. Alternatively, use the file manager available on most hosting platforms. In my case, I choose the latter solution and proceed as follows:
See also plugins for Woocommerce that your online store should have.
Well, what if the backup plug-in is the culprit of this critical error?
No worries!
In this case, we install the WP Rollback plugin, which allows you to restore previous versions of plugins.
We press the “Rollback” option next to WPvivid (our backup plugin).
After activating Rollback, we see the current selected version of the plug-in, and a list of previous versions is displayed below. We select the previous version and click Rollback.
After installing the selected version of the plug-in, we can run it.
You can see that this task is not so difficult, and the critical error suddenly becomes less scary.... ;)
However, this is not the end of the story. Other errors can occur, such as a redirection error.
See our Wordpress care service and :
WordPress offers a wide range of possibilities to optimize our site for SEO, especially with its flexible URL structure, known as direct links, and allows for free management of redirects.
Redirects are a powerful tool in the battle to rank high in Google search results. However, as Uncle Ben from Spider-Man pointed out, with great power comes great responsibility.
This is where these plugins come into play again. Since plug-ins can also manage URL redirects, it sometimes happens that two different plug-ins start working in opposite directions. Simply put, plugin A redirects from A to B, while plugin B redirects from B to A.
The result can be the creation of a redirect loop. As a result, the browser detects this loop and informs us of the error.
No one is happy when you start making them “crazy.”
In addition to redirect loops, we may also encounter an error related to excessive redirects. This means that we send the browser from point A to point B, from B to C, and so on, which can lead to problems.
Redirection errors may affect only specific subpages. This means that, in general, a page may work correctly, but after accessing a specific subpage, the browser may suddenly display an error.
In this case, it is necessary to track all redirects for a given subpage, which may include checking an SEO plugin or a dedicated redirection plugin.
However, sometimes the problem with redirects affects the main address of our site, which can prevent access to the WordPress admin panel.
It is worth noting that plugins are not always the only cause of redirect errors. Often, the problem stems from bad WordPress Address and Site Address settings in the WordPress admin panel. For example, trying to force an address with an HTTPS prefix on a site that does not have an SSL certificate installed can lead to such problems.
Another common problem, not necessarily directly related to redirects, but worth noting, is a simple typo when entering a page address.
Of course, if you lack access to the WordPress admin panel, you will need to log in directly to the server using an FTP connection.
After successfully logging in, we navigate to the directory containing our WordPress.
Then open the “wp-content” folder.
Here we go to the “themes” folder.
We find the folder of the currently used theme, for example, OceanWP.
Inside this folder, we look for a file named “functions.php” and edit it.
Now, directly below the first line starting with a sharp parenthesis, we add two lines of code that modify the WordPress URL and the Site URL, respectively:
update_option( 'siteurl', 'https://example.com' );
update_option( 'home', 'https://example.com' );
These addresses are identical to the ones we enter in the Settings section of the WordPress admin panel.
We enter the correct addresses here, that is, if we previously forced the use of HTTPS on the site without a certificate, now we enter the address with HTTP. It is important to make sure that the addresses are accurate and without errors.
Then we save the changes and close the text editor. We upload the modified file to the server.
After these steps, we should be able to log into our WordPress site. Once we achieve this, it is recommended to remove the two lines of code added earlier from the functions.php file.
If we encounter an error and can't log into the WordPress admin panel, the Emergency Restore Script can help us quickly fix the redirection problem.
After running the script, if the error is due to a specific plugin, as shown earlier, we can disable it, as well as all of them at once, to see if that resolves the redirects.
In case the problem is not in the plugin or theme, but, for example, is due to a typo in the domain name (a misspelled site address), then in the scope of the script you will find an option to correct the site and WordPress addresses (which are usually identical).
We make the corrections and press “Update URLs.”
Done!
The site should now be up and running, and we can log into the WordPress admin panel.
In a situation where disabling all plugins and themes, checking the SSL certificate and URL settings in WordPress didn't work, it's worth taking a look at the .htaccess file.
This file plays an important role in controlling various aspects of the website, including redirects.
To see if the .htaccess file is the culprit, we need to log into the server via FTP.
Unfortunately, in this case the Emergency Restore Script will not help.
After logging into the server, we go to the WordPress root directory, where the .htaccess file is located.
We rename this file by adding “old” at the end, for example.
By renaming the .htaccess file, we de facto disable it, while keeping a backup. However, it is worth remembering that such a modification may introduce some unforeseen consequences, so we recommend caution.
After this operation, we refresh the page, checking whether the problem has been fixed. If so, we go to the WordPress settings and then to the “Direct Links” tab. Here we restore the previous settings and save the changes, which will cause WordPress to generate a new .htaccess file.
It is worth comparing the new and old .htaccess file to identify any changes. However, it is important to remember that modifications to the .htaccess file can also be the result of plug-ins. For this reason, deleting parts of the .htaccess file may adversely affect the performance of some plug-ins, such as those responsible for WordPress security or controlling access to files on the server.
If the problem with the .htaccess file is difficult to identify or solve, it's a good idea to consult someone knowledgeable about WordPress.
Of course, there is a risk of somehow losing or accidentally deleting important WordPress files....
Let's see what happens if we delete some important WordPress files.
Let's move on to trying to delete some WordPress files using an FTP connection.
I decided to delete some random files from the WordPress root directory and from the wp-admin directory. In addition, I completely deleted the folder with JavaScript files (“js” folder) from the wp-admin directory.
These actions were enough to significantly disrupt the site - when you try to log into the administration panel, a critical site error appears.
On the WordPress home page, the message “No such file or directory” appears, which means that no such file or folder exists.
I understand, it's like we get a hint that something is wrong, that certain files are missing.
But how to deal with it?
We need to download the latest version of WordPress from the wordpress.org website, unzip it on our computer, and then transfer the missing files from the computer to the server.
Luckily, FileZilla offers a useful directory comparison feature, which makes the process much easier.
We open the same directories (i.e. the ones whose contents we want to compare) on both the computer and the server. We then enable the directory comparison function by going to Preview > Directory Comparison and clicking Enable.
FileZilla will mark the differences in the contents of open directories.
Now we just need to copy the missing files from the left side (our computer) to the right side (to the server).
And now we have to go through each directory until we find and complete all the missing files. This task can be a bit time-consuming.
However, it's worth seeing how the Emergency Restore Script can make the process much easier. After launching the script, we go to the “Core Files” section, where we can immediately see a list of missing WordPress files.
Scroll down the page to the very bottom of the section, where we have additional options. Here it is possible to rescan all WordPress files using the “Rescan Core Files” option. What's more, with one click (using the “Reinstall All Core Files” option) we can reinstall all WordPress files.
The Emergency Restore script takes care of this in literally a few moments.
In the case of manual intervention? Accordingly with half an hour, not to say more.
The latest version of WordPress, when a critical error is detected, automatically sends an email with information about the error and a link to emergency mode for the site administrator.
When you click this link, it will open the WordPress admin panel in fallback mode.Fallback mode deactivates plugins and themes that may cause problems.
This allows the user to, for example, restore a backup of the site.
Of course, the theory always seems simple, but in practice, various unforeseen situations can occur.
Imagine making an update and getting a blank screen with a short error message as a result, and the email to the administrator never arrives.
In such situations, if we update only one plug-in and a critical error occurs, we can say with reasonable certainty that a particular plug-in is the trouble maker.
There is also no problem with themes, since we usually have only one active theme.Even when we update several themes at once and a critical site error appears, we can assume that it is the active theme that is causing the trouble. The issues become more complicated when we update several plugins at the same time, and we are not sure which one is responsible for the critical site error. It can also happen that the error appears after updating WordPress itself. In this case, it is likely that one of our plugins or themes is not compatible with the newer version of WordPress and is generating errors. What to do in this situation? We have two options.
First, we can disable all plugins and the current theme. This should fix the error and restore access to the admin panel.
Then we can restore the backup of the site. However, it is useful to find out what caused the error, so we can re-enable one by one what we previously disabled and observe when exactly the error occurs - this will allow us to identify what is responsible for the critical error.
The second option is to use the so-called debug mode of WordPress.Debug mode makes WordPress display on the homepage all the errors and warnings encountered, along with their specific location.Unfortunately, debug mode is disabled by default, so I will now show how to activate it.
To activate WordPress debugging mode, follow the instructions below:
Log in to your server using an FTP connection.
Navigate to the directory containing your WordPress files.
Find the file named wp-config.php.
Open the wp-config.php file with a text editor, such as Notepad or Visual Studio Code.
Add the following code before the line containing the command /* That's all, stop editing! Happy publishing. */:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
This code activates debug mode and writes error logs to a file.
Save the changes and close the file.
Now WordPress is running in debug mode, which will allow you to view errors and record detailed information about them. Remember to disable debug mode after resolving the issue, so as not to generate additional logs. To do this, remove or comment out the lines of code you added earlier in the wp-config.php file.
We modify the file and search it for a line with the phrase WP_DEBUG.
Note that by default, debug mode is disabled because the value of the WP_DEBUG parameter is set to “false”.
To enable debug mode, it is necessary to change the word “false” to “true”.
We save the changes made and close the text editor.
We confirm that we want to send the new version of the wp-config file to the server by clicking “YES”, and now the debug mode is active.
Now we should notice additional information about errors on the page.
Okay, we already have an idea of what's causing trouble on our site, so we're moving on to fixing it.
Simply disabling the plugin or theme that generates the error will restore access to the admin panel.
To deactivate a plug-in or theme, simply rename the corresponding folder on our server.
Although for disabling the WooCommerce plugin, go to the wp-content > plugins directory, and then modify the woocommerce folder name by adding any part at the end.
Check out the WP Super Cache wordpress plugin test.
We refresh the page, and voilà, the site is active again.
At this point, we can choose to remove the plug-in if we don't need it, or restore the site's backup to its pre-upgrade state.
The same process can be used to deactivate motifs.
Go to wp-content > themes directory and modify the folder name of the currently used theme.
After disabling the theme, our site will still not display content, as WordPress needs the theme to render content correctly. Nevertheless, the WordPress admin panel will be fully functional, allowing us to restore a backup of the site or install a new theme.
I understand that you want to make troubleshooting a critical error faster and more convenient. Instead of logging into the server via FTP, entering data, installing an FTP program, or turning debug mode on and off, you can use the Script Failover Restore.
Let's take a look at how it works.
After noticing the available updates, you go to the site and proceed to update the...
See also 5 fastest wordpress themes
During the update process, when a critical error suddenly occurs on the site, causing it to be completely blocked, I reach for the Emergency Restore Script.
The script is a simple PHP file that I run by typing the exact address on the server into a browser. I then enter the password, which triggers the disaster recovery script.
Going to the Plugins section, I click the “Deactivate plugin” option if I know the plugin that caused the problem. If I am unsure about a particular plugin, I use the “Deactivate all plugins” option.
This procedure can also be applied to themes, allowing you to quickly identify the source of the problem and restore your site.
Our offer to create websites :
After disabling all themes, although the homepage may remain empty, the WordPress admin panel will still be available and functional.
Then, we head to the WordPress admin panel, activate the WPvivid plugin and proceed to restore the backup.
To avoid critical errors, it is important to follow a few key steps. Regular updates are the foundation, but it is equally important to disable automatic updates. As an added convenience, use snapshots before proceeding with necessary updates, allowing you to safely restore your site in case of problems.
The question of whether or not to update plugins and themes in WordPress often raises questions. Should you update, or is it better to avoid it?
There is no definite answer, because it depends on the type of update. If you're dealing with a new version of a plug-in, enhanced with new features, sometimes it's worth waiting a few weeks before updating. The release of version 3.0 is often quickly followed by version 3.1, and this can continue for days afterwards. Therefore, sometimes it pays to wait patiently for a more stable edition.
However, there are updates that are not worth putting off. These are security patches that close potential vulnerabilities that make it easier for unwanted intrusion into the site. In the case of such updates, we don't wait - we execute them immediately. Security holes are quickly becoming a buzz, and information about them is well documented. Plugin authors often describe how the new version fixes the problems found.
Therefore, if there is a risk of a security breach, it is advisable to update without delay. However, it is worth remembering to make a backup before any updates, which allows us to safely revert to the previous state if necessary. I personally recommend the WPvivid plugin for this purpose.
Having a security copy, we can confidently proceed with the update.
See also:
Check your mailbox for an email regarding a site error. Log in through the link provided and, depending on the source of the problem, disable the appropriate plug-in or temporarily change the theme.
JDM.co.uk customers can conveniently use the option to check the error log, where log analysis will help identify the problem and find a solution.
If you can't access Cockpit, you can try to disable plugins via SFTP, following the step-by-step instructions. A similar method can be applied to a theme by uploading a new version via SFTP to the /wp-content/themes folder, where the installed themes are located.
If none of the above methods work, you can report the problem to the hosting company, which will help you solve the problem by offering support for an additional fee or free of charge, depending on the extent of the problem.
Digital Agency Hauerpower
Copyrights 2010-2022
