A June 23, 2026 Make/Core dev note says WordPress 7.1 hides the Classic block from the block inserter by default. Existing Classic blocks remain registered and editable, but staff who still create new Classic blocks need a decision before the update.
Use this for older WordPress sites with legacy content, newsletter templates, custom HTML workflows, TinyMCE-heavy editorial processes, or editors who rely on the Classic block inside the block editor.
Quick answer
WordPress 7.1 Classic Block Inserter Change should be handled with a narrow evidence-first workflow: find classic blocks, interview editors, test conversion, then verify the result before making broader changes.
What to check first
- Find posts and pages that already contain the core/freeform Classic block.
- Interview editors who still add new Classic blocks and document why they need them.
- Test Convert to Blocks on representative posts before bulk migration.
- Decide whether to re-enable the Classic block inserter with the documented filter for specific post types.
- Create rollback notes for templates, patterns, and editor training materials.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Find Classic blocks | Find posts and pages that already contain the core/freeform Classic block. | Existing Classic blocks can still be edited after the update. |
| Interview editors | Interview editors who still add new Classic blocks and document why they need them. | Editors know how to create content without the Classic block when possible. |
| Test conversion | Test Convert to Blocks on representative posts before bulk migration. | Any opt-in filter is limited to the post types that need it. |
| Decide filter | Decide whether to re-enable the Classic block inserter with the documented filter for specific post types. | No migration changes content without a reviewed backup. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp post list --post_type=post,page --format=ids | xargs -n1 -I % sh -c "wp post get % --field=post_content | grep -q 'wp:freeform' && echo %"
add_filter( 'wp_classic_block_supports_inserter', '__return_true' );
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Find Classic blocks
- Interview editors
- Test conversion
- Decide filter
- Update training
Production verification checklist
- Existing Classic blocks can still be edited after the update.
- Editors know how to create content without the Classic block when possible.
- Any opt-in filter is limited to the post types that need it.
- No migration changes content without a reviewed backup.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, 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, test WordPress 7.1 editor changes.
Update the plan with the final Classic block decision
The proposal changed before release. Use the WordPress 7.1 Classic block final-release audit to confirm it remains available, remove stale workarounds, and keep only migrations with an independent benefit.
Helpful references
Protect legacy posts with conversion fixtures
Before editors convert older content, use the WordPress 7.1 Classic block conversion regression test for galleries, shortcodes, embeds, captions, custom HTML, mobile output, accessibility, and revision recovery.