WordPress plugins and Drupal modules: choosing, updating, and removing them safely

A university's events calendar plugin has not been updated in three years. It still works, so nobody touches it. Then a security researcher publishes a flaw in it that lets anyone upload a file to the server, and within a week the site is serving spam pages to search engines. The plugin's author had moved on long ago, so no fix was coming. On WordPress and Drupal sites, most compromises start in add-on code like this rather than in the CMS core.

Why add-ons carry most of the risk

WordPress and Drupal core are reviewed by large security teams and patched quickly. The tens of thousands of plugins and contributed modules around them range from excellent to unmaintained. Each one you install runs with full access to your site and database. A single weak plugin is enough, and attackers scan for vulnerable versions of popular plugins within hours of a flaw being published. Every add-on is code you are trusting, so treat installing one as a decision, not a click.

Before you install: a five-question check

1. Is it maintained? Look for an update in the last few months and support questions that get answers.
2. Is it widely used? More active installs means more people finding and reporting problems.
3. What is its security history? Search the plugin or module name with "vulnerability." Past flaws that were fixed quickly are a good sign; flaws left open are not.
4. Is it covered by security review? On Drupal, prefer modules marked as covered by the security advisory policy. They get coordinated fixes and advisories.
5. Do you really need it? If the job is a few lines of code or something your theme already does, skip the add-on. Fewer add-ons means fewer things to patch.

Keep an inventory

You cannot patch what you do not know you run. Keep a simple list per site: each plugin or module, its version, why it is there, and who asked for it. Mark any that have been customized, because those need testing before every update. Review the list twice a year. The question for each entry is simple: is this still needed, and is it still maintained?

To list what a site runs:

wp plugin list --fields=name,status,version,update
drush pm:list --status=enabled --type=module

Updating without breaking the site

• Security updates first. Apply security releases within days; feature releases can wait for a planned cycle.
• Test in staging. Update in a non-production copy, check the pages and features that use the add-on, then deploy the same versions to production.
• No direct updates in production. Updates made from the admin dashboard on the live site skip testing and leave no record. Deploy through source control instead; see updating WordPress and Drupal safely.
• Never edit add-on code in place. Changes made directly to a plugin or module are lost on the next update. Customizations belong in a child theme, a custom plugin, or a patch file that is reapplied.

Removing what you do not need

A deactivated plugin is still on the server, and in many cases its files can still be reached and exploited. If something is not needed, uninstall it and delete its files. Watch for add-ons that are closed or removed from the official directory, because that often means an unfixed security problem. Replace abandoned add-ons with maintained ones, or with a small custom feature, before a flaw is published rather than after.

A note for government sites

Agencies often need to show what software a site runs and that it is kept current, for security reviews and audits. The inventory above, with update dates, is most of that evidence. Drupal government sites benefit from favoring modules covered by the security advisory policy, since advisories and fixes are coordinated and announced on a predictable schedule; see Drupal security updates and patch cadence.

How eWay handles add-ons

On sites eWay manages, direct updates are disabled in production and everything goes through source control and staging. eWay keeps an inventory of customized plugins and tests updates against those customizations. Core, parent themes, and commercial plugins are never edited; customizations live in child themes and custom plugins. eWay tracks published vulnerabilities per plugin, and critical WordPress plugin security patches are typically applied within 24 to 48 hours of a security release.

What to include in a support ticket

• The site, and the plugin or module name and version
• Whether you are asking for a security update, a new add-on review, or removal
• Any customization you know of, and the pages or features that depend on it

eWay customers can open a ticket in the support portal or email support@ewaycorp.com. Related reading: keeping servers patched and if your site is hacked: the first hour.