## Lingering Questions - The Abilities API gains "a filterable execution lifecycle, custom validation, and shared discovery" in 7.1 — which of those filters are the extension points third-party AI tooling will actually hook, and are any of them capability-gated? - Client-side media processing moves compression and thumbnailing into the browser. What happens on a device that cannot do the work, and does the fallback path reintroduce the PHP memory limits it was meant to avoid? - Full editor iframing "for all themes" — what breaks for plugins that were injecting admin CSS into the canvas, and was there a deprecation window? ## Article Ideas - A post on what 7.1 actually shipped versus what the roadmap promised, read against Anne McCarthy's decision log. The gap is the story, and the log explains it. ## Cross Reference - [[3. Resources/Permanent Notes/A Release Lead's Output Is Mostly Subtraction]] — this announcement is the visible half of 7.1; the decision log is the invisible half, and the invisible half is larger. ## Fiction & Worldbuilding - None. ## Vocabulary - **Abilities API** — Core's registry for describing what a site can do, in a form other software (increasingly AI tooling) can discover and call. - **Client-side media processing** — compression, resizing, and thumbnail generation performed in the browser rather than by PHP on the server. ## Bib capsule WordPress.org, "WordPress 7.1 'Mary Lou'" — the official release announcement, published 2026-08-19. Primary source, promotional register. Read alongside [[3. Resources/Readwise/Articles/WordPress 7.1 Release Lead Decision Log|Anne McCarthy's decision log]], which covers the same cycle from inside and records what did not ship. ## Author's thesis 7.1 delivers three structural changes — extended agent-integration infrastructure, browser-side media processing, and full editor iframing — each framed as removing a long-standing constraint rather than adding a feature. ## Key arguments 1. The Abilities API is an ongoing investment, not a 6.9 experiment. 2. Moving media processing to the browser sidesteps shared-hosting limits without server configuration. 3. Iframing the post editor eliminates a class of style-leakage bugs by architecture. ## Claim atoms ### Core continues investing in agent-integration infrastructure beyond 6.9 > [!quote] ID:rw_atom1 > "The Abilities API builds on the infrastructure introduced in WordPress 6.9 with a filterable execution lifecycle, custom validation, and shared discovery. These additions make it easier to build integrations and automation on top of WordPress, including AI-powered tooling." *Where:* Feature summary. *Why:* the clearest primary-source confirmation that this is a sustained direction. Worth holding against the decision log, which records the Abilities API *follow-ups* being punted from this same release — so the commitment is real and the pace is contested. ### In-browser image processing removes a shared-hosting constraint without server changes > [!quote] ID:rw_atom2 > "Image compression, resizing, and thumbnail generation now happen in the browser, reducing server load and producing smaller files — without hitting PHP memory limits or upload timeouts." *Where:* Media section. *Why:* a genuine architectural shift addressing a constraint that has shaped WordPress hosting advice for a decade. ### Full editor iframing removes style leakage by construction rather than by patching > [!quote] ID:rw_atom3 > "The post editor is now fully iframed for all themes, matching the Site Editor. The editing canvas runs separately from the WordPress admin interface, so admin styles don't interfere with your content." *Where:* Editor section. *Why:* a structural fix that retires an entire bug category instead of resolving instances of it — the same move as [[3. Resources/Permanent Notes/Instruction Files Are the Last Rung Not the First]] recommends, one domain over. ## Permanent candidates **None created — deliberately.** These are release-note facts, and the vault already holds 33 Literature notes on the 7.1 cycle covering the Abilities API, responsive styling, iframing, and client-side media in more analytical depth than the announcement offers. The announcement's value here is as the **primary-source anchor** those notes cite, not as a source of new claims. The one genuinely uncaptured angle — that framing AI-adjacent infrastructure purely as capability, without addressing the documented consent and opt-out concerns from the same cycle, widens rather than closes a trust gap — is already carried by [[3. Resources/Permanent Notes/Default-On AI Activation Inflates Adoption Metrics at the Cost of Consent]] and [[3. Resources/Permanent Notes/WordPress Stores AI API Keys in a Layer Its Own Security Team Says It Cannot Encrypt]]. ## Processing checklist - [x] Read against the decision log (primary, same cycle, opposite register) - [x] Checked all three atoms against existing Permanents before creating any - [x] Registered in a MOC - [ ] Revisit if 7.2 changes the Abilities API extension points ## Links - [[3. Resources/MOCs/WordPress Platform Design MOC]] — the shipped surface of 7.1, against which the cycle's punts and reversals are read - [[3. Resources/Permanent Notes/A Release Lead's Output Is Mostly Subtraction]] — because contrasts: the announcement lists what was added; the release lead's actual output was the ten things that were not - [[3. Resources/Permanent Notes/A Reversible Opt-Out Beats a Revert When Integration Runs Deep]] — because applies-in: responsive styling shipped with a disable switch, and this is the announcement that shipped it - [[3. Resources/Permanent Notes/A Legacy Feature Should Become Obsolete by Choice Not by Force]] — because evidence-for: the Classic block is still in the inserter in this release, which is the reversal taking effect ## Source [[3. Resources/Readwise/Articles/WordPress 7.1 “Mary Lou”|WordPress 7.1 “Mary Lou”]]