# Hiding Not Removing Deprecates a Legacy Feature Safely ## Claim You can deprecate a legacy feature safely by hiding it from discovery while keeping it registered, rendering, and reversible with a single filter. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds when existing content keeps rendering unchanged and a documented opt-back-in escape hatch exists for anyone who still needs the old behavior. - Breaks down when the feature is removed outright, or migration off it is forced rather than optional. - Doesn't establish that hiding alone solves the underlying problem (here, lazy-loading TinyMCE) — only that it's a safe first step that doesn't break anyone immediately. ## Evidence WordPress 7.1 removes the Classic block from the block inserter's visible list while leaving `core/freeform` fully registered, rendering, and editable; a dedicated filter, `wp_classic_block_supports_inserter`, restores full visibility (including per-post-type logic) for anyone who needs it, with a no-code plugin already available for non-developers — framed explicitly as groundwork for a later goal of loading TinyMCE only when needed. **Reversed in practice (2026-08-28)** — the WordPress plan this describes was undone. [[3. Resources/Readwise/Articles/WordPress 7.1 Release Lead Decision Log|WordPress 7.1 Release Lead Decision Log]] records the July 7 decision: hiding the Classic block from the inserter was reverted, and the `wp_classic_block_supports_inserter` filter and its deprecation notice were removed. The reversal does **not** falsify the technical claim. Hiding while keeping the feature registered, rendering, and filter-reversible is still the low-breakage mechanism, and nothing in the decision disputes that. What it rejects is the premise underneath: Anne McCarthy's stated takeaway is that the Classic block "should become obsolete by choice, not by force," which treats removing discovery as force in a quieter form. So the scope narrows rather than closes. This is a claim about **breakage**, not about **consent** — and a deprecation needs to pass both tests. ## Links - [[3. Resources/Permanent Notes/WordPress's Compatibility-First Culture Is Now Its Binding Security Constraint]] — because extends; this is a concrete case of the same compatibility-preservation instinct applied to an editor deprecation instead of a security tradeoff. - [[3. Resources/Permanent Notes/Default-Off Feature Flags Decouple Shipping Speed From Production Risk]] — because applies-in; hide-with-a-reversal-filter is the deprecation-side mirror of default-off-with-an-opt-in-flag on the shipping-new-features side. - [[3. Resources/MOCs/Open Source Governance MOC]] — because applies-in; this is a reusable deprecation pattern for any large project trying to sunset a legacy feature without breaking its install base. - [[3. Resources/Permanent Notes/A Legacy Feature Should Become Obsolete by Choice Not by Force]] — because contrasts: the decision that reverted this mechanism in WordPress 7.1, on the ground that hiding is still force even when it is safe. - [[3. Resources/MOCs/WordPress Platform Design MOC]] — because it names the low-breakage mechanism for retiring a Core feature, and the 7.1 Classic block reversal is why that mechanism now has to pass a consent test as well. ## Tests / falsifiers - Track whether sites relying on `core/freeform` (via plugins, custom post types, or saved content) actually break after 7.1 ships — any breakage would show "hide-don't-remove" isn't as safe as claimed. - Watch whether the later "fully opt-in Classic" phase ends up removing the block outright rather than keeping the filter escape hatch — that would show hiding was really a removal in disguise, on a longer timeline. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Readwise/Full Document Contents/Articles/Hiding the Classic Block From the Inserter in WordPress 7.1]] — the devnote describing the hide-with-filter approach.