Delete plugins and themes the site no longer uses instead of leaving them deactivated, keep one current default theme as a fallback, and check for leftovers after every redesign or rebuild.

Switched off, still there

Open the plugins screen on an older WordPress site and the list often includes a long run of inactive ones: plugins switched off years ago and never removed.

A slider from the previous design. A contact form replaced by a better one. A backup plugin someone tried for a week.

Deactivating them felt like removing them. It is not: every file is still on the server, exactly as it was on the day it was switched off.

And those files can still be attacked.

What deactivating actually does

WordPress loads each active plugin whenever a page is built. Deactivating a plugin tells WordPress to stop loading it, and that is all it does.

The plugin's folder stays in place, full of PHP files. Most do nothing on their own, but some will run when requested directly by their address on your site.

If one of those has a known flaw, such as an upload script that does not check what it accepts, the attacker does not care whether the plugin is switched on.

Automated scans look for the file, not the setting.

What tends to be left behind

The fifth gets forgotten most, because it appears in no WordPress screen at all. It is a whole second site, with its own outdated plugins, sitting beside the real one.

Why the updates stop

WordPress still lists updates for inactive plugins, but people skip them. Updating something that is switched off feels pointless.

WordPress 4.6, released on Tuesday, makes updating quicker because it happens without leaving the page. It does nothing for plugins nobody looks at.

Plugins that have been closed in the WordPress directory get no updates at all, and the dashboard gives no sign of it.

So the deactivated plugins on a site tend to be its oldest code. Which makes them the likeliest way in.

A worked example

A family cherry orchard with a u-pick season and a farm stand had its site redesigned two years ago, with a new theme and a booking plugin for picking times.

The old theme, an old slider and a shop plugin from the years they shipped gift boxes were all deactivated during the redesign and left where they were.

In July, in the middle of picking season, visitors on phones began landing on a spam pharmacy site instead of the orchard's pages. Visitors on computers saw nothing wrong.

The injected code sent only phone visitors away, which is why the owners, checking from the office computer, took days to see it.

The way in was a file inside the old slider, with a flaw published long before. Switched off, the slider had never been updated, and its files still answered anyone who asked.

The clean-up removed the injected code, deleted every unused plugin and both old themes, and kept a single current default theme.

The orchard's developer now compares the installed plugins with a written list after any change to the design.

Delete, do not deactivate

If a plugin is not in use, delete it from the plugins screen. WordPress then removes its folder from the server.

Before deleting, note any settings worth keeping and take a backup. Some plugins delete their stored data on removal; others leave it in the database.

Plugins that arrived bundled with a premium theme often sit in the same list. If the theme has gone, its bundled plugins should go with it.

If you might want a plugin again, it can be reinstalled in a minute. Keeping it installed just in case is the habit to break.

Themes are files too

Old themes carry the same risk. Many bundled their own image resizers, sliders and upload scripts, and those files keep answering requests whether or not the theme is active.

Delete every theme the site does not use, with two exceptions.

Keep one current default theme, such as Twenty Sixteen, as a fallback. If the active theme's files go missing, WordPress falls back to it and the site still shows something.

Switching to it is also the quickest test of whether a fault lies in the theme.

And if the active theme is a child theme, keep its parent. It shows as inactive, but the site depends on it.

Check after every redesign

Most leftovers arrive in one go, at a redesign, when the new theme and plugins go in and the old ones are switched off rather than removed.

Make the clean-up part of the launch: a list of what should be installed, compared with what is, and everything else deleted.

Ask whoever built the new site to confirm, in writing, that no copy of the old site or test folder was left on the server.

What a tidy install looks like

Two lists that match: the plugins the site uses, and the plugins on the server.

One theme in use, one default as a fallback, and the parent theme if there is a child. Nothing else in the themes folder, and no second site in a subfolder.

A site in that state has far less code for anyone to probe, and far less for whoever maintains it to keep current.

The counter-case

Deactivating has its place. When something breaks, switching plugins off one at a time is how the culprit is found, and a plugin can sit deactivated for a day while that happens.

A plugin used only for a few weeks a year can reasonably stay installed, provided someone keeps it updated all year.

And deleting carries a small risk of its own, since some plugins take their settings with them. A backup first makes that harmless.

Otherwise, a plugin the site does not use has no business being on the server.

The clean-up

  1. Make a backup of files and database first.
  2. List the plugins the site actually uses.
  3. Delete every inactive plugin not on that list.
  4. Delete unused themes, keeping one default and any parent.
  5. Remove old copies of the site from the server.
  6. Update everything that remains.
  7. Repeat the check after every redesign.

Step five usually finds the most, because a copy of the old site is a complete WordPress installation that nobody has updated since the day it was replaced.

Active plugins that have quietly stopped receiving updates are covered in plugins removed from the WordPress directory.


Frequently asked questions

Is a deactivated plugin still a security risk?

It can be. Its files stay on the server, and some can run when requested directly by address, so a known flaw in one can still be used.

Why do inactive plugins fall behind on updates?

People skip updates for plugins that are switched off, and plugins closed in the directory get none at all. They tend to be the oldest code on a site.

What should I keep when cleaning up themes?

One current default theme as a fallback, plus the parent of your active theme if it is a child theme. Delete everything else.

Will deleting a plugin lose its settings?

Sometimes. Some plugins remove their stored data when deleted and others leave it behind, so note any settings worth keeping and take a backup first.

Where else do old files hide?

In copies of the previous site left in folders named old, test or dev. Each is a complete, unmaintained WordPress installation sitting beside the real one.

When is deactivating a plugin the right move?

While troubleshooting, when plugins are switched off one at a time to find a fault. Once it is found, delete anything the site no longer needs.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Old plugins and themes still on the server?

Tell us where the site is. We will compare what is installed with what is used, and say what should go.

Start a Conversation