The Classic Block Remains in the Inserter for WordPress 7.1

The Classic block will continue to appear in the block inserter by default in WordPress 7.1, reversing a previously announced plan to hide it. This decision preserves the current editing experience and defers the block’s obsolescence to user choice rather than enforced removal.

What Happened

Earlier in the WordPress 7.1 development cycle, the WordPress Core team announced that the Classic block (also known as the freeform block) would be hidden from the inserter by default. This change aimed to encourage users to transition to block-based editing, reducing reliance on TinyMCE, the legacy rich text editor that powers the Classic block.

To support this, a filter named wp_classic_block_supports_inserter was introduced, alongside the Enable Classic Block plugin to restore Classic block visibility if desired.

However, after collecting community feedback and internal discussions, the decision was reversed. The Classic block remains fully available in the inserter with WordPress 7.1, maintaining the status quo for users and developers. Consequently, the filter was removed as it never affected a stable release, and the Enable Classic Block plugin will be retired.

The Classic block’s editing toolbar, including the “Convert to blocks” option, remains unchanged. The revert aims to avoid forcing users off the Classic block and focuses future efforts on making the block editor’s alternative genuinely better and migration smoother.

Why This Matters

In production WordPress environments, the Classic block has long served as a fallback for content created outside the block editor or for users who prefer the legacy TinyMCE editor. It is deeply embedded in many workflows, especially for agencies managing large portfolios of sites with diverse content needs.

Removing the Classic block from the inserter by default would have been a significant user experience shift, effectively nudging site operators toward the block editor even if they were not ready. This could disrupt workflows, introduce friction, and complicate content maintenance where TinyMCE’s rich text capabilities remain preferred or necessary.

Technically, the Classic block depends on TinyMCE, a large and complex JavaScript library that continues to affect editor load times and performance. The initial motivation for hiding the block was to reduce TinyMCE’s footprint in the editor, improving performance and modernizing the editing experience.

However, the removal of the Classic block from the inserter does not eliminate TinyMCE’s load if existing content uses it, nor does it offer a seamless migration path. Forcing users to abandon the Classic block without a flawless conversion mechanism risks breaking content or creating confusion.

The revert highlights a critical architectural and ecosystem trade-off: legacy support versus forward progress. By keeping the Classic block accessible, WordPress avoids alienating users and agencies dependent on it while signaling that the transition to block editing is a gradual, user-driven process.

From a business perspective, this decision reduces the risk of customer dissatisfaction or support overhead caused by forced changes. It also ensures plugin and theme developers have time to adapt their products to coexist with both editing paradigms during this transition period.

What This Means for WordPress Users

Agency owners and developers: You can continue to rely on the Classic block for legacy content or client preferences without disruption in WordPress 7.1. There is no immediate need to modify your deployment strategies, but it remains advisable to invest in block-based workflows and educate clients on the benefits of the block editor.

Site operators: The Classic block stays available and fully functional. You do not need to install or maintain the Enable Classic Block plugin anymore. Consider testing the “Convert to blocks” feature carefully and plan gradual content migration where practical.

Plugin authors and theme developers: This revert means TinyMCE will continue loading when the Classic block is present, so performance optimization efforts should account for that. Future improvements in asset loading and explicit TinyMCE dependency declarations will require your cooperation to maximize benefits.

The WordPress Core team’s renewed focus on improving conversion tools and enabling asynchronous TinyMCE loading promises better long-term performance and user experience. Monitoring these developments and participating in feedback channels will be crucial for staying ahead.