Less is more: tidying up and resolving conflicts

Module 5: Themes and plugins · Reading time: 9 minutes

Learning objective: After this lesson you can tidy up your plugins and track down and fix a conflict or a white screen yourself.

Key concepts: deactivate vs delete, inactive code, critical error, recovery mode, Site Health, Troubleshooting Mode, renaming the plugin folder, WP_DEBUG, WP_DEBUG_LOG, debug.log, error log

Switching off is not throwing away

Under Plugins you can Deactivate or Delete a plugin. The difference:

Deactivate: WordPress no longer loads the plugin. But the files stay in wp-content/plugins/, and they can often still be requested directly through the web server. If a separate PHP file in that plugin has a vulnerability, that vulnerability is still there. Attackers scan for known vulnerable files, not for active plugins.
Delete: the files are removed. Some plugins also clean up their settings and database tables when you delete them; others leave them behind.

If you no longer use a plugin, delete it. Deactivating is only for the short term (while you are looking for a problem). The same applies to themes (lesson 2.4).

Tidying up: a regular round

Go through your plugins once a quarter (lesson 9.4). For each plugin:

What is it for? If you no longer remember, find out. Often a plugin turns out to have been installed once for a single task and never removed.
Is it still being used? A slider plugin while there is no slider anywhere, a form plugin while your contact page uses a different form.
Can you do without it? Can WordPress, the theme or another plugin already do it (lesson 5.3)?
Is it still maintained? When was it last updated, and is it still in the plugin directory?

Do the tidying up on a staging site first (lesson 8.3), or at least make a backup, and delete one plugin at a time so you know what caused it if something goes wrong. Watch out for shortcodes: if you delete a plugin that provided [formulier id="2"], that text will then appear literally on your page.

When it goes wrong: the critical error

After an update, a new plugin or a PHP upgrade, you suddenly see:

There has been a critical error on this website.

or a completely white page. This means PHP stopped with a fatal error before a page was produced (lesson 1.2). Usually this is caused by a plugin or theme that does not work together with something else: another plugin, the new version of WordPress, or the PHP version.

Since WordPress 5.2, WordPress then does two things:

it sends an email to the administration email address saying which plugin or theme caused the error, with a special link;
with that link you log in to recovery mode: the admin area then works, with the plugin that caused the error temporarily switched off, so you can update, replace or delete it.

That is why an administration email address that you actually read is so important (lesson 2.2).

Searching yourself: the steps

No email arrives, or recovery mode does not work? This is how you find the cause yourself.

1. Check the error log

The error is almost always in the error log of the web server or of PHP. In DirectAdmin you will find it among the logs for your domain. Look for a line containing PHP Fatal error and the time of your attempt:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function()
in /home/gebruiker/domains/example.com/public_html/wp-content/plugins/oude-slider/slider.php:42

The path tells you who the culprit is: here, the plugin in the oude-slider folder. The rest of the line tells you why (here: a function that was removed in PHP 8, lesson 8.4).

2. Turn on the debug log (not the on-screen display)

If the error log contains nothing useful, add the following to wp-config.php (above "stop editing"):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WordPress then writes all errors to wp-content/debug.log, without showing them to visitors. Never leave this on longer than necessary: debug.log is in a folder that the web server serves, and anyone who knows the address can read it. It contains paths, sometimes usernames and other information that helps an attacker. Switch it off again once you have finished and delete debug.log. Alternatively, have WordPress write the log file outside the web directory by giving WP_DEBUG_LOG a path (for example '/home/gebruiker/logs/wp-debug.log', if your hosting provider allows it). In lesson 7.4 you check that debug.log is not public.

3. Switching off a plugin without the admin area

If you cannot get into the admin area, switch off the suspect plugin by renaming its folder, using File Manager or SFTP:

wp-content/plugins/oude-slider   becomes   wp-content/plugins/oude-slider-uit

WordPress can then no longer find the plugin and switches it off. If you do not know which plugin it is, rename the whole plugins folder to plugins-uit: all plugins are switched off. If the website then works, create a new empty plugins folder, move the plugins back one by one and check after each plugin whether the error returns. The same goes for a theme: rename the folder of the active theme and WordPress falls back to a default theme, if one is still installed (lesson 2.4).

4. Conflicts without a fatal error

Not every problem is a critical error. Sometimes a single feature stops working: a button does nothing, the form does not send, the editor loads only halfway. This is often a conflict between two plugins or between a plugin and the theme. The official plugin Health Check & Troubleshooting is useful here: in Troubleshooting Mode it switches off all plugins and changes to a default theme for your session only, while visitors still see the normal website. You then switch them back on one by one until the problem returns.

Also check your browser's console (F12): JavaScript errors often name the file, and therefore the plugin.

Site Health

Under Tools > Site Health WordPress checks your website itself: an outdated PHP version, plugins and themes that are not active, missing PHP extensions, a REST API that does not work, scheduled tasks that are running late. The Info tab shows all the details of your installation (versions, paths, PHP settings). You can copy that tab and include it when you ask for help. Take a quick look here after every major change.

Summary

Deactivating leaves the files in place; delete plugins and themes you do not use.
Tidy up every quarter, one plugin at a time, with a backup or on a staging site.
When a critical error occurs, WordPress sends an email with a link to recovery mode.
The error log or debug.log names the path of the culprit; switch debugging off again when you are done, otherwise debug.log is public.
Without the admin area, you switch off a plugin by renaming its folder; you track down conflicts with Troubleshooting Mode.

Quiz

Exercise

Exercise A5.4: Is your debug log not public? Enter your website's address and prove with the code the exercise gives you that the website is yours (a TXT record or a small file). The program requests /wp-content/debug.log: the result is good if it does not exist or is refused (404 or 403). If the program gets a file back, the result is red. The program also counts how many different plugin folders appear in the HTML of your homepage (for information only).

Exercise D5.4: Tidying up your plugin list. Make a list of all your plugins (active and inactive): name, what it is for, still needed (yes/no), alternative without a plugin. Delete the plugins you no longer need (after making a backup or on a staging site), one at a time, and check after each deletion whether the website still works. Fill in how many plugins you had and how many are left, and note whether any shortcodes were left behind that you had to clean up.

Exercise D5.4: Tidying up your plugin list

You do this exercise yourself; no one checks it. Tick off what you've done and mark the exercise as done.

Made a backup first or worked on a staging site
Removed one plugin at a time
Checked the website after each removal
Checked for leftover shortcodes

Your list: name, what for, still needed, alternative

How many plugins did you have before and after?

Your ticks and notes only stay in this browser; we don't send them anywhere. If you're signed in, we only save in My courses that you've done the exercise.

Cookies at WebOké

Cookie settings

Necessary

Marketing