A newly merged change slated for WordPress 7.1 will make the insertion of Classic block unavailable from the block inserter by default, while preserving support for existing Classic blocks. Users who wish to continue inserting the block will be able to re-enable it through an opt-in filter.
Changes coming in WordPress 7.1
Marin Atanasov announced the change after a pull request was merged into the WordPress 7.1 codebase that hides the Classic block from the block inserter by default.
In the upcoming version, the Classic block (core/freeform) will no longer be available through the block inserter, block library, or slash commands. The change does not remove the block itself, however, as existing Classic block content will continue to function and remain editable. The update also does not affect the Classic Editor or the underlying TinyMCE experience, and sites that do not use the block editor will see no change.
Rather than removing existing functionality, the move is intended to steer new content creation away from the Classic block.
Classic Editor remains unaffected
Atanasov highlighted the scope of the change, noting that it is confined to the Classic block inside the block editor and does not impact the Classic editor itself, “ 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.”
The Classic Editor refers to the original WordPress editing interface used before the introduction of the block editor (Gutenberg). It remains available today as a plugin with over 9 million active installations, allowing users to continue working with the traditional editor experience.
The Classic block, by contrast, is a block within the block editor that embeds a legacy editing interface inside the modern block-based system. When used, it allows content to be edited in a way that resembles the pre-block editor experience, but within the block editor environment.
Opt-in option and plugin support
Atanasov wrote that the Classic block served as a transitional bridge from the pre-block era into the block editor, and that it is also the only Core block that does not operate like a standard block, “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.”
The change is part of a broader direction to reduce reliance on legacy content paths, as usage of Classic content has steadily declined over time. The intention is to stop new Classic content from being created so the existing footprint can gradually shrink.
He also pointed to ongoing maintenance overhead, noting that the Classic block often requires special handling across different parts of the block library and editor experience.
A filter is available for users who still want the Classic block to appear in the block inserter. The option is provided through wp_classic_block_supports_inserter, which allows the block to be restored if needed.
For users who prefer not to implement the filter manually, Atanasov has created the Enable Classic Block plugin, which provides the same functionality by automatically enabling the behavior.
Migration and future direction
Atanasov noted that work is continuing around the Classic block to make migration smoother for users as part of the broader direction of change.
An experimental deprecation and migration notice is currently being tested in Gutenberg. The feature surfaces a notice inside existing Classic blocks and offers one-click actions to convert content into blocks or move it into 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.”
Atanasov also highlighted parallel work on improving the surrounding editing experience, including the Custom HTML block, the Convert to Blocks flow, and related conversion and compatibility layers. The aim is to ensure that when migration is needed, the available tools are stable and complete.
Also, the GitHub tracking issue outlines a direction where the Classic block is expected to be fully removed from default availability and made opt-in only. This step is currently targeted for a future Gutenberg cycle, likely aligned with WordPress 7.2. In parallel, work is also expected to continue on making TinyMCE an opt-in dependency, further reducing reliance on legacy editor components within Core.
WordPress 7.1 is set to be released on August 19, during WordCamp US 2026.