We’ve just merged a change that will be part of WordPress 7.1 that hides the Classic block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. from the block inserter by default. The Classic block stays registered, every existing Classic block keeps working and remains editable, and a new filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. 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 The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/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 <!-- wp:freeform --> 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 A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. 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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. 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 Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. 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 Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase..

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