# Registered Extension Points Reduce Markup Coupling ## Claim When plugins extend a system by targeting DOM selectors instead of registering through a defined API, every internal markup change becomes a potential breaking change for extensions that never opted into that risk. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds for any platform where third parties extend behavior by manipulating rendered output rather than calling a published interface. - The fix (registered fields/actions/views) only reduces coupling to the extent the registered surface actually covers the workflows extensions need — an incomplete registration API pushes developers back to markup-patching for the gap cases. - Doesn't claim registered APIs eliminate conflicts entirely — independently-registered extensions can still collide on the same field or view, just through a defined contract instead of an undefined one. ## Evidence WooCommerce's DataViews argument: classic WordPress admin extensions rely on imperative hooks and custom JavaScript targeting DOM selectors, which aren't a stable API — so even internal markup changes can break integrations, and each extension wires into the UI independently with no shared model, raising the odds plugins conflict with one another. The proposed fix (register fields, actions, and views declaratively) is explicitly still being built: a View Config extension point was targeted for WordPress 7.1, with server-side field registration planned next. ## Links - [[3. Resources/Permanent Notes/A Shared Field Schema Replaces Four Separate Implementations]] — because extends: the schema defines what can be registered; this note is about why registering it (instead of patching markup) matters. - [[3. Resources/Permanent Notes/Working Locally With No-Push Intent Limits AI Contribution Risk]] — because contrasts: both are about stabilizing an interface against unreviewed change, one at the API-contract layer, one at the human-review layer. - [[3. Resources/MOCs/Open Source Governance MOC]] — because applies-in: extension-point stability is a governance and deprecation-policy question as much as a technical one. ## Tests / falsifiers - Track plugin breakage rate across a WordPress major release for plugins using registered DataViews extension points versus plugins still targeting admin DOM selectors for equivalent functionality. - If registered-API plugins break at the same rate as DOM-targeting plugins during a release, the claim would be falsified — the registration layer wouldn't actually be insulating extensions from internal change. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Readwise/Articles/What’s the value of DataViews and who is it for|What’s the value of DataViews and who is it for?]] — the markup-coupling argument and the View Config / server-side field registration roadmap.