Enterprise Audit · Rollout · Rollback
WordPress 7.0
Readiness Checklist
An 80-point engineering deliverable for the May 20, 2026 release — server, plugins, custom code, headless surfaces, security, performance, rollout, and rollback runbook with sign-off.
- Target release
- WordPress 7.0 · 2026-05-20
- Document version
- 1.0 · Issued 2026-05-19
- Distribution
- Engineering · Platform Ops · Security · PMO
- Approval gates
- 4 sign-offs required (see page 9)
- Recommended start
- T−7 business days before update
- Estimated effort
- 16–28 engineering hours · single environment
Pre-flight Audit
T−7 to T−1 business days · read-only inspection · nothing in production changes
How to use this document. Each item is a tick-box readiness gate. Walk it section by section. Park unresolved items on a written remediation list and re-run the audit one business day before update. The four sign-off boxes on the final page should not be signed until every item above them is checked or explicitly accepted as a known risk.
Want 30 of these checks automated? We built a free WordPress plugin that runs the technical items in this document automatically — visual readiness score, color-coded findings, four one-click autofixes, and plugin-directory snapshots before any update. The plugin handles the verifiable items so you can focus on the human-judgment ones in this document.
Get the free plugin →
01Server & infrastructure
Verify the runtime can host WordPress 7.0 before any plugin or code work begins.
- PHP CLI version is 7.4 or higher (PHP 8.3 or 8.4 recommended). Run
php -v on the host.
- PHP web SAPI version matches the CLI. A CLI/SAPI mismatch is a common cause of "works on staging, breaks in production" failures.
- Database version is MySQL 8.0+ or MariaDB 10.6+. Run
SELECT VERSION();
- OPcache enabled with
opcache.memory_consumption=128 or higher. Verify via opcache_get_status(); revalidation strategy documented.
- PHP-FPM pool topology documented. Note whether the vhost runs a dedicated pool or shares a master — affects how opcache is reset post-upgrade.
- WAF rule set updated for WordPress 7.0; learning mode enabled for the first 48 hours if you front the admin with strict rules.
- CDN cache-key strategy reviewed;
/wp-admin/ and /wp-login.php bypass page cache.
- Object cache (Redis or Memcached) reachable; flush command documented and tested.
- Cron daemon healthy; no stuck jobs older than 1 hour in the queue (
wp cron event list --due-now).
- Disk space at least 3× the size of
wp-content/uploads available for snapshot retention.
02Backups & disaster recovery
An untested backup is a hope. The rollback only counts if it has been run.
- Full server snapshot (files + database) taken within the last 24 hours.
- Backup restored on a sacrificial environment within the last 30 days — boot verified.
- Off-site backup copy exists (object storage, separate region or provider).
- Database dump uses
--single-transaction for InnoDB consistency.
- Recovery Time Objective (RTO) documented and tested within the last quarter.
- Rollback runbook reviewed, dated, and accessible to the on-call rotation.
03Plugin & theme audit
The single largest source of post-upgrade incidents. Skip nothing.
- Full plugin inventory exported:
wp plugin list --fields=name,version,update,status --format=csv
- Each active plugin's changelog read for an explicit WordPress 7.0 compatibility statement (typically last 30 days).
- Inactive plugins flagged for removal; nothing inactive ships to production after the upgrade.
- Premium plugin licenses current; vendor account access verified for emergency support.
- Active theme: 7.0-compatible release confirmed (block themes typically follow core).
- Page builders confirmed 7.0-ready: Elementor, Divi, Beaver Builder, Bricks, Oxygen.
- SEO stack current: Yoast SEO or Rank Math on the latest stable.
- ACF Pro 6.8.1+ installed. 6.8.1 shipped the Image-field fix for the WordPress 7.0 release candidate.
- WPGraphQL + WPGraphQL ACF compatibility confirmed (headless deployments).
- WooCommerce on the latest stable; HPOS (High-Performance Order Storage) sync state verified if enabled.
- Cache plugins (WP Rocket, W3 Total Cache, LiteSpeed) bumped to their 7.0-tested releases.
04Custom code static scan
Grep the active theme and every custom plugin for the breaking-change surfaces.
- Grep for
WP_List_Table consumers. DataViews replaces the classic list-table on Posts, Pages, and Media.
- Grep for
manage_posts_columns, manage_posts_custom_column, bulk_actions-* hooks. Not fully integrated with DataViews in 7.0.
- Grep for
groupByField — renamed to groupBy object in 7.0 DataViews.
- Grep for
effect( in Interactivity API contexts — renamed to watch().
- Grep for
state.navigation.hasStarted / hasFinished — replaced by watch(() => state.url).
- Grep
block.json for apiVersion: 2 — bump to 3 and verify iframed editor render.
- Grep for
add_theme_support('html5', ['script'] — deprecated in 7.0.
- Grep block JavaScript for direct
window / document access. Refactor to useRefEffect for iframed-editor safety.
- Grep for
add_meta_box( on collaboration-bound CPTs. Classic meta boxes disable RTC for that post type once collaboration ships in a later release.
- Static type-check + lint (PHPStan / Psalm) passes against the active theme + custom plugins.
05Headless & API surfaces
Skip this section if WordPress renders your front end directly.
- Every WPGraphQL query consumed by the front end traced and validated against the 7.0 release candidate.
- Every REST endpoint consumed by mobile or partner integrations exercised on RC.
- Custom REST routes (
register_rest_route) still register correctly post-upgrade; signatures unchanged.
- ISR / on-demand revalidation webhook tested end-to-end against RC (e.g.
/api/revalidate?tag=settings).
- Front end's image-domain allowlist (e.g.
next.config.js remotePatterns) covers the WordPress media domain.
- GraphQL introspection schema diffed between 6.9 and 7.0; consumer-breaking changes flagged.
06Multisite, SSO & RBAC
Skip this section if you run a single WordPress site without external identity.
- Network admin customizations grep'd for
WP_List_Table dependencies.
- Custom role / capability mappings documented; export to fixture file.
- SSO plugin (SAML, OIDC, Okta, Azure AD, Auth0) tested on the 7.0 release candidate.
- Default-role behavior reviewed;
default_role_dropdown_excluded_roles filter applied if you customize.
- Multisite spam-flag behavior change reviewed. Sites no longer auto-flagged when their user account is flagged as spam.
- Per-tenant white-label theme overrides verified.
07Security & compliance
The AI Connectors surface is new in 7.0 and deserves its own policy decision.
- AI Connectors policy drafted and signed off before 7.0 ships.
- Allowed AI providers documented (default: none until DPA signed). Settings > Connectors locked down via capability filter.
- Audit-log plugin writes verified through both
add_meta_box and the new register_post_meta + REST path.
- SOC 2 / HIPAA / FedRAMP evidence pre-collected: change ticket, approval emails, runbook, restore test.
- PII handling unchanged; no new data egress paths opened by the upgrade.
- Plugin supply-chain hygiene: every active plugin's authorship verified; no abandoned or sold-on plugins.
- 2FA enforced for all Administrator-tier users.
08Performance baseline
Capture pre-upgrade metrics. You'll re-measure post-upgrade against the same set.
- Lighthouse scores (LCP, INP, CLS) captured on 5 representative public pages.
- TTFB captured for the same 5 pages from at least two geographic regions.
- Admin AJAX response times captured for Posts, Pages, Media list views.
- Object cache hit rate captured (Redis
INFO stats).
- Database slow-query log reviewed; pre-existing slow paths noted.
- Synthetic uptime monitor's pre-upgrade baseline captured.
09Stakeholder communication
An upgrade nobody knows about becomes an incident.
- Maintenance window communicated to all stakeholders at least 5 business days in advance.
- Status page entry pre-drafted (scheduled maintenance + duration estimate).
- On-call rotation confirmed; primary + secondary engineer paged-in for the window.
- Customer-success team briefed on the AI Connectors policy in case clients ask.
- Editorial team briefed on the new DataViews admin interface (Posts / Pages / Media).
Engineering note. WordPress 7.0 ships with the WP AI Client — a provider-agnostic API for OpenAI, Anthropic, and Google models — but no AI features are enabled by default. The Connectors UI is admin-only and opt-in. The risk is not that AI will be on; the risk is that one Editor with the right capability and a credit card can change your exposure profile overnight. Write the policy before May 20.
Rollout Day
T−24 hours through T+1 hour · sequenced, no improvisation
10T−24h checks
- Final RC test on staging passes; smoke-test report attached to change ticket.
- All plugin updates current on staging; no pending update notifications.
- Maintenance window communication re-confirmed.
- Backup taken within the last 12 hours; restore checksum verified.
- On-call rota confirmed; war-room channel created.
11T−0 execution sequence
Execute in order. Do not skip a step. Time-box each step at 5 minutes; escalate if any step exceeds.
- Take pre-flight snapshot of files and database.
tar + mysqldump --single-transaction. Verify md5sum of both artifacts.
- Enable maintenance mode.
wp maintenance-mode activate.
- Update WordPress core.
wp core update --version=7.0.
- Run the database schema update.
wp core update-db.
- Update plugins to their 7.0-tested releases (queued in pre-flight).
wp plugin update --all.
- Flush PHP opcache.
kill -USR2 <fpm-master-pid> — or hit an opcache_reset() shim for shared-pool FPM contexts.
- Flush object cache.
wp cache flush.
- Flush page cache (WP Rocket / W3 Total Cache / LiteSpeed Cache CLI command).
- Flush CDN cache (Cloudflare / Fastly / Akamai API call or dashboard purge).
- Disable maintenance mode.
wp maintenance-mode deactivate.
- Smoke-test 5 critical public pages: verify rendered HTML body, not just HTTP 200.
- Smoke-test admin login + 3 critical
wp-admin paths (Dashboard, Posts list, Media library).
Critical gotcha. Plesk, nginx, and most LB layers will happily return HTTP 200 on a broken page where PHP fatal-errored or WordPress white-screened. Always verify the rendered body of critical pages contains expected content — not just that the status code is green.
Verification & Rollback
T+1 hour through T+24 hours · objective gates, not gut feel
12T+1h verification
- Lighthouse re-run on the same 5 pages; LCP, INP, CLS within ±10% of baseline.
- Error log scan: zero new fatal errors in the last 60 minutes.
- PHP notice / warning rate within 2x of baseline.
- WAF dashboard reviewed: no false-positive lockout spike on admin AJAX.
- Object cache hit rate within 5% of baseline.
- Admin REST API calls succeeding (DataViews is REST-heavy under the hood).
- For headless: front-end ISR cache refreshed; tag-based revalidation working.
13T+24h stabilization
- No new error-log spikes overnight; cron events firing on schedule.
- Zero support tickets attributable to the upgrade.
- Performance baseline holding (or improved) on representative pages.
- Editorial team smoke-tested: post create / edit / schedule / publish all work.
- Comment moderation queue accessible and functioning.
- Auto-update behavior reviewed; core auto-update re-enabled if previously paused.
14Rollback trigger criteria
If any trigger fires, execute the rollback procedure within 30 minutes of detection.
- Fatal error rate > 0.5% of requests over a 10-minute window.
- Admin completely inaccessible to all users (not a single user with a stale cookie).
- Critical plugin behavior regression with no available patch within 4 hours.
- Data integrity issue: corrupted writes, missing fields, or wrong type stored.
- Security regression: auth bypass, privilege escalation, or data exposure.
15Rollback procedure
- Declare rollback in the war-room channel; page secondary engineer.
- Enable maintenance mode.
wp maintenance-mode activate.
- Restore files from the pre-flight snapshot.
- Restore database from the pre-flight snapshot.
- Flush opcache, object cache, page cache, and CDN cache in that order.
- Verify 5 critical pages render (the same set used in the rollout smoke test).
- Disable maintenance mode.
- Document the trigger, root cause, and remediation plan in the change ticket within 24 hours.
Closing the Change
Documentation, evidence, and the runbook your team owns next time
16Documentation & evidence
- Upgrade summary written: what changed, when, who approved, who executed.
- Compliance evidence packaged: change ticket, approvals, smoke-test report, restore test, post-upgrade verification.
- Stakeholder communication sent: "we're live on WordPress 7.0".
- Plugin compatibility ledger updated: each plugin's tested version + re-test date.
- Status page entry resolved; maintenance window closed.
- Runbook archived in version control; next quarter's re-test scheduled.
17Lessons-learned review
- Blameless retrospective scheduled within 5 business days of the change.
- Any in-flight remediation items captured as engineering backlog tickets.
- Time-tracking captured: actual hours vs. estimate (16–28h benchmark).
- Improvements to this checklist documented for the next major release.
18Forward planning
- Next WordPress major (7.1, planned August 2026) added to the engineering roadmap.
- Real-time collaboration evaluation scheduled when it ships in a later release.
- AI Connectors policy reviewed quarterly; vendor DPA refresh on the calendar.
- Plugin compat ledger reviewed monthly; abandoned plugins replaced before they become emergencies.
The runbook is the durable deliverable. The next time WordPress ships a major, this entire process should be repeatable from the runbook alone — without re-learning what was discovered the hard way this round. Treat that as the success metric.
Sign-off
Four approvals required before the change ticket is closed
By signing below, each approver confirms that the items in their domain on pages 2–8 have been verified or explicitly accepted as a known risk. Outstanding items must be listed in the comments section of the change ticket.
Engineering Lead
SignatureDate
Platform Operations
SignatureDate
Security & Compliance
SignatureDate
Product / PMO
SignatureDate
Change ticket reference:
Date upgrade executed:
Total elapsed time (T−0 through verification):
Engage Champlin Enterprises to run this for you.
We engineer safe, staged, fully documented WordPress 7.0 upgrades for enterprise teams — audit, remediation, staged rollout, and the runbook your team owns next time. Three engagements a quarter, by application.
Apply for an engagement →
Sprint engagements start at $10K per environment. Multisite networks, multi-environment estates, and headless stacks are scoped per project.