WordPress 7.1 “Mary Lou”  🔗 **Source:** [WordPress 7.1 “Mary Lou”](https://wordpress.org/news/2026/08/mary-lou/) > [!note]+ Document Notes > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > <!-- deep-read:sections start --> ## 🏷️ Title WordPress 7.1 “Mary Lou” — Official Release Announcement ## 🧭 Table of Contents 1. References 2. Summary 3. Main Content 4. Paraphrase 5. Newsletter 6. Action Items 7. Hypotheses 8. Methodology 9. Questions 10. Future Research 11. Implications 12. Learning Styles Assessment 13. Accessibility Assessment 14. DEIB Assessment 15. Logical Validity 16. DARVO Analysis 17. Conclusion 18. Refactor Appendix 19. Template Library ## 🔗 References (in-page) - WordPress 7.1 Release Notes (linked, not detailed in this capture) - WordPress 7.1 Field Guide (linked, developer notes) - WordPress 7.1 feature showcase website (linked) - Learn WordPress (linked) ## 📝 Summary The official WordPress.org announcement for WordPress 7.1, code-named "Mary Lou" after jazz pianist/composer Mary Lou Williams. This is a major, feature-dense release: responsive style controls built directly into the Site Editor/Global Styles (no custom CSS needed, with live viewport preview); a persistent admin bar that now follows users across all editors; a new unified media-editor modal (freeform/aspect-ratio cropping, flip, precise/snap rotation, metadata editing) replacing the old inline crop tool; Notes now support rich text, @mentions, per-text-selection (not just per-block) commenting, multiple concurrent conversations per block, and collapsible threads; in-browser image processing (compression/resizing/thumbnails via a WebAssembly build of libvips) that reduces server load and avoids PHP memory/upload-timeout failures, plus native AVIF/HEIC/HDR-gain-map support; two new blocks (Playlist, with waveform visualization; Tabs); a new public SVG Icon API (`wp_register_icon_collection()`, `wp_register_icon()`, `wp_get_icon()`) letting developers register custom icon collections; the Abilities API (introduced in 6.9) gains a filterable execution lifecycle, custom validation, and shared discovery — explicitly framed as infrastructure for "AI-powered tooling"; a new admin Design System (semantic design tokens, ThemeProvider React component) for consistent custom admin-interface theming; block themes can now define custom responsive breakpoints in theme.json (overriding defaults); Button blocks get distinct hover/focus/active interactive styles; the post editor is now fully iframed for all themes (matching the Site Editor), isolating editing-canvas styles from admin styles; accessibility improvements (new `wp_get_tooltip()`/`wp_get_toggletip()` functions, improved screen-reader labeling in post list tables); infinite-scroll Media Library (with a per-user pagination opt-out); opt-in GIF-to-video conversion; resilient uploads (progress indicators, automatic retries); and host/site-owner-configurable speculative-loading defaults via environment variables or constants. The release: 800+ contributors, 170+ first-time contributors, 1500+ enhancements/fixes. Stakeholders: every WordPress site owner, theme/plugin developer, and hosting provider; especially relevant given this vault's existing tracking of the Icon Registration API (already deep-read separately) and the Abilities API's growing ecosystem (WordCamp US 2026 talks already in this vault). Bottom line: 7.1 is a substantial, developer-and-editor-experience-focused release that meaningfully advances both the no-code responsive-design story and the AI-agent/Abilities-API integration surface simultaneously. ## 📖 Main Content ### 🗒️ Notes **Naming tradition and this release's theme.** Each release honors a musician; 7.1 honors Mary Lou Williams, framed around "reinvention and collaboration" — her Harlem apartment functioned as a nightly workshop where Monk, Gillespie, and Powell shaped bebop together, explicitly mirrored in the release's collaboration-focused feature set (Notes, admin bar, responsive design tools). **Responsive styling without custom CSS.** Style controls for how a block looks at different screen sizes are now directly in Global Styles or individual block settings, with live viewport-size preview while editing. **Persistent, polished admin bar.** Follows the user across all editors (not just admin pages), with small visual polish updates. **Unified media editor.** Replaces the old inline cropping tool with one modal handling freeform/aspect-ratio cropping, flipping, fine-grained/snap rotation, and metadata editing — accessed via the same familiar Crop button. **Notes get rich text, mentions, and granular targeting.** Bold/italic/code formatting, links, @mention-based collaborator notification, notes on a specific text selection (not just an entire block), multiple simultaneous conversation threads per block, and collapsible long notes. **In-browser image processing.** Compression, resizing, and thumbnail generation now run client-side via a WebAssembly build of libvips — reduces server load, avoids PHP memory-limit/upload-timeout failures. Native AVIF, HEIC, and HDR gain map support added, matching formats modern phones/cameras already produce natively. **Two new blocks.** Playlist (multiple audio tracks, optional per-track waveform visualization) and Tabs (organize content into tabbed panels instead of showing everything at once). **Custom responsive breakpoints.** Block themes can define their own mobile/tablet breakpoints in `theme.json`, overriding WordPress's defaults for both responsive styles and block visibility. **Custom icon registration — now a public API.** `wp_register_icon_collection()`, `wp_register_icon()`, `wp_get_icon()` let developers register their own icon collections for use throughout the editor alongside the built-in library. (Cross-reference: this vault already has a dedicated Literature Note on the Icon Registration API from an earlier deep-read of a developer.wordpress.org tutorial.) **Abilities API matures.** Builds on the 6.9 infrastructure with a filterable execution lifecycle, custom validation, and shared discovery — explicitly stated purpose: "make it easier to build integrations and automation on top of WordPress, including AI-powered tooling." (Cross-reference: this vault has multiple WordCamp US 2026 Literature/Permanent Notes already covering the Abilities API's plugin-architecture implications in depth — this official release note is the primary-source confirmation of that infrastructure's continued core investment.) **New admin Design System.** Semantic design tokens plus a `ThemeProvider` React component, giving developers foundational theming support (color, roundness, cursor styles) for custom admin interfaces that still feel native to WordPress. **Interactive Button styles.** Distinct hover/focus/active states settable directly in the editor's style controls, per-button or globally. **Fully iframed post editor.** Now matches the Site Editor's architecture — editing canvas runs separately from the admin interface so admin styles can't leak into content styling, and viewport-relative units/media queries target the editing canvas directly for more predictable responsive-layout behavior while editing. Described as "mostly invisible" but structurally significant. **Accessibility.** New `wp_get_tooltip()`/`wp_get_toggletip()` functions bring accessible tooltips to more admin areas (post meta boxes, login screen); improved screen-reader labeling and more predictable navigation in post list tables; the new Tab/Playlist blocks and editor-navigation improvements are folded into the broader accessibility push. **Performance.** Browser-side image processing (WASM libvips) as above; opt-in GIF-to-video conversion for smaller files; resilient uploads (progress indicators, automatic retry on dropped connections); Media Library defaults to infinite scroll (per-user pagination opt-out available); speculative-loading (prefetch) defaults now configurable via environment variables/constants — letting hosts/site owners tune prefetch behavior without writing a plugin. **Release scale.** 800+ contributors, 170+ first-time contributors, 1500+ enhancements and fixes — explicitly framed against the mission to "democratize publishing." ## 📚 References All primary/official: WordPress.org's own release notes, Field Guide (developer notes), and feature showcase site — linked but not detailed in this capture. This announcement is itself a primary source. ## 🗣️ Paraphrase WordPress 7.1 is doing two things at once that are easy to read as separate stories but are actually connected: it's making WordPress more capable for humans working visually (responsive design without CSS, richer collaborative notes, a real media editor, tabs and playlists) while simultaneously deepening the infrastructure that lets *non-human* actors — AI agents, automation tools — operate on WordPress sites through the Abilities API's more mature execution/validation/discovery lifecycle. Read alongside this vault's existing Abilities API coverage from WordCamp US 2026, this release note is the primary-source confirmation that Automattic/core is treating agent-integration infrastructure as a first-class, ongoing investment, not a one-off 6.9 experiment. The performance section quietly ships a genuinely significant architectural change — moving image processing into the browser via WebAssembly — that solves a chronic pain point (PHP memory limits and upload timeouts on shared hosting) without requiring any server-side configuration change from site owners or hosts. ## 📰 Newsletter **WordPress 7.1 "Mary Lou" just shipped, and the two headline stories are responsive design without CSS and a maturing Abilities API built for AI agents.** Style any block differently per screen size directly in Global Styles, with live viewport preview. The post editor is now fully iframed to match the Site Editor. Notes finally get rich text, @mentions, and per-text-selection targeting instead of whole-block-only commenting. Image processing moves into the browser via WebAssembly (bye, PHP memory-limit crashes on big uploads), with native AVIF/HEIC/HDR support. Two new blocks (Playlist with waveforms, Tabs). And quietly, in the developer section: the Abilities API introduced in 6.9 now has a filterable execution lifecycle, custom validation, and shared discovery — explicit infrastructure for "AI-powered tooling." 800+ contributors, 170+ of them first-timers, 1500+ fixes. Worth reading the Field Guide if you build on WordPress. ## ✅ Action Items - **Core:** This is Core's own release — track adoption/feedback on the fully-iframed post editor change ("mostly invisible" per the announcement, but structurally significant) and the new responsive-breakpoint theme.json overrides. - **Core Performance:** The in-browser WASM image processing is a major performance/reliability win worth benchmarking against the prior server-side pipeline (memory-limit/timeout failure rate before vs. after). - **Core AI:** The Abilities API maturation (filterable execution lifecycle, custom validation, shared discovery) is directly relevant — cross-reference against this vault's existing WordCamp US 2026 Abilities API notes for continuity tracking. - **Core Program Team:** 800+ contributors / 170+ first-timers / 1500+ fixes is a strong headline metric worth using in program-health reporting, though cross-reference against the WPOCC survey's Five-for-the-Future skepticism (Mullenweg himself reportedly called those numbers not reflective of reality in the WordCamp US fireside chat already in this vault) before treating raw contributor counts as an uncomplicated health signal. - **Mobile:** The new responsive-breakpoint and viewport-preview tools are directly relevant to mobile-rendering QA workflows. - **Playground:** A good release to showcase via Playground given the density of new editor-visible features (Tabs, Playlist, media editor, responsive controls). - **Community:** The naming/collaboration framing (Mary Lou Williams' Harlem workshop) is a nice narrative hook for community-facing release communications. - **Training / Documentation:** The Field Guide and feature showcase site are the primary developer-facing resources to point new contributors/theme authors toward, especially for the new Icon API, Abilities API changes, and admin Design System. - **Marketing:** Release-note copy already frames responsive design and collaboration features well for external marketing; the Abilities API/AI-tooling angle is a distinct, less-marketed story worth its own content. - **Support:** New Notes functionality (rich text, mentions, per-text-selection) will likely generate support questions during the adjustment period — worth pre-staffing documentation/FAQ content. - **Design:** The new admin Design System (semantic tokens, ThemeProvider) is directly actionable for any custom-admin-interface work. - **Accessibility:** New tooltip/toggletip functions and post-list-table screen-reader improvements are concrete, citable accessibility wins for this vault's accessibility-tracking material. - **Meta:** Not applicable to this source beyond general plugin-directory Icon API implications already tracked separately. - **CLI:** Not explicitly covered in this announcement, though the scale of changes (iframed editor, new blocks, Abilities API) likely has WP-CLI-relevant implications not detailed here. - **Hosting:** The configurable speculative-loading defaults (via environment variables/constants) and the in-browser image processing both reduce server-side load in ways directly relevant to hosting providers' resource planning. - **Tide:** Not applicable to this source. - **Openverse:** Not applicable to this source. - **Themes:** Custom responsive breakpoints in theme.json, pseudo-state styling (hover/focus/focus-visible/active) via theme.json, and new DataViews/DataForm filters are all directly actionable for theme authors. - **Plugins:** The public SVG Icon API and the maturing Abilities API both reduce the need for certain categories of plugins (custom icon plugins, some automation/integration plugins) — worth tracking plugin-directory impact over time. - **The WPOCC:** Worth cross-referencing this release's AI/Abilities-API framing against the WPOCC survey's finding that AI-in-WordPress is the single most negative sentiment measure (net −33) in the community — this release continues investing in AI-adjacent infrastructure during a period of documented community unease about exactly that direction, without an explicit opt-out/consent framing mentioned in this announcement (though the Abilities API itself may have permission scoping not detailed here). - **FAIR:** Not applicable to this source directly, though the federated/decentralized-infrastructure questions raised elsewhere in this vault are adjacent to how Abilities API adoption unfolds. ## 🧪 Hypotheses 1. The in-browser WASM image-processing change will measurably reduce hosting-support tickets related to upload timeouts/memory-limit errors within the next 1-2 release cycles. 2. Given the WPOCC survey's finding that AI-in-WordPress sentiment is net −33 even among daily AI users, continued Abilities API investment framed explicitly around "AI-powered tooling" (as this release note does) risks reinforcing the "shoehorned in" perception documented in that survey's open responses, unless accompanied by clear opt-in/opt-out communication that this announcement doesn't mention. 3. The fully-iframed post editor (matching Site Editor architecture) will reduce a category of theme/plugin CSS-conflict bug reports, since admin styles can no longer leak into editor-canvas content styling. 4. Custom icon collections registered via the new public SVG Icon API will proliferate faster among plugin/theme developers than community-built icon sets did previously, given the lower implementation barrier of an official, documented API versus ad-hoc prior approaches. ## 📊 Methodology This is an official product-release announcement, not research — no methodology beyond WordPress's standard release-cycle development and testing process (implied by the Field Guide/Release Notes references, not detailed in this capture). Contributor/fix counts (800+, 170+, 1500+) are self-reported release statistics, standard for this genre and generally considered reliable given WordPress's public Trac/GitHub contribution tracking. ## ❓ Questions - Does the Abilities API's "custom validation" and "shared discovery" lifecycle include any user-facing permission/consent UI, given the WPOCC survey's finding that AI-in-WordPress objections center specifically on missing opt-out mechanisms? - What's the actual measured performance/reliability improvement from moving image processing to WASM/browser-side, compared to the prior server-side pipeline, across a range of hosting environments (shared hosting with tight PHP memory limits specifically)? - How does the new admin Design System relate to (or supersede) prior admin-theming approaches, and what's the migration path for existing custom admin interfaces? - Will the fully-iframed post editor break any existing plugins that inject custom admin-area styles expecting them to cascade into the editor canvas? ## 🔮 Future Research - A follow-up comparison of upload-failure/support-ticket rates before and after 7.1's WASM image-processing rollout, ideally segmented by hosting tier (shared vs. managed vs. VPS). - Tracking Abilities API adoption rate among the top N plugins/themes over the next 2-3 release cycles, to see whether the API's maturation (validation, discovery lifecycle) meaningfully accelerates third-party adoption versus the 6.9 baseline. - A qualitative follow-up specifically asking WordPress community members (perhaps as a targeted WPOCC survey question) how they perceive 7.1's Abilities API framing given the documented AI-in-WordPress sentiment gap. ## 💡 Implications - **Practice:** Theme/plugin developers should prioritize evaluating the new public Icon API and Abilities API lifecycle changes for near-term adoption, given official core investment signals continued platform support. - **Policy:** Core's continued framing of Abilities API work explicitly around "AI-powered tooling" without an accompanying visible opt-in/consent framing (per this announcement) is worth flagging against the WPOCC survey's governance-and-AI findings — a communications/policy gap between what core ships and how the community has said it wants AI framed. - **Security:** Not directly addressed in this announcement beyond the Abilities API's "custom validation" lifecycle, which likely has security implications not detailed here. - **Education:** The Field Guide and feature showcase site are the right next-step resources for anyone building on 7.1's new APIs. - **Funding:** Not applicable to this source. ## 🧠 Learning Styles Assessment - **Visual:** Strong — references a release video and numerous UI-dependent features (media editor, responsive preview, Tabs/Playlist blocks) best understood visually. - **Aural:** Moderate — the linked release video would serve auditory learners well; the text itself is descriptive prose. - **Verbal:** Strong — clear, well-organized section headers and specific function names (`wp_register_icon()`, etc.) for developers to reference directly. - **Kinesthetic:** Strong — directly actionable for developers ready to try the new APIs and editor features hands-on. - **Logical:** Strong — organized into clear thematic sections (styling, media, collaboration, blocks, developer tools, accessibility, performance). - **Social:** Moderate — the Notes/collaboration features and the Mary Lou Williams naming narrative both carry a social/collaborative framing. - **Solitary:** Moderate — a straightforward reference document for independent review. - **Naturalistic:** Not applicable. Estimated reading level: general WordPress user through developer-professional audience — the announcement itself is accessible to general users, while the "Developer's toolbox" section assumes PHP/JS/theme.json familiarity. ## 📊 Accessibility Assessment (WCAG 2.2 AA) - **Perceivable:** The release itself ships accessibility improvements (accessible tooltips/toggletips, improved screen-reader labeling) — a positive, substantive accessibility contribution rather than just an assessment target. - **Operable:** New keyboard/screen-reader improvements in post list tables directly improve operability for assistive-technology users. - **Understandable:** The announcement's own prose is clear and well-structured with descriptive headers. - **Robust:** Not assessable from this scrape alone regarding the actual shipped code's WCAG conformance. - **Overall:** This release note itself models good practice by dedicating an explicit "Accessibility" section rather than treating it as an afterthought — consistent with the vault's broader tracking of WordPress 7.1's accessibility investment (44 Core + 43 Gutenberg fixes, per the WP-CONTENT.CO newsletter already in this vault). ## 🌍 DEIB Assessment - **Cultural breadth:** The release-naming tradition honoring a Black female jazz pioneer (Mary Lou Williams) whose Harlem apartment hosted a genuinely cross-cultural, collaborative creative scene is a meaningful representational choice, explicitly tied to the release's own collaboration-focused feature narrative. - **Inclusive language:** No concerns identified. - **Neurodiversity support:** The new collapsible-Notes feature (keeping long threads tidy) and improved tooltip/toggletip accessibility both incidentally support reduced cognitive load. - **Representation:** The contributor-count framing (800+ contributors, 170+ first-timers, from "all over the world") emphasizes global/diverse participation, though cross-reference against the WPOCC survey's finding that these headline numbers may not reflect the sustained/paid contributor reality is warranted before treating them uncritically. - **Psychological safety:** Not a primary dimension of this source. ## ✅ Logical Validity **Strong reasoning:** This is a straightforward release announcement, not an argumentative piece — its claims (feature descriptions, contributor counts) are factual/descriptive rather than persuasive arguments requiring logical scrutiny in the traditional sense. **Fallacies:** None applicable to this genre. One point worth flagging as a gap rather than a fallacy: the announcement frames the Abilities API's AI-tooling purpose entirely positively, without acknowledging the documented community ambivalence about AI-in-WordPress (per the WPOCC survey already in this vault) — not a logical error, but a notable omission of relevant context a careful reader should supply themselves. **Tone of voice:** Celebratory, feature-forward, standard for an official release announcement; the musician-naming narrative adds warmth without undermining the informational content. ## 🛡️ DARVO Analysis Not applicable to this source — no deny/attack/reverse-victim-offender dynamic present; this is a straightforward product-release announcement with no accusation or defensive framing. ## 🎯 Conclusion A substantial, well-rounded release that advances both ends of WordPress's current strategic tension simultaneously: making the visual/collaborative editing experience genuinely better (responsive design without CSS, richer Notes, a real media editor, new blocks) while continuing to build out AI-agent integration infrastructure (Abilities API maturation) during a period the vault's own WPOCC survey data shows is one of real community ambivalence about exactly that direction. For anyone tracking WordPress's AI-strategy trajectory (as this vault does extensively), 7.1 is a primary-source data point that core investment in Abilities API/agent-integration work is continuing on schedule and un-slowed by the community-sentiment concerns documented elsewhere in this vault — worth watching whether a future release addresses the opt-in/opt-out and communication gaps the WPOCC survey specifically flagged. ## 🧱 Refactor Appendix ### Literature Split Pad (H3) #### The Abilities API's maturation is explicitly framed as infrastructure for AI-powered tooling > [!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/why: the clearest primary-source confirmation that core continues investing in agent-integration infrastructure as an ongoing priority, not a one-off 6.9 experiment — directly relevant to this vault's extensive existing Abilities API coverage. #### In-browser image processing solves a chronic shared-hosting pain point without server-side configuration 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/why: a genuinely significant architectural shift (WASM-based client-side processing) addressing a long-standing, widely-experienced WordPress pain point. #### The post editor's full iframing removes a category of style-leakage bugs by construction > [!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/why: a structural fix that eliminates an entire class of admin-CSS-leaking-into-content bugs by architecture rather than by patching individual conflicts. ### Atomic Split Pad (H4) **Framing new AI-adjacent infrastructure purely as capability, without addressing documented community consent/opt-out concerns, risks widening rather than closing a trust gap.** Claim: when official release communications describe new AI-integration infrastructure (like the Abilities API) purely in terms of what it enables, without acknowledging or addressing community-documented concerns about consent, defaults, and opt-out (as this vault's WPOCC survey data shows is a live, specific concern — not blanket AI opposition), the communication itself can reinforce the exact "shoehorned in" perception the community has already flagged, independent of whether the underlying feature actually addresses those concerns technically. Evidence: this WordPress 7.1 announcement's Abilities API section makes no mention of permission/consent/opt-out framing, while the WPOCC's own State of the Community 2026 survey (already in this vault) documents AI-in-WordPress as the single most negative sentiment measure, with objections centering specifically on default/opt-out design rather than AI capability itself. Scope: applies to official communications about features in domains where a community has documented specific process/consent concerns; the gap identified here is about communication framing, not necessarily about the feature's actual technical design (which may or may not address those concerns — not detailed in this announcement either way). <!-- atomicity: 1 idea ✓ --> ### Fleeting Queue - Check the WordPress 7.1 Field Guide directly for whether the Abilities API's "custom validation" lifecycle includes any user-facing permission/consent UI, to resolve the open question above. - Cross-reference this release's contributor-count framing (800+, 170+ first-timers) against the WPOCC survey and the Mullenweg fireside-chat note (already in this vault) where he reportedly stated Five-for-the-Future's headline numbers don't reflect reality — worth a synthesis-pass connection. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/WordPress 7.1 “Mary Lou”.md|WordPress 7.1 “Mary Lou” by WordPress.org News]] ## Highlights - 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. ([View Highlight](https://read.readwise.io/read/01m0ftjhzw4tc6n6rcj59a1hkx)) - Tags: atom/literature/h2 - The editing canvas runs separately from the WordPress admin interface, so admin styles don’t interfere with your content. Viewport-relative units and media queries now target the editing canvas directly, so responsive layouts behave more predictably as you build. The change is mostly invisible, but the result is a more reliable and consistent editor. ([View Highlight](https://read.readwise.io/read/01m0ftjp0xeq0a217pp6n4zdeg)) - Tags: atom/literature/h3 - 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. ([View Highlight](https://read.readwise.io/read/01m0ftjd9nqwwk999kg4ta8kxs)) - Tags: atom/literature/h1