Some clients get nervous about updates. Some don’t. Most don’t really care. Fact is that a plugin update can (and has) taken a site down and if nobody is quite sure what the last person installed then the thing just sits there, looking fine from the outside, while the risk quietly grows.
Immediate release does not mean untested release
A good example is WordPress 7.1.1 was released on 17 September 2026. The official notes had 17 core bug fixes, editor fixes, 11 security issues. And claim that you had to UPDATE ASAP WordPress.org news.
Hosts like WP Engine and Pantheon treated it as a major security event, not a “when we get to it” delay. (Pantheon release note)
The right careplan or SLA service is neither “click update on production because the banner is orange” and it’s certainly not “leave it for a month until we have a 100% perfect test window.” The right answer is far more complex.
Big scary sites need a recovery point and a short list of journeys to check. WooCommerce, RevOps, CRMs, members, operational tools first of all need to be prepped for failure.
If your support plan cannot do that in days, it is not valid support. It is a retainer for when something is already on fire.
I have seen both of these failure actions on inherited sites. One client delayed a security release because the last plugin update had broken a forms formatting (!?). Another applied everything on a Friday with no staging and spent the weekend in ignorant bliss that their online forms were now just showing a [shortcode] script. Fun times.
A worst case plugin exploitation can happen even after a patch
So what about the Wholesale Lead Capture plugin for WooCommerce which was found to have an unauthenticated file-upload issue that opened up a PHP backdoor.
This was “fixed” in version 2.0.3.2 so why was it still being hammered months later? Security blog coverage explained that this was still making waves in June and late summer. (Bleeping Computer, WPScan). Ouch.
This is the new normal pattern:
- A commercial plugin was bought once a while ago
- The licence sits on an agency or freelancer account (or an employee)
- Auto-updates were turned off or just never worked in the first place
- The plugin handles a real business process (B2B registration, in this case), so nobody wants to touch it and just prays it keeps working
- The vulnerability scanner misses the issue and the risk grows for months before anyone notices
WooCommerce and WordPress did not fail here so much as ownership of the system did.
Onboarding should include a licence and dependency register. If we cannot name the owner of a truly critical plugin, we should treat that as a high priority finding not a footnote in a spreadsheet.
Loving what Kinsta are doing
The Kinsta’s API already covers a lot of interesting features and their direction is more into “programmable hosting”. I like this as it is useful for agencies that actually run sites (Kinsta API docs).
It’s a dumb name but “programmable hosting” will really help an agency for repeatable consistent deployments, seamless staging and gives an extra layer to the “Managed WordPress” product.
It is also a reason to treat hosting as part of the engineering system, not a line item on an invoice or just something the client needs to worry about.
System care is a process, not a bucket of hours
Anyway, a lot of WordPress “support” is still sold as a monthly number. That can work for small brochure sites. It falls over the moment the site is connected to sales, memberships, stock or a CRM.
The sort of care we look for looks like this:
- You know what is on the site and why
- You know who owns licences and hosting
- You can take a recovery and backup easily
- You can update without holding your breath
- You can tell a client, in writing, what was checked afterwards with a report
If your WordPress site is still from the dark ages then a rebuild can still be a good idea but it is also an expensive way to dodge the question of who is looking after the current system.
If you want a practical first step rather than a redesign by default, that is what the WordPress 5-Day Reliability Sprint is for.
What would actually have to be true before you trusted the next update on your site?
Leave a Reply