The fastest way to update a WordPress site is to tick every box and press the button. It is also the fastest way to end up with a broken checkout and fourteen suspects.
The problem with batch updates
When eleven plugins, two themes and core all move at once and something stops working, you have one symptom and no way to attribute it. The usual response is to roll everything back — including the ten updates that were perfectly fine — and start again more carefully. That is the good outcome. The bad one is that nobody notices for a fortnight, and by then the backup you would have restored has rotated out.
What a run actually does
Every CMSKeeper maintenance run follows the same order, every time:
- Health check. A site that is already broken does not get updated. There is no point layering changes onto an unknown state.
- Screenshots before. Every critical path, desktop and mobile, captured as a baseline.
- Backup. Database and files, before anything is touched.
- One update. Not the queue. One.
- Verify. Browser tests, checks inside the CMS, and a pixel comparison against the baseline from step two.
- Repeat from step four until the queue is empty.
Why the order is the whole point
Because when step five fails, there is exactly one candidate. The rollback is narrow: that one plugin goes back to its previous version and the rest of the queue continues. The site ends the night more up to date than it started, not less — and the one update that could not go in is named, in writing, with the reason.
Batch updating optimises for the machine’s time. Nobody is waiting on the machine at three in the morning. It should take the slow path.
