An early WordPress 7.1 proposal would have hidden the Classic block from the inserter. The final Field Guide states that the change was reverted, so the Classic block remains available. Teams using an old beta checklist may still remove workflows, install workarounds, or train editors around behavior that did not ship.
Use this for publishers, agencies, theme and plugin teams, training owners, and sites with Classic blocks, TinyMCE integrations, conversion workflows, or legacy content.
Quick answer
Update the release plan first: the Classic block remains available in WordPress 7.1. Remove any workaround that restores a block which was never removed in the final release. Then test existing Classic blocks, new insertion, conversion to blocks, Custom HTML alternatives, TinyMCE extensions, roles, patterns, revisions, save output, and public rendering. Keep migration work only when it improves the site independently of the reverted proposal.
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 |
|---|
| New insertion | WordPress 7.1 final | Classic block appears |
| Existing content | core/freeform fixtures | Editable and unchanged |
| Conversion | Convert to Blocks action | Lossless fixture result |
| Old workaround | Restore-inserter filter | Remove if no longer needed |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Replace beta assumptions with the final WordPress 7.1 Field Guide decision. | Record whether the rollout plan came from beta notes, the final Field Guide, a plugin advisory, training material, or a custom workaround. | The final release behavior matches the Field Guide on representative sites. |
| Disable release-only workarounds in staging and retest the exact content fixtures. | Verify Classic block insertion, existing block editing, conversion, revisions, previews, and public rendering under required roles and themes. | Existing Classic blocks remain editable and public output is unchanged. |
| Verify insertion, editing, conversion, roles, revisions, and public rendering. | Inventory filters, plugins, snippets, feature flags, documentation, and training added only to restore or replace the proposed behavior. | Unneeded filters, plugins, snippets, and training instructions are removed. |
| Update support scripts, documentation, and editor training with the final behavior. | Compare saved markup and TinyMCE extension behavior before and after WordPress 7.1 without forcing a migration. | Optional migrations preserve content, accessibility, revisions, and rollback evidence. |
What to check first
- Record whether the rollout plan came from beta notes, the final Field Guide, a plugin advisory, training material, or a custom workaround.
- Verify Classic block insertion, existing block editing, conversion, revisions, previews, and public rendering under required roles and themes.
- Inventory filters, plugins, snippets, feature flags, documentation, and training added only to restore or replace the proposed behavior.
- Compare saved markup and TinyMCE extension behavior before and after WordPress 7.1 without forcing a migration.
- Retain conversion work only where it has a separate accessibility, maintenance, design, or performance benefit.
Field notes
- Use the final Field Guide as the release source of truth.
- Do not mass-convert content merely to satisfy a change that did not ship.
- Preserve exact sample posts before testing conversion behavior.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture,source_plan,wp_version,new_insert,existing_edit,conversion,workaround,decision
CB-01,beta-note,7.1,visible,pass,pass,enabled,remove
CB-02,field-guide,7.1,visible,pass,review,none,keep
CB-03,training-doc,7.1,visible,pass,n/a,instructions,update
Why this usually happens
- Roadmap and beta proposals can be copied into production plans before final decisions land.
- Search results and internal tickets may keep the earlier proposal visible.
- A workaround can remain active after the behavior it targeted was reverted.
- Migration projects can mix a release requirement with a broader editorial improvement.
Decision rule
Do not deploy a Classic block workaround or mandatory migration solely because of the reverted WordPress 7.1 proposal. Require a separate tested reason for any content conversion.
Production verification checklist
- The final release behavior matches the Field Guide on representative sites.
- Existing Classic blocks remain editable and public output is unchanged.
- Unneeded filters, plugins, snippets, and training instructions are removed.
- Optional migrations preserve content, accessibility, revisions, and rollback 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.
- Replace beta assumptions with the final WordPress 7.1 Field Guide decision.
- Disable release-only workarounds in staging and retest the exact content fixtures.
- Verify insertion, editing, conversion, roles, revisions, and public rendering.
- Update support scripts, documentation, and editor training with the final behavior.
- Keep optional migration work only with its own evidence and owner.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, stable fixture IDs, current settings, and a reproducible baseline.
- Treating one successful browser screen as proof that queues, caches, providers, reports, roles, and downstream records agree.
- Deleting logs or identifiers before the failure boundary, business impact, rollback point, and accountable owner are known.
- Testing only an administrator session instead of the devices, roles, consent states, networks, and failure paths real users have.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a real customer, expose personal data, or change inventory. Perform destructive repairs, upgrades, cache-policy changes, and schema work on staging first. Promote only the smallest measured change with a current rollback point.
What evidence should the report keep?
Keep exact component versions, UTC timestamps, stable synthetic IDs, expected and actual results, queue or provider identifiers, the decision owner, rollback point, and final verification. Redact customer data, credentials, tokens, message content, addresses, and private infrastructure details before sharing evidence.
When is the task complete?
Complete the task when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context. Record any observation window that remains instead of calling a quiet test a permanent fix.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, root cause or current cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window is still open.
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, review a WordPress 7.1 upgrade plan.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references