Module 5 · 5.4

English

Nederlands English Deutsch

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 plugins and find and fix a conflict or 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 isn't the same as throwing away

On the Plugins screen 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 are often still directly accessible via the web server. If a loose PHP file from that plugin has a vulnerability, it's 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 deleted; others leave them in place.

If you no longer use a plugin, delete it. Deactivating is only for a short while (while you're tracking down a problem). The same applies to themes (lesson 2.4).

Tidying up: a fixed routine

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

What's it for? If you can't remember, find out. Often a plugin was once installed for a single thing and never removed.
Is it still used? A slider plugin while there's 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? Last updated, still in the plugin directory?

Do the tidying up in staging first (lesson 8.3), or at least make a backup, and remove one plugin at a time so you know what went wrong if something does. Watch out for shortcodes: if you remove a plugin that produced [formulier id="2"], that text will afterwards 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:

Er is een kritieke fout op deze website.

or a completely white page. This means PHP stopped with a fatal error before a page could be produced (lesson 1.2). This is usually caused by a plugin or theme that doesn't get along 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 admin address stating which plugin or theme caused the error, with a special link;
that link lets you log in in recovery mode: the dashboard then works, with the plugin that caused the error temporarily switched off, so you can update, replace or delete it.

This is why an admin address that you actually read is so important (lesson 2.2).

Finding it yourself: the steps

No email arriving, or recovery mode not working? Here's how to find it 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'll find it under your domain's logs. Look for a line with 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 folder oude-slider. 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 message)

If there's nothing useful in the error log, add this 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 switched on longer than necessary: debug.log sits in a folder 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 after you're done searching and delete debug.log. Or have WordPress write the log file outside the web folder by giving WP_DEBUG_LOG a path (for example '/home/gebruiker/logs/wp-debug.log', if your host allows this). In lesson 7.4 you check that debug.log isn't publicly accessible.

3. Switching off a plugin without the dashboard

If you can't get into the dashboard, switch off the suspect plugin by renaming its folder, via File Manager or SFTP:

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

WordPress then can't find the plugin and switches it off. If you don't know which one it is, rename the entire plugins folder to plugins-uit: all plugins switch off. If the website then works, create a new empty plugins folder, put the plugins back one by one and check after each one whether the error comes back. The same applies to a theme: rename the active theme's folder and WordPress falls back to a default theme, if one is still present (lesson 2.4).

4. Conflicts without a fatal error

Not every problem is a critical error. Sometimes just one feature doesn't work: a button does nothing, the form doesn't send, the editor loads halfway. That's often a conflict between two plugins or between a plugin and the theme. The official plugin Health Check & Troubleshooting is handy for this: in troubleshooting mode it switches off all plugins and switches to a default theme for your session only, while visitors still see the normal website. Then you switch them on one by one until the problem returns.

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

Site Health

Under Tools > Site Health, WordPress checks your website itself: outdated PHP version, plugins and themes that aren't active, missing PHP extensions, a REST API that isn't working, scheduled tasks that are running behind. The Info tab lists all the details of your installation (versions, paths, PHP settings). You can copy that tab and include it when asking for help. Check this after every major change.

Summary

Deactivating leaves the files in place; delete plugins and themes you don't use.
Tidy up every quarter, one plugin at a time, with a backup or in staging.
With a critical error, 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 after searching, since debug.log is otherwise public.
Without the dashboard, switch off a plugin by renaming its folder; find 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 it's your own website (a TXT record or a small file). The tool requests /wp-content/debug.log: it's fine if this doesn't exist or is refused (404 or 403). If the tool gets a file back, that's shown as red. The tool also counts how many different plugin folders appear in your homepage's HTML (for information only).

Exercise D5.4: Tidying up your plugin list. Make a list of all your plugins (active and inactive): name, purpose, still needed (yes/no), alternative without the plugin. Remove (after a backup or in staging) the plugins that are no longer needed, one at a time, and check after each removal that the website still works. Note down how many plugins you had and how many are left, and record 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