WordPress 7.1 introduces a significant change for block editor users by hiding the Classic block from the inserter by default. This update continues the platform’s steady push towards a block-first editing experience, signaling a shift in how legacy content is managed within the block ecosystem.
- The Classic block remains registered and fully functional but is no longer visible in the block inserter by default in WordPress 7.1.
- This change encourages new content creation exclusively with modern blocks, reducing reliance on legacy editing methods.
- Existing Classic blocks and the Classic Editor plugin remain unaffected, ensuring backward compatibility.
- Developers and site owners can re-enable the Classic block in the inserter using a new filter or a small plugin.
- This move lays groundwork for future optimizations, including conditional loading of TinyMCE only when necessary.
What Happened
As part of the WordPress 7.1 release, the Classic block (also known as core/freeform) will no longer appear in the block inserter by default. This change was merged based on Trac ticket #65166 and Gutenberg issue #77911. The block remains registered within WordPress core, and all existing instances of the Classic block continue to work and remain editable without modification.
Users cannot add new Classic blocks through the inserter UI, block library, or slash commands, but the Classic Editor plugin and post types not using the block editor are unaffected. The change targets only the block editor’s interface, steering new content creation towards native blocks.
To accommodate workflows that still rely on the Classic block, WordPress 7.1 introduces a filter wp_classic_block_supports_inserter. This filter allows developers to opt the Classic block back into the inserter on a global or conditional basis, such as by post type. Additionally, a plugin called Enable Classic Block is submitted to the WordPress Plugin Directory to simplify this opt-in process for non-developers.
This update is the first step in a longer roadmap that aims to make the Classic block fully opt-in and optimize the loading of TinyMCE, the editor powering the Classic block, only when necessary. Alongside the invisibility change, experimental features in Gutenberg are testing deprecation notices and smoother migration flows to help users convert Classic block content into modern blocks.
Why This Matters
In production WordPress environments, the Classic block has long served as a transitional tool, bridging pre-block content editing with the block editor’s modern approach. However, it represents an architectural anomaly. Unlike other blocks, which function as discrete nodes in the block tree, the Classic block encapsulates opaque HTML managed by an embedded TinyMCE instance. This inconsistency complicates block editor maintenance and feature enhancements.
Removing the Classic block from the inserter reflects a deliberate push for architectural consistency. For agencies and developers managing multiple client sites, this means fewer edge cases when building block-based solutions or customizing the editor experience. It also reduces the cognitive load for content creators by presenting a cleaner, more uniform block library that aligns with the block-first editing philosophy.
From a business standpoint, this move accelerates the decline of new Classic block usage, which has been steadily shrinking due to the availability of native blocks and the “Convert to Blocks” feature. By curbing the creation of new Classic block content, WordPress can allocate maintenance resources more efficiently and reduce the complexity imposed by legacy editor integration.
Operationally, the eventual goal of loading TinyMCE only when required can improve performance and reduce resource consumption in block editor sessions, particularly for sites that no longer rely on the Classic block. This optimization benefits hosting providers and site operators by lowering server load and improving editor responsiveness.
The change also signals a shift in WordPress’s long-term strategy for legacy content management. The experimental deprecation notices and conversion workflows currently in development indicate a broader effort to smooth the migration path away from Classic blocks, reducing friction for site operators planning bulk content updates or redesigns.
What This Means for WordPress Users
Should you care about the Classic block being hidden in the inserter? Yes, if your workflows or client sites still depend on adding new Classic blocks within the block editor. The change does not disrupt existing Classic block content or the Classic Editor plugin, so your current content remains safe and editable.
If your development or agency environments rely on the Classic block for content creation, you can easily restore its visibility in the inserter with the provided wp_classic_block_supports_inserter filter. For non-technical users, the Enable Classic Block plugin offers a straightforward opt-in path without code.
For site operators and agencies focusing on modern block-based content, this change is a positive nudge to accelerate migration away from legacy editing patterns. Evaluating and planning bulk conversion of existing Classic blocks using the Convert to Blocks feature or custom migration scripts is advisable to future-proof content and take full advantage of the block editor’s capabilities.
Developers should note that hiding the Classic block reduces special-case handling during block editor enhancements and customizations. This can streamline plugin development and improve compatibility with new block features.
Finally, hosting providers and WordPress operators can anticipate performance improvements as TinyMCE loading is optimized in future releases, potentially reducing memory and CPU usage during editor sessions, especially on large-scale multi-site or agency environments.
Frequently Asked Questions
Will hiding the Classic block break my existing posts?
No. Existing Classic block content remains fully functional and editable. This change only prevents adding new Classic blocks from the inserter.
Does this affect the Classic Editor plugin?
No. The Classic Editor plugin and non-block-editor post types are unaffected. This change applies only to the Classic block within the block editor interface.
How can I re-enable the Classic block in the inserter?
Use the wp_classic_block_supports_inserter filter in your theme or plugin to return true. Alternatively, install the Enable Classic Block plugin which automates this.
Why is WordPress making this change now?
To promote a block-first editing experience, simplify maintenance, reduce legacy complexity, and prepare for future optimizations like conditional TinyMCE loading.
What tools exist to help migrate away from Classic blocks?
The block editor includes a “Convert to Blocks” feature. Experimental deprecation notices and migration flows are also being tested in Gutenberg to assist with this transition.
