A few days ago a friend called and told me he had been given the task of maintaining an old WordPress project. Apparently, the website had not been updated for more than three years and there were issues all over the place. The poor guy was totally stuck, because he couldn’t update anything there: plugins, theme, content… nothing worked. All actions (other than browsing the site itself) resulted in WordPress crashing and returning an error.
When we have an unusable WordPress that generates errors continuously an can’t be updated, the first thing we must do is to identify why it’s behaving the way it does. That is, we need to find the culprit. Usually, any issues you might encounter on a WordPress site occur because of your theme or one (or more) of your plugins.
Considering this, the usual procedure to fix a WordPress site is to identify the offending plugin, eliminate it from the equation, update everything, and, finally, see if we can reinstall and update the offending plugin on our website or we should look for a replacement. Today I’m going to tell you four simple tricks to discover why a website fails and, thus, to be able to fix it.
Using Our Server’s Error Log
Assuming the hypothesis that it’s a plugin the one who’s causing the errors we have on our website, the first thing we have to do is validate said hypothesis. There are different formulas for doing so. Personally, I like to start by looking at my server’s error log, which has its own option in cPanel:
Hopefully, the error log does not contain only a trace of the errors that have occurred on our website, but also information on “where” they occurred and, therefore, who was the culprit. For example, last week I encountered the following issue in the error log of my development environment:
appserver_1 | [Mon Aug 24 09:18:20.977541 2020] [php7:notice] [pid 1107] [client 172.20.0.2:34396] PHP Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>yoast/v1/get_head</code> is missing the
required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugg
ing in WordPress</a> for more information. (This message was added in version 5.5.0.) in /app/.lando/wordpress/wp-includes/functions.php on line 5225, referer: http://nab5.lndo.site/wp-admin/edit.php The log is reporting a PHP notice that occurred in one of WordPress’ own files (wp-includes/functions.php), which doesn’t tell us anything about “a plugin being the culprit.” Luckily, if you read the whole message, you will see that it describes what failed (i.e. a call to the register_rest_route function) and gives us a hint of what might be wrong: Yoast (see how it mentions “yoast/v1/get_head“?).
Error logs are the easiest way to quickly find out when/if something’s amiss and, if it is, what’s the reason behind an error. In this particular example I found out I had an issue with Yoast and, well, all I had to do was update the plugin to its latest version 😉
Deactivating Plugins from the WordPress Dashboard
Unfortunately, it is not always possible to access a website’s error log to find out when things went south. Or, if you do have access to the log, it might be incomplete. In these cases we need alternative formulas to validate (or disproof) our initial hypothesis.
Assuming our website is failing due to a faulty plugin, the easiest thing to do is deactivate all plugins and check if the error persists. If it doesn’t, the culprit was a plugin; if it persists, the problem is elsewhere.
To do this, go to the WordPress Dashboard » Plugins, select all your active plugins, and bulk Deactivate them:
and check if the error still occurs. If it doesn’t, you know the issue was caused by one of the plugins you just deactivated. Now it’s time to discover which one precisely.
To identify the faulty plugin, you can activate them one by one and check when the error shows up again. Or, if you want to go faster, you can apply the following steps:
- Activate half of your plugins.
- If the error reappears, the culprit is in the half you just activated, so you can safely activate the other half.
- If the error does not appear, the culprit is in the other half.
- Once you know in which “group” the faulty plugin is, you only need to focus on that one and repeat the process. Activate half of that group and deactivate the other half (i.e. you’d now be checking a fourth of the total), and see if your website works properly.
- Repeat the process until you find the culprit.
Once you know which plugin is failing, how to fix the problem is up to you. You may have to contact the developer, try to fix the plugin yourself, or even consider replacing it with an alternative. But, at least, you now know what you need to do to get rid of the issue.
Nelio Forms
A fantastic contact plugin using the block editor. In its simplicity lies the true power of this plugin. I love it, very versatile and it worked perfectly for me.
Wajari Velasquez
Backup Your List of Active Plugins
Remember my friend from the beginning? When we were investigating his website, we followed all the previous steps and deactivated all the plugins on his website…
…which resulted in a white screen of death!
Apparently the web was full of custom plugins and theme tweaks with plenty of cross-dependencies. By deactivating the plugins, some of the functions the theme relied on were no longer available, which triggered a fatal error. This is clearly a bad practice: a theme can not rely on a plugin being active. If it needs some of the features provided by a certain plugin, it must implement security checks to validate whether they’re available or not.
Anyway, the thing is the site was completely shut down and we weren’t able to reactivate the plugins using the Dashboard. So what’s the solution here? Well, for starters, you should always have a backup of your website… but in this particular case there’s an easier and faster solution at hand.
In your WordPress database, there’s a table named wp_options. There, you’ll find an option named active_plugins. Its value is an array with all the active plugins. So, before deactivating the plugins using the bulk action I mentioned before, just save this value in a text file:
This way, if “deactivating all plugins” ends up in an unlikely (but not impossible) WSOD, you can reactivate all plugins by restoring the active_plugins option in the database.
How to Deactivate Plugins via FTP
If you know that your problem is being generated by a specific plugin but you have no way to deactivate it from the WordPress dashboard, you can do it safely via FTP.
As you already know, plugins are nothing more than a set of files. When you install a new plugin on your website, its code ends up in WordPress’ wp-content/plugins folder. Taking advantage of this knowledge, we can deactivate the plugin by “removing” it from said folder.
Go to your server’s cPanel and look for the FTP option:
Then, using the FTP file explorer, find the wp-content/plugins folder and locate your plugin:
Now, all you have to do is either delete the plugin or rename its folder so that WordPress can’t find it. This way, if you log into your WordPress site, WordPress won’t see the plugin anymore and won’t be able to load its faulty code, thus solving the issue you had.
Use a Default Theme
Finally, if the hypothesis that the problem was caused by one of your plugins wasn’t true, the next step is to assume that the culprit is your theme. In this case, all you have to do is install a default WordPress theme (such as Twenty Twenty) and see if the problem disappears or not. If it disappears, you already know that there is something wrong with your original theme; if it doesn’t, that’s something we’ll have to discuss in a different post.
If, for whatever reason, you don’t have access to the WordPress dashboard, you can install a new theme on your website by uploading it via FTP (wp-content/themes) and change the active theme using the database: just modify the options template and stylesheet in wp_options. For example, you might want to set both options to twentytwenty, assuming that’s the theme you’ve uploaded.
In Summary
A vanilla WordPress (without plugins and without a custom theme) is unlikely to fail. So, if you have problems on your website, the culprit is most likely one of your plugins or your theme. In today’s post we have seen different formulas to find the culprit, get it out of the way, and recover the website. I sincerely hope you don’t need to use any of these tricks… but if you do, I hope they’ll be helpful.
What about my friend’s website? Well, I don’t know―some people say he switched careers… 🙂
Featured image by Olia Nayda on Unsplash.
Leave a Reply