# A Reversible Opt-Out Beats a Revert When Integration Runs Deep ## Claim When a feature is too entangled to remove safely late in a cycle, shipping a non-destructive switch preserves both the release and the objectors' position at a fraction of the risk. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds where the feature's data survives the switch and the switch itself is small — as here, saved responsive styles persist and the toggle hides two entry points rather than rewriting the feature. - Breaks where the opt-out is itself complex, or where per-site divergence on a headline feature imposes more documentation, training, and support cost than the original problem did. - Requires the objection to be about experience or timing, not about the feature's correctness — an opt-out doesn't fix a broken feature, it defers exposure to it. ## Evidence WordPress 7.1 shipped `responsiveEditingEnabled`, a new setting to non-destructively disable responsive style editing, added within roughly 24 hours of a maintainer flagging concrete UX problems for an enterprise theme used by thousands of sites. The core committer judged an outright revert riskier than the opt-out because of how deeply responsive styling was already integrated into the release — a real but unverifiable engineering assessment that the article reports without an independent second opinion. **Corroboration (2026-08-28)** — [[3. Resources/Readwise/Articles/WordPress 7.1 Release Lead Decision Log|WordPress 7.1 Release Lead Decision Log]] supplies the decision-maker's own account of the July 28 responsive-styling call. Enterprise theme maintainers raised support-burden concerns in dev chat and asked for a pause or an opt-out; McCarthy's recorded call was *"A way to disable is fine. I don't think fully disabling it makes sense,"* on the ground that a full removal "was disproportionate to the impact and desire for this feature." She also draws the general lesson this note asserts, and dates it earlier than the conflict: *"A way to opt out likely should have been done from the beginning as this is a common request in WordPress, even when a feature is long awaited."* That moves the switch from a late-cycle rescue to a design default — the opt-out is cheapest before anyone needs it. ## Links - [[3. Resources/Permanent Notes/WordPress Ships a Risky Feature's Architecture Into Core While Withholding the Full Feature Set]] — because contrasts; that pattern decouples infrastructure from user-experience commitment at the initial ship, this pattern decouples them after the fact when a problem surfaces late - [[3. Resources/Permanent Notes/Default-Off Feature Flags Decouple Shipping Speed From Production Risk]] — because contrasts; this opt-out defaults to *on*, which is the riskier variant of the same mechanism and worth noting as a deliberate choice - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — because applies-in; the revert-versus-switch tradeoff under release-date pressure is a transferable product decision, not a WordPress-specific one - [[3. Resources/Permanent Notes/A Legacy Feature Should Become Obsolete by Choice Not by Force]] — because applies-in: the same release lead in the same cycle, reaching for a switch instead of a removal once objectors surfaced late. ## Tests / falsifiers - Track support-ticket volume and bug reports for sites left on the responsive-editing default versus sites that opted out; if opted-out sites show no meaningful reduction in friction, the mitigation didn't address the underlying complaint, only silenced it. - If a later release shows the opt-out fragmenting documentation or training cost more than the original UX problem did, that's the scope condition breaking in practice, not just in theory. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Readwise/Articles/WordPress 7.1 Beta 4 Adds Opt-Out for Responsive Styling, Punts Inherited Styles Display]] — reports the Tuesday dev-chat escalation, the merged setting, and the engineering rationale for switch-over-revert.