Plugin Updates: Automatic, Manual, or Staged
The argument over automatic updates treats all updates as the same thing. They are not. A sensible policy sorts them by risk and applies a different rule to each.
Turn automatic on for these
- Security releases of the core platform. The window between a public disclosure and mass exploitation is often measured in hours. Waiting for a human is the bigger risk.
- Minor point releases of the platform, which are almost always maintenance-only.
- Plugins from large, well-maintained vendors that do not touch checkout, forms, or layout.
Keep these manual and staged
- Anything that processes payments.
- Forms and lead capture.
- The theme and any page builder, where a change can move every layout on the site.
- Major version jumps, which are the ones that change how things work.
- Custom or heavily configured plugins where the settings are the value.
What staged actually means
Copy production to a staging site, apply the updates there, and click through the paths that matter: homepage, a service page, the contact form end to end, checkout with a test order, and the admin screens you use weekly. Then apply the same set to production and repeat the quick version of that test. The whole exercise is 20 minutes on a small site.
The safety net that makes any policy workable
Take a backup immediately before the update, not a nightly one from twelve hours ago. Know how to restore it. With a tested restore path, an update gone wrong is an inconvenience; without one, it is an outage of unknown length, which is why people stop updating at all and end up with the far worse problem.
A cadence that holds
Security patches immediately, everything else on a fixed day every other week, majors quarterly with a proper test. Write it down, put it on a calendar, and log what you applied and when. When something breaks three days later, that log turns an investigation into a two-minute answer.
