Updating WordPress and Drupal safely: plugins, modules, and dependencies

Two kinds of sites get hurt by updates. The first never updates, and eventually gets compromised through a plugin or module with a published vulnerability. The second clicks "update all" on the live site and discovers that a customized plugin just lost its customizations. The safe path sits between them: update often, but never blind, and never first on production.

Know what you are running

Every safe update process starts with an inventory. For each plugin, module, and theme, record:

• The current version and whether it is still maintained upstream
• Whether anyone has modified its code (the highest-risk case)
• What it does and who on your team relies on it
• Whether it is commercial, and who holds the license

An inventory also exposes the plugins nobody can explain. Removing those is one of the cheapest security improvements available.

The customized plugin problem

If someone edited a plugin or theme file directly, the next update overwrites that edit. The site either loses a feature silently or breaks outright. The fix is structural: customizations belong in a child theme, a separate custom plugin, or, for Drupal, a custom module or a patch file applied by Composer. Until that is done, every update to a modified plugin needs to be tested specifically against the customization.

Drupal: Composer is the source of truth

Modern Drupal is managed with Composer. The composer.json file declares what the site needs, and composer.lock records the exact versions installed. Both belong in version control. A typical core update on a development branch looks like this:

composer update "drupal/core-*" --with-all-dependencies
drush updatedb
drush config:export

Then the change is committed, deployed to Test, and released with drush deploy, which runs database updates, imports configuration, and clears caches in the right order. composer audit lists installed packages with known security advisories.

WordPress: updates through code, not the dashboard

On a managed site, updates should arrive through version control rather than the dashboard. Setting DISALLOW_FILE_MODS in wp-config.php removes the update buttons from production entirely. Updates are applied on Dev or Test, for example with wp plugin update --all --dry-run to preview and then without it to apply, checked, committed, and deployed.

Security releases have a rhythm

• Drupal publishes security advisories on a regular weekly release window, and for the most serious core issues the Security Team announces the date in advance with a public service announcement. That gives you time to schedule the window before the details are public.
• WordPress core security releases are pushed automatically for minor versions, but plugins are where most WordPress vulnerabilities live. Watching advisories for the specific plugins you run matters more than watching core.

Critical vulnerabilities in widely used plugins are often exploited within days of disclosure, so the gap between "advisory published" and "patch live" is the number that matters.

A routine that works

1. Check for updates and advisories on a fixed schedule, weekly at minimum.
2. Read release notes for anything major: a new major version, dropped PHP support, or a changed API.
3. Apply updates on Dev, run database updates, and commit the result.
4. Deploy to Test and check the pages and features each update touches, plus login, search, and forms.
5. Take a backup point, deploy to Live in an agreed window, and verify.
6. Keep the previous release ready to redeploy if something appears later.

Security updates rated critical skip the wait for the regular window and go through an expedited version of the same steps.

Plan the big jumps

Minor updates are routine. Major versions (a new Drupal major release, a PHP upgrade, a plugin's version 2.0) need a plan: check compatibility of every module or plugin, estimate the custom code that needs changing, and schedule the work before the old version reaches end of life, not after.

Finally, remove what you do not use. Every inactive plugin or disabled module is still code on the server, and deactivated plugins can still contain exploitable files. Uninstall and delete anything that is not needed.

How eWay manages updates

eWay keeps a full inventory of plugins and modules, including which ones carry customizations, and tests every update in staging against those customizations before it reaches production. eWay tracks security advisories for each component you run, and critical WordPress plugin vulnerabilities are typically patched within 24 to 48 hours of a security release. A WordPress-specific WAF ruleset blocks known exploit patterns in the meantime, and file integrity monitoring flags unexpected code changes. Major-version upgrades get a written assessment of effort and risk before they are scheduled.

What to include in a support ticket

• The severity you would assign, P1 to P4 (see severity levels and response times)
• The plugin, module, or core version in question
• For a broken update: what changed, when, and what now fails

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: Dev, Test, and Live environments and Drupal security updates and patch cadence. More on our WordPress and Drupal pages.