Classic block hidden from inserter; opted back in via…

We’ve just merged a change that will be part of WordPress 7.1 that hides the Classic block from the block inserter by default. The Classic block stays registered, every existing Classic block keeps working and remains editable, and a new filter lets anyone bring it back into the inserter. This post explains what changes, why, and how to opt back in if needed.

What’s changing

Starting in WordPress 7.1, the Classic block (core/freeform) no longer appears in the block inserter (#11712, Trac #65166, originally #77911 in Gutenberg). In practice, this means you can’t add a new Classic block from the inserter, the block library, or slash commands.

Nothing else about the block changes:

The Classic block remains registered.
All existing Classic blocks (including any  content) continue to render and stay fully editable, exactly as before.
The Classic editor and the underlying TinyMCE experience are untouched. If a post type doesn’t use the block editor, nothing here applies to it.

This is purely about steering new content away from the legacy Classic block, not about removing anything you already have.

To be clear: the Classic editor is not affected at all by this change. This is strictly about the Classic block inside the block editor. If you use the Classic editor (for example, via the Classic Editor plugin or on post types that don’t use the block editor), your experience stays exactly the same.

Why we’re doing this

The Classic block has been the bridge from the pre-block era into the block editor, and it has served that role well. But it’s also the one block in Core that doesn’t behave like a block:

Architectural consistency. Every other Core block is a node in the block tree. The Classic block is the lone exception, opaque HTML rendered through a separate editor embedded inside the block editor. Keeping it as a default inserter option works against the block-first model on which the editor is built.
Reducing the inflow. The migration path away from Classic content (Convert to Blocks) has existed for years, and Classic usage keeps shrinking. Hiding the block from the inserter stops new Classic content from being created, so that set keeps getting smaller rather than growing.
Maintenance leverage. Many block-library improvements have to special-case the Classic block. Each special handling may be small on its own, but cumulatively, this may slow down work that benefits every other block.

The broader, longer-term goal, which will be covered separately as it matures, is to make the Classic block fully opt-in and eventually to lay the groundwork for loading TinyMCE only when it’s actually needed. WordPress 7.1 is just the first user-facing step on that path. None of the later steps are happening in 7.1, and each will get its own discussion and dev note.

Opting back in

If you (or your users) still want the Classic block available in the inserter, there’s a dedicated filter: wp_classic_block_supports_inserter.

Return true to show it everywhere:

add_filter( 'wp_classic_block_supports_inserter', '__return_true' );

The filter also receives the post being edited, so you can make the decision conditional, for example, per post type:

add_filter(
	'wp_classic_block_supports_inserter',
	function ( $supports_inserter, $post ) {
		return 'page' === $post->post_type ? true : $supports_inserter;
	},
	10,
	2
);

If you’d rather not write code, there’s a small plugin that does exactly this, Enable Classic Block, which flips the filter on for you. The plugin has already been submitted for approval to the WordPress Plugin Directory.

Backward compatibility

This change is opt-out by design and doesn’t break anything:

No content is modified or migrated. Existing Classic blocks are left exactly as they are.
The block, its edit behavior, and the Convert to Blocks action all continue to work.
The core/freeform block remains registered, so any code that relies on it being present keeps functioning.
Restoring the previous behavior is a one-line filter (or one tiny plugin) away.

What’s next

Alongside this change, we’re investing in the surrounding experience so that moving away from the Classic block is smoother for everyone:

A deprecation/migration notice (experimental). There’s an experiment in Gutenberg that surfaces a notice inside existing Classic blocks, with one-click actions to convert the content to blocks or to a Custom HTML block. We’re exploring this as a gentle way to highlight that the Classic block is being phased out and to make the migration path more discoverable. It’s behind an experiment flag for now while we refine it for a WordPress release.
Improving everything around it. In parallel, we’re improving and fixing the pieces that live by the Classic block: the Custom HTML block, the Convert to Blocks path, freeform handling and conversion, and related compatibility layers. The goal is that by the time Classic content needs to move, the tools to move it are solid.

These, alongside other planned next steps, can be tracked in the dedicated tracking issue.

We’d love your feedback

This is an early step in a longer effort, and we want to get it right. If you maintain plugins or custom integrations, run large sites, or have workflows that depend on the Classic block, we’d really like to hear from you, especially around migration and bulk-conversion needs.

Props to @desrosj, @mamaduka, @mukesh27, @westonruter, @wildworks, and @yuliyan for the contributions, feedback, and code reviews.

Props to @mamaduka and @yuliyan for reviewing this post.

#7-1, #dev-notes, #dev-notes-7-1

Classic block hidden from inserter; opted back in via filter