A business owner does not want to approve a WordPress update. They want their site to keep working and to hear about it when it does not.
This is the third article on our security update process. The first covered the routine path and the second covered the sites that needed real work. This one is the end client’s side. A reseller partner runs the process for their clients, and each client picks how involved they want to be.
What Every Client Gets
Whichever mode a site uses, the client receives the same two emails.
- A week before: a notice that updates are coming, with the date. That is the time to mention a launch, a sale or a developer who is mid-project.
- Afterwards: one email per site, with a link to the before-and-after screenshots of the site’s test pages. “What changed on my site?” has an answer they can look at.
Every update also runs on a fresh staging copy first, in every mode. The modes only change what happens between staging and live.
The Four Modes
| Mode | What happens after staging | Suits | Share of the last 255 updates |
|---|---|---|---|
| Auto-approve | Screenshots compared, goes live if nothing looks wrong | Brochure sites, most small businesses | 144 |
| Review | A person checks the screenshot comparison, then it goes live | Shops, booking forms, anything where layout costs money | 0 |
| Wait | Stops on staging until the client says go | Custom checkouts, membership areas, sites the client tests themselves | 85 |
| Decline | Skipped this round | Sites with development work in progress | 26 |
Auto-approve
The update runs on staging, the screenshots are compared, and if nothing looks wrong it goes live. The client gets the completion email afterwards.
This is the most common setting, 144 of the last 255 updates, and the right one for most brochure sites. The screenshots still exist and the client can look at them. They just do not have to before the site is patched.
Review
Same staging run, but a person looks at the comparison before it goes live. This suits sites where a broken layout costs money, like a shop or a booking form. The person reviewing should know what the pages are supposed to look like. That is the reseller, or the business itself when it hosts with us directly.
Wait
The update runs on staging and stops there until the client says go. This is for sites where the client wants to test something themselves first: a custom checkout, a membership flow, an integration with another system.
85 of the 255 updates were set to wait. It is a legitimate choice, and it is also the mode that needs the most care. A site waiting for an answer is still running the old code, and a security update that is not applied does not fix anything. The rule we are moving to is that every wait gets a date, after which the update either goes live or becomes a conversation.
Decline
Skip this round. 26 updates were declined, usually because a developer had work in progress that the update would collide with.
Declining a month is fine. Declining every month would leave the site unpatched, and in practice it does not happen.
The Mode Can Change Each Month
The mode is set per site, and it is not permanent. A shop might run auto-approve all year and switch to review in the week before a big sale. A site in the middle of a rebuild might decline for two months and go back to auto-approve once the new version is live.
The setting a site starts with is a default, not an outcome. What matters is whether each month’s update reached the live site, and the completion email answers that for each site.
The Useful Question
The question clients usually ask is “do I trust automatic updates?” It is the wrong question, because every mode here tests on staging first.
The useful question is: how much do you want to see before it goes live? For most sites the answer is “nothing, just tell me afterwards”. For a few it is “everything”. Both are fine, as long as the update still happens.
