Classic Block Hidden from Inserter in WordPress 7.1

Twenty years of WordPress work teaches you that nothing in this project gets removed loudly. The Classic block, the one we have all quietly fallen back on whenever a third-party page builder leaked weird markup into a post, has been on a slow goodbye since the Gutenberg era began. This week the next step in that goodbye landed in trunk, and it is the kind of change that sounds small in the changelog and large the first time a non-technical editor cannot find a familiar button.

The short version: starting with WordPress 7.1, the Classic block is hidden from the block inserter by default. Existing Classic content still renders and stays editable. New posts will not let editors reach for the old TinyMCE box from the regular block library. There is a filter to bring it back. That is the entire policy.

If you maintain client sites with editors who still rely on the Classic block — and you know who you are — this is the change you need to plan for before WordPress 7.1 ships on August 19. Here is what is actually in it, and what I would do.

What is actually new

Marin Atanasov announced the change on Make/Core on June 23, 2026 in Hiding the Classic block from the inserter in WordPress 7.1. The core implementation landed the same day as wordpress-develop PR #11712 by tyxla, committed as changeset 62546 against Trac #65166. It ports the work from Gutenberg PR #77911, which had already shipped the same behavior in Gutenberg 23.1 back in May.

The behavior is precise. The Classic block (block name core/freeform) is no longer registered for the inserter, the block library, slash commands, or the conversion menu. Anyone trying to add a new Classic block through the editor UI will not find it. As the Make/Core post puts it, “all existing Classic blocks (including any <!-- wp:freeform --> content) continue to render and stay fully editable, exactly as before.” Nothing in the database is migrated. Nothing in already-published posts is touched.

If you have a real reason to restore the block, the contract is a single filter:

add_filter( 'wp_classic_block_supports_inserter', '__return_true' );

The filter receives the post object, so you can scope it by post type, by role, or by whether the post already contains a Classic block. The PR discussion is explicit that this is intentionally a scoped filter rather than a permanent register_post_type-style argument, because the goal is to discontinue the path eventually rather than maintain a public API for it.

This ships in WordPress 7.1, with Beta 1 on July 15 and the final on August 19, per the 7.1 roadmap.

Why it matters for WordPress people

For a developer reading the diff, this is small. For a site with two hundred editorial users and a habit of pasting Microsoft Word into the Classic block to keep their lives simple, this is a training event. Those are two very different conversations, and the second one is the one we will keep having for the rest of the year.

A few practical realities our team has lived through repeatedly:

• The Classic block is a habit, not a feature. Most editors who still use it do so because they were trained on TinyMCE between 2010 and 2018. They are not attached to core/freeform; they are attached to the experience. The Paragraph, Heading, List, and Quote blocks already cover almost everything they actually do.
• Word and Google Docs paste is the real dependency. What people miss is not the block, it is the forgiveness of pasting from a Microsoft document into the editor without thinking. Modern Gutenberg handles that paste path well, but the muscle memory of “drop everything into one big TinyMCE box first” dies hard.
• Existing posts are safe. Worth repeating, because it is the question we get within five minutes of explaining the change: nothing in your archive breaks. wp:freeform blocks already on the page continue to render and remain editable when an editor opens that post.
• The Convert to Blocks path still matters. If you have heavy legacy Classic content, the “Convert to blocks” action on existing Classic blocks remains the right cleanup path. It is now genuinely a one-way door, which is fine — that is the direction the platform is going.
• This is not the TinyMCE removal. TinyMCE is still in core. The Classic block is still registered. What is changing is discoverability for new content. The broader deprecation conversation lives in Gutenberg issue #78067, but that is a separate, longer arc.

What I would do (or not do) about it

If you are running an agency or maintaining a stack of client sites, here is the order we are working through internally:

• Do not enable the filter by default. It is tempting to drop add_filter( 'wp_classic_block_supports_inserter', '__return_true' ); into every mu-plugin and move on. Resist that. Each site you opt in is a site you are going to have to opt out again later.
• Audit which sites actually use it. A simple WP_Query against the last two years of content, looking for %<!-- wp:freeform -->% in post_content, tells you exactly which clients you need to talk to before July 15. Most agencies will be surprised how short this list is.
• For sites that genuinely need it, scope the filter narrowly. Restore the Classic block only for the post types and roles that need it. Pair that with a short internal note explaining that this is a temporary bridge, not a long-term position. We use the post object the filter passes to limit it to a single legacy post type on one client right now.
• Train editors before they panic. Twenty minutes with the Paragraph block and the paste-from-Word path covers ninety percent of what editors actually use the Classic block for. Show them once, and the question stops coming back.
• Use this as the excuse to clean up. If you have a backlog of half-converted Classic posts, run “Convert to blocks” on them now while the block is still visible in your editor’s own tools. Two months from now your editors will not see a button to do this anymore.

The pattern in WordPress core right now is consistent and, frankly, healthy: features that served the platform during the Gutenberg transition are being quietly retired in a way that does not break existing sites but does stop the bleeding for new content. Hiding the Classic block from the inserter is a textbook example. The diff is small. The cleanup it enables across the WordPress ecosystem is large.

Plan the editor conversations now. The code change you need is one filter, and most of you will not need it at all.