The official RC3 notice reports more than 90 updates and fixes since RC1, split across Editor and Core. That number is useful as a warning about change volume, but it is not a test plan. A site-specific matrix should map its block usage, content types, REST clients, cron jobs, media stack, plugins, theme, cache, and business journeys to the changed surfaces most likely to matter.
Use this for WordPress engineering teams, plugin vendors, theme developers, QA leads, and agencies that need broad coverage without pretending every core ticket has equal risk for every site.
Quick answer
Start with the site's actual feature inventory, then group tests into Editor, rendering, media, REST, data, authentication, cron, cache, accessibility, and integration lanes. Give each lane a stable fixture, expected result, owner, baseline, and severity. Add targeted tests for the RC3 security backport and any core tickets that touch installed components. Use change volume to widen coverage, not to create vague testing.
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 |
|---|
| Editor | Common and complex post fixtures | Save, reload, preview, publish, and frontend match |
| Core data | REST, options, metadata, cron, and revisions | No schema, timing, or permission drift |
| Media | Role-based image and PDF fixtures | Uploads and derivatives match policy |
| Integrations | Forms, checkout, email, webhooks, and cache | One expected business outcome |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Convert the site inventory into named regression lanes. | Inventory blocks, templates, content types, custom fields, REST consumers, scheduled tasks, media workflows, roles, plugins, theme features, and caches. | Editor and Core lanes reflect features actually used by the site. |
| Add stable fixtures and expected results to every critical and high-risk lane. | Map each inventory item to Editor or Core surfaces mentioned in the RC3 milestone and component lists. | Critical tests include permissions, data integrity, retries, and side effects as well as visible output. |
| Run baseline and RC3 tests under matching cache, role, and data conditions. | Rank lanes by customer impact, data loss, security boundary, revenue, publishing frequency, and rollback difficulty. | RC3 results are compared with the same fixture and environment baseline. |
| Isolate failures to core, plugin, theme, hosting, or integration ownership. | Choose reusable fixtures and capture the current production or RC2 result before installing RC3. | Failures and not-applicable decisions have owners and supporting evidence. |
What to check first
- Inventory blocks, templates, content types, custom fields, REST consumers, scheduled tasks, media workflows, roles, plugins, theme features, and caches.
- Map each inventory item to Editor or Core surfaces mentioned in the RC3 milestone and component lists.
- Rank lanes by customer impact, data loss, security boundary, revenue, publishing frequency, and rollback difficulty.
- Choose reusable fixtures and capture the current production or RC2 result before installing RC3.
- Track pass, fail, blocked, not applicable, owner, evidence, and retest build in one matrix.
Field notes
- Mark a test not applicable only after recording why the component cannot be reached on the site.
- Keep the baseline artifact and fixture ID beside the RC3 result so visual or behavioral differences are reviewable.
- Use failures to improve the evergreen matrix for future releases instead of discarding the evidence after 7.1.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
lane,surface,fixture,risk,baseline,rc3,owner
editor,patterns,landing-hero,high,pass,pass,content
core,cron,renewal-job,high,pass,pass,platform
media,pdf-preview,guide-42,medium,pass,review,editorial
integration,checkout,guest-card,critical,pass,pass,commerce
Why this usually happens
- Release notes describe project-level change while teams need site-level risk translation.
- A broad smoke test can pass even when a rare but valuable publishing or checkout fixture breaks.
- Ad hoc QA repeats easy visual checks and neglects permissions, scheduled work, retries, and data integrity.
Decision rule
The matrix is ready when every critical business and security surface has a fixture, expected result, owner, baseline, and retained evidence. A raw ticket count or homepage check cannot substitute for that coverage.
Production verification checklist
- Editor and Core lanes reflect features actually used by the site.
- Critical tests include permissions, data integrity, retries, and side effects as well as visible output.
- RC3 results are compared with the same fixture and environment baseline.
- Failures and not-applicable decisions have owners and supporting evidence.
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.
- Convert the site inventory into named regression lanes.
- Add stable fixtures and expected results to every critical and high-risk lane.
- Run baseline and RC3 tests under matching cache, role, and data conditions.
- Isolate failures to core, plugin, theme, hosting, or integration ownership.
- Retain the matrix for final-release and future maintenance testing.
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, build a WordPress regression matrix.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references