A WordPress security update can succeed on the primary origin while an old container image, secondary region, cron worker, preview host, staging environment, or manually restored instance remains behind. The risk is higher when ImageMagick and Ghostscript packages differ by host. Patch parity requires an inventory that joins application version, server package state, deployment source, traffic reachability, and cache behavior.
Use this for agencies, managed hosts, multisite operators, containerized WordPress, autoscaling groups, blue-green deployments, and any organization that updates many WordPress environments from more than one source.
Quick answer
Build a fleet table with environment, public host, origin, WordPress version, image digest, PHP Imagick state, Ghostscript version, deployment timestamp, last request, and owner. Patch the deployment source before replacing instances, remove stale origins from traffic, invalidate only affected pages after version parity is proven, and alert when a reachable host reports a version below the approved baseline.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Primary origin | Normal public request | Fixed version and expected build digest |
| Autoscaled replacement | New instance from current image | Fixed version before receiving traffic |
| Restore test | Recent backup restored in isolation | Update automation reaches approved baseline |
| Stale route | Secondary hostname or origin | Removed, blocked, or patched |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Patch the canonical deployment artifact and record its immutable digest. | Enumerate DNS, load balancer targets, containers, virtual hosts, scheduled workers, staging sites, preview hosts, and disaster-recovery copies. | Every public route resolves to a runtime at the approved WordPress baseline. |
| Replace or patch every reachable runtime and remove stale targets from traffic. | Collect WordPress core version, package digest, PHP extension list, Ghostscript version, operating-system image, and last deployment for each runtime. | New autoscaled and restored instances start patched before health checks admit traffic. |
| Update restore, backup, and environment-bootstrap automation to the fixed baseline. | Send a harmless version or health probe through every public route and compare it with direct origin evidence. | Imagick and Ghostscript package state matches the platform policy for each role. |
| Document short-lived exceptions with network isolation, owner, compensating control, and expiry. | Check whether deployment pipelines, golden images, backups, and restore automation still contain the old WordPress package. | Exceptions are isolated, owned, time-limited, and visible in the next parity report. |
What to check first
- Enumerate DNS, load balancer targets, containers, virtual hosts, scheduled workers, staging sites, preview hosts, and disaster-recovery copies.
- Collect WordPress core version, package digest, PHP extension list, Ghostscript version, operating-system image, and last deployment for each runtime.
- Send a harmless version or health probe through every public route and compare it with direct origin evidence.
- Check whether deployment pipelines, golden images, backups, and restore automation still contain the old WordPress package.
- Record cache keys, origin selection, health status, owner, approved exception, and expiry for any runtime that cannot update immediately.
Field notes
- Use a signed or authenticated inventory endpoint when version disclosure would create risk.
- Keep unreachable archives offline rather than exposing an unpatched restore for convenience.
- Separate WordPress core parity from Imagick and Ghostscript package policy so ownership is clear.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
environment,host,wp_version,image_digest,imagick,ghostscript,reachable,owner
prod-a,origin-a,7.0.4,sha256:a14,yes,10.04,yes,platform
prod-b,origin-b,7.0.4,sha256:a14,yes,10.04,yes,platform
staging,stage,7.0.3,sha256:992,yes,9.56,no,engineering
Why this usually happens
- Teams patch mutable production storage but forget the immutable image that creates the next instance.
- A dashboard may query one site URL even when traffic can reach several origins.
- Database restore and file restore procedures can silently reintroduce an older core package after the security window closes.
Decision rule
The fleet is compliant only when every reachable runtime and every artifact capable of creating a reachable runtime meets the approved baseline. An isolated archive can remain offline, but it must be patched before any future network access.
Production verification checklist
- Every public route resolves to a runtime at the approved WordPress baseline.
- New autoscaled and restored instances start patched before health checks admit traffic.
- Imagick and Ghostscript package state matches the platform policy for each role.
- Exceptions are isolated, owned, time-limited, and visible in the next parity report.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Patch the canonical deployment artifact and record its immutable digest.
- Replace or patch every reachable runtime and remove stale targets from traffic.
- Update restore, backup, and environment-bootstrap automation to the fixed baseline.
- Document short-lived exceptions with network isolation, owner, compensating control, and expiry.
- Run the parity probe on a schedule and alert on version, package, image, or reachability drift.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not treat a green screen, successful request, or quiet log as proof that the customer outcome is correct.
- Do not leave debug logs, broad credentials, test orders, temporary roles, or firewall exceptions active after verification.
- Do not close the work without recording versions, fixture IDs, UTC timestamps, owner, result, and rollback point.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, cache, data shape, roles, integrations, and server packages. Finish with one controlled production fixture when the result depends on real email routing, edge cache, crawler access, payment callbacks, or advertising diagnostics.
What evidence should be retained?
Keep the smallest useful evidence set: exact versions, stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, decision, and final verification. Redact customer data, secrets, order keys, and full click identifiers.
When should the change be rolled back?
Roll back when a revenue, privacy, security, publishing, or lead path fails and the cause cannot be isolated inside the approved maintenance window. Preserve the failed fixture before rollback so the next attempt starts with facts.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, audit WordPress patch parity.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references