Check each plugin's last update date and the WordPress version it was tested with. Anything untouched for two years should be replaced, removed, or rebuilt properly, because an abandoned plugin is the usual way into a small WordPress site.

The plugin list nobody reads

Open the plugins screen on a WordPress site that has been running for five years and count. Twenty is common. So is a plugin last updated in 2016.

Most were installed for a reason at the time: a slider for the home page, a gallery, a form, sharing buttons, a fix for something that went wrong once.

Some are still in use. Some were switched off years ago and never deleted. A few come from authors who stopped working on them long ago.

Those last ones matter far more than their number suggests.

How small sites actually get broken into

Small business sites are rarely attacked by a person. They are found by automated scanners working through millions of sites, looking for software with known flaws.

WordPress itself is a poor target, because its security fixes arrive quickly and install by themselves. Plugins are where the known flaws collect.

When a flaw is found in a maintained plugin, a fixed version usually follows quickly. When the plugin is abandoned, the flaw is published and never fixed, and every site running it stays open.

A plugin can even be withdrawn from the official directory over a security problem without the sites running it being told. It simply stops updating, which looks exactly like a plugin with nothing to update.

Spotting an abandoned plugin

The fifth is easy to miss. A plugin bought from a marketplace updates only while its licence is current, and the plugins screen does not always make it obvious that the updates have stopped.

Why old plugins hold the whole site back

PHP 7.0, the language version many WordPress sites run on, reaches the end of its security support today, ten days after PHP 5.6 did.

Plenty of small business sites are still on one of the two, and the reason is often a plugin. One written for PHP 5 breaks on a newer version, so the site is left where it is.

That makes an abandoned plugin a double problem. It carries its own unfixed flaws, and it keeps everything else on a version of PHP that no longer gets fixes either.

Removing it is often the step that lets the rest of the site move forward.

Deactivated is not removed

A plugin that has been switched off is not gone. Its files are still on the server, and some flaws can be reached directly, without the plugin being active.

So a deactivated plugin carries much of the risk of an active one and none of the benefit.

If something was switched off more than a month ago and nobody has missed it, delete it, after a backup. If it is ever needed again, a current version installs in a minute.

Three ways to deal with one you still need

Some abandoned plugins do something the business still relies on, and there are three choices.

Replace it with a maintained plugin that does the same job, chosen for recent updates, a long record of them, and an author still answering questions.

Remove the function, if it turns out nobody needs it. A sharing bar from 2014, or a slider on a page nobody visits, often belongs here.

Or have it built properly. Many small plugins do what a few lines of code added to the site could do, such as inserting a tracking snippet, and that takes one outside author out of the picture.

A worked example

A yoga studio's class timetable ran on a schedule plugin last updated in the spring of 2016.

The host had been emailing about PHP 5.6 since the autumn. A test switch to 7.2 had turned the timetable page into an error, so the switch was reversed and the emails were filed.

The site had twenty-two plugins. Six were deactivated, two did the same job as each other, and the timetable plugin's directory page warned that it had not been tested with recent versions of WordPress.

On a copy of the site, the six inactive plugins were deleted, the duplicate was removed, and the timetable moved to a maintained scheduling plugin.

With the old timetable gone, the copy ran cleanly on PHP 7.2, and the live site followed on a weekday morning.

Twenty-two plugins became fifteen, and nobody at the studio has missed any of the seven.

Fewer plugins is a security decision

Every plugin is code from a different author, updated on that author's schedule, with access to most of the site.

That is why the count matters, though not in the way it is usually argued. Fifteen well-maintained plugins can be safer than six neglected ones.

Each one is a standing obligation: somebody has to watch for its updates, read its notes, and notice when its author goes quiet. Fewer plugins means fewer authors whose bad year becomes yours.

Before adding one, ask whether the site really needs it, whether it is maintained, and whether whoever looks after the site will keep watching it.

The counter-case

An old plugin is not automatically a dangerous one.

Some small plugins are simply finished. One that adds two lines to the page header, has no settings screen, and touches no forms or uploads may have had no reason to change since 2016.

What a plugin can reach decides the risk. Anything handling forms, uploads, logins, payments or customer details needs an author who is still working; a cosmetic tweak is a much smaller exposure.

That judgement belongs with whoever maintains the site, plugin by plugin. The default still stands: if nobody can say why an old plugin is safe, replace it or remove it.

This month

  1. List every plugin, active or not.
  2. Note each last-updated date from its directory page.
  3. Delete everything deactivated a month or more ago.
  4. Remove what nobody uses any more.
  5. Replace anything untouched for two years.
  6. Have small jobs built into the site properly.
  7. Then plan the PHP upgrade.

Step three is the quickest and the most overlooked. Deleting inactive plugins takes minutes and removes code that can still be reached, even though nobody has used it in years.

Making those changes without breaking anything is covered in clicking update all on a Friday afternoon.


Frequently asked questions

How do I know a plugin is abandoned?

Its directory page shows when it was last updated and which WordPress version it was tested with. Two years without an update, or a warning banner, is the sign.

Why are abandoned plugins a security risk?

When a flaw is found in one, nobody releases a fix. Automated scanners look for exactly those known flaws, so every site running the plugin stays exposed.

Is a deactivated plugin safe to leave installed?

No. Its files remain on the server, and some flaws can be reached without the plugin being active. If nobody has missed it, delete it.

What do plugins have to do with PHP?

Old plugins often break on newer PHP versions, so sites stay on old ones. PHP 7.0 loses security support today, and 5.6 already has.

What should replace an abandoned plugin?

A maintained plugin that does the same job, nothing at all if the function is no longer needed, or a few lines of code built properly into the site.

Is having fewer plugins really safer?

Each plugin is code from a different author with access to most of the site. Fewer plugins means fewer authors to watch and fewer flaws to inherit.

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.

Twenty plugins and no idea which matter?

Send us the list. We will mark which are abandoned, which are unused, and what each one should become.

Start a Conversation