# Forced UX Removal Gets Reverted Under Visible Pushback ## Claim When a project announces it will force-remove or hide a widely used legacy feature without first shipping a preferred alternative, expect that plan to get walked back once the change becomes visible to the people who rely on it. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds when the removed feature has an active, non-trivial user base and no ready substitute exists yet at the time of the removal announcement. - Less likely to hold when a genuine replacement ships alongside the removal — deprecation-with-migration-path is a different, more durable move than forced hiding with no alternative. - The WordPress source doesn't name what feedback actually drove the reversal (forum threads, Trac comments, social posts) — the causal mechanism ("pushback caused the reversal") is inferred from the sequence of events, not confirmed by the article itself. ## Evidence WordPress 7.1's roadmap originally planned to hide the Classic block from the block inserter; the plan was reverted, with the team's stated focus shifting to "building better alternatives" rather than forcing the change. This is the one clear instance in an otherwise forward-only July 2026 developer roundup of core reversing a previously announced UX decision. ## Links - [[3. Resources/Permanent Notes/Hiding Not Removing Deprecates a Legacy Feature Safely]] — because contrasts; that note documents the *mechanics* of a safe, reversible hide (single filter, content keeps rendering, opt-back-in escape hatch) — this note is about what happens when a hide is announced *without* that reversibility discipline built in up front - [[3. Resources/Permanent Notes/Default-Off Feature Flags Decouple Shipping Speed From Production Risk]] — because contrasts; default-off flags avoid this failure mode entirely by never forcing exposure on anyone before it's proven safe — the Classic block plan skipped that gate and had to be reversed after the fact instead - [[3. Resources/MOCs/Open Source Governance MOC]] — because applies-in; this is a governance pattern for how forced-change decisions get contested and walked back in an open community project - [[3. Resources/Permanent Notes/A Legacy Feature Should Become Obsolete by Choice Not by Force]] — because evidence-for: the pattern completing, documented by the release lead who made the reversal rather than inferred from a changelog. ## Tests / falsifiers - Find a case where a project announced a forced removal of an actively-used feature *with* a ready replacement already shipped, and check whether it still got reverted — if pushback reverses removals even when a substitute exists, the "no ready alternative" scope condition is wrong. - Track whether WordPress specifically names the feedback source for the Classic block reversal in a future retrospective; if it turns out to be a small, non-representative complaint rather than broad pushback, this claim's evidentiary basis weakens. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Literature Notes/What's New for Developers (July 2026)]] — reports the Classic block reversal alongside the 7.1 beta schedule and the roundup's other breaking/additive changes.