Classic Block Stays in the WordPress 7.1 Inserter

Two weeks ago I wrote about the plan to hide the Classic block from the WordPress inserter starting in 7.1. It was a scoped, filter-guarded change with a clear opt-out and a stated long-term goal of not loading TinyMCE unless a page actually needed it. On paper it read like the sort of quiet, sensible cleanup the block editor project has been doing since 2018.

On July 7, the same contributor who shipped the original change stood up and reversed it. The Classic block will remain in the WordPress 7.1 inserter, in the block library, and in the slash-command menu, exactly as it does today. No filter. No companion plugin. No visual deprecation notice. That is a rare thing to see this close to Beta 1, and it is worth reading carefully — because the interesting part is why.

I do not think of this as WordPress being indecisive. I think of it as the project doing something a lot of software teams talk about and do not actually do: shipping less when the shape of the problem changed underneath them. That is the frame for today’s post.

What is actually new

The Classic block stays in the inserter for WordPress 7.1 was posted on July 7, 2026 at 6:22 UTC by Marin Atanasov on Make/Core, tagged as a 7.1 dev note. It reverses the June 23 announcement that had promoted Gutenberg PR #77911 — originally merged in May 2026 as an experimental unwrap — into default WordPress 7.1 behaviour via Trac #65166 and wordpress-develop changeset 62546.

Concretely, three things go away with the reversal. The wp_classic_block_supports_inserter filter that would have let sites opt back in has been removed from the 7.1 branch. Because the change never shipped in a stable WordPress release, there is no back-compatibility footprint — no filter to keep alive, no notice-and-shim cycle, no deprecation window. The companion Enable Classic Block plugin, which existed to restore the inserter entry, will be discontinued. And the block-level deprecation notices that were queued to display on Classic blocks in the editor are pulled out too.

The reasoning in Atanasov’s post is unusually direct: “this approach had things largely backward.” Hiding the block from the inserter did not make TinyMCE any less loaded — TinyMCE still ships with core and still gets registered whenever any existing wp:freeform content is present on a page. It just made the block harder to reach for the people who are still using it because they need it, without moving the actual goal one step closer.

The gaps that came up in comments on the June 23 post and in the surrounding Gutenberg tracking issue #78067 are worth naming, because they are the same set the Classic block has been quietly plugging for years. Table blocks still do not support cell merging or colspan/rowspan. The Paragraph and Heading blocks still do not have a Special Characters picker. Media alignment inside prose still cannot do the classic float-and-wrap layout without custom CSS. The “Convert to Blocks” tool, which is the migration path most posts about this feature assume everyone will just use, still has known content-integrity edge cases with shortcodes, embedded HTML, and complex inline formatting. None of those are new. All of them are exactly the reasons a working WordPress editor reaches for the Classic block in 2026.

The direction the post lays out for after 7.1 is not deprecation. It is fixing the “Convert to Blocks” tool so the migration is actually reliable, building a mass-migration mechanism for sites with thousands of Classic-block posts, and moving TinyMCE toward optional and on-demand loading through explicit dependency declarations so plugins that need the editor can ask for it and pages that do not can skip it. That is a longer road, but it is the road that actually removes the asset from the average page load, which is what the original hide-from-inserter change was reaching for and could not deliver.

Why it matters for WordPress / WooCommerce people

If you had already started planning around the hide-from-inserter change — writing a mu-plugin that flipped the filter for editors on your team, adding a note to your client onboarding docs, or building a training slide about “why Classic is going away” — you can stop. It is not going away in 7.1. Not with a filter, not with a deprecation notice, not with a nudge in the inserter. The status quo you have today is the status quo you will have on August 19 when 7.1 ships, and for the foreseeable dot-releases after that.

The bigger implication is for anyone doing content migrations off legacy WordPress installs. If you are moving a site with tens of thousands of Classic-block posts onto a new theme, the honest answer is that the “Convert to Blocks” tool is the piece to watch, not the inserter. That is the tool the July 7 post commits to fixing. Until it lands, the safe migration pattern is still the one experienced teams have been using: keep the legacy content as wp:freeform, convert incrementally as posts are edited, and do not run bulk convert-on-save scripts across an archive you have not fully proofed.

For WooCommerce stores, the practical read is simpler still. Product descriptions, order-received copy, terms and conditions, refund policy pages — anywhere your merchant edits long-form content, the Classic block was and is a valid tool, especially for the tables and inline formatting that block editor equivalents still do not cover cleanly. You do not need to write a migration plan around a change that just got pulled.

And there is a broader signal worth catching. This is the second visible reversal in the 7.1 cycle — real-time collaboration was pulled from 7.0 in May and is now in “strategic decisions pending” status for 7.1, per the 7.1 roadmap. The project is being unusually public about ship-less-than-planned decisions. That is healthy. It is also a reminder to not build production code against merge proposals until they have actually shipped in a beta.

What I would do (or not do) about it

Do not add the wp_classic_block_supports_inserter filter to anything you ship this quarter. It is gone from the 7.1 branch and it was never in a stable release. Any code that references it will do nothing on 7.1 and confuse the next developer who reads it. If you have already written a mu-plugin around it, delete it before it ships to production.

If your team was preparing training materials around “Classic block is deprecated in 7.1,” revise them now, before Beta 1 lands on July 15. The accurate framing for editors is that the Classic block is a supported, first-class option in WordPress 7.1 for the content it is genuinely better at — legacy content, complex tables, tricky inline formatting — and that the block editor is the default for everything else. That is a much easier message to teach than a soft deprecation you cannot fully explain.

If you are on the plugin side and you register TinyMCE plugins or depend on wp_editor(), this is a good week to audit how you declare that dependency. The direction of travel is toward TinyMCE loading only when explicitly requested. When that lands — and it will, on a slower timeline than the original hide-from-inserter plan — the plugins that already declare their dependency cleanly will keep working with no changes. The ones that rely on TinyMCE always being registered will need a code change. Add the dependency now, not the week after it becomes required.

And on the content migration side, the recommendation I have been giving clients for two years does not change: do not do bulk Classic-to-block conversions across an archive you have not read. Fix the “Convert to Blocks” issues that hit your specific templates, do the migrations post-by-post as content gets touched anyway, and accept that some old posts will stay Classic forever. That is a fine outcome. The block editor does not need to eat every paragraph in your archive to be worth using on new content.

The most useful sentence in the July 7 post, for me, is the one where Atanasov says the hide-from-inserter change made the experience worse “with no direct gain.” That is the sentence I want more merge proposals to be tested against — not just this one.