A Plugin Update Policy That Survives More Than One Site
Plugin updates are a risk either way. Applying them blindly breaks sites; delaying them leaves known vulnerabilities open. The answer is not a rule, it is a routine — one that treats security updates differently from feature updates.
The short version
- Security updates go out immediately, on production, same day.
- Feature updates batch weekly and go through staging first.
- Major version updates are a scheduled task, never a routine one.
- Every update needs a rollback path you have actually used.
Classify the update before you apply it
| Type | When | Where first |
|---|---|---|
| Security release | Same day | Production, directly |
| Core minor | Automatic | Production, automatic |
| Plugin patch (x.y.Z) | Weekly batch | Staging |
| Plugin minor (x.Y.0) | Weekly batch | Staging |
| Plugin major (X.0.0) | Scheduled | Staging, with time booked |
| Core major | Scheduled, after 2 weeks | Staging |
Security updates: immediately, and that is the point
When a plugin ships a fix for an actively exploited vulnerability, the window between disclosure and mass scanning is hours, not days. Apply it on production directly. The risk of a regression is far lower than the risk of being one of the sites scanned that night.
To know which releases these are, subscribe to a vulnerability feed rather than relying on the update screen, which does not distinguish a security fix from a typo fix.
The weekly batch
1. Pull production to staging
A staging copy from last month tests nothing useful. Refresh it first.
2. Apply all pending patch and minor updates
All at once is fine here. If something breaks you will bisect, and bisecting five is quicker than testing five individually.
3. Walk the critical paths
Home, a post, a category, search, the main form, login, and checkout if there is one. Ten minutes.
4. Check the console and the error log
A silent JavaScript error is the most common symptom of a broken update.
5. Repeat on production
Same updates, same order, then the same ten-minute walk.
Major versions are a project, not a chore
A major version bump means the authors changed something intentionally. Read the changelog, look for a migration note, and book actual time. Doing it inside the weekly batch is how a routine turns into an outage.
Watch out
Never apply a major update to production on a Friday, and never immediately before you are unavailable. The problem is rarely the update itself; it is being unable to respond when something surfaces two hours later.
Rollback
Every update needs a way back. That means a backup taken immediately before the batch, retained for at least a week, and a restore procedure you have performed at least once on purpose. An untested restore is not a rollback plan, it is an assumption.
What to automate and what not to
- Automate: core minor updates, backups, uptime monitoring, vulnerability alerts.
- Do not automate: plugin updates on client sites, major versions, theme updates on a site with a modified theme.
- Borderline: plugin auto-updates on your own low-stakes sites, where the cost of a brief break is low.
Common questions
Should I enable plugin auto-updates?
On a personal site where a short outage is acceptable, yes. On anything a client or a business depends on, no — you want to be present when it happens.
How long should I wait before a major update?
Two weeks is a reasonable default for core. For plugins it depends on how central the plugin is; the more load-bearing it is, the longer you wait and the more carefully you read.
What if a plugin update breaks something and there is no rollback?
Install the previous version manually from the repository’s advanced view, which keeps old releases, then investigate on staging.
Sumit
Writes everything on TechMozz.