WordPress 7.1 Beta 1  🔗 **Source:** [WordPress 7.1 Beta 1](https://wordpress.org/news/2026/07/wordpress-7-1-beta-1/) > [!note]+ Document Notes > tags: [wordpress-core, gutenberg, block-editor, admin-ux, media-processing, accessibility] > author: [MISSING] > source: WordPress.org News > reference: https://wordpress.org/news/2026/07/wordpress-7-1-beta-1/ > date created: 2026-07-16 08:35 > > # 🏷️ Title: WordPress 7.1 Beta 1 > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [WordPress Beta Tester plugin](https://wordpress.org/plugins/wordpress-beta-tester/) - [Beta 1 direct download (zip)](https://wordpress.org/wordpress-7.1-beta1.zip) - [7.1 release schedule](https://make.wordpress.org/core/2026/07/03/wordpress-7-1-release-party-schedule/) - [Help test WordPress 7.1](https://make.wordpress.org/test/2026/07/15/help-test-wordpress-7-1/) - [WordPress Trac (new ticket)](https://core.trac.wordpress.org/newticket) - [Known major bugs](https://core.trac.wordpress.org/tickets/major) - [Make Core testing initiatives](https://make.wordpress.org/test/) - [7.1 Beta 1 Playground instance](https://playground.wordpress.net/?site-slug=kind-classic-mountain&networking=no&php=8.3&wp=beta&language=&multisite=no) ## 📝 Summary - WordPress 7.1 Beta 1 is publicly downloadable for testing (not production use), via the Beta Tester plugin, direct zip, WP-CLI, or WordPress Playground. - Final 7.1 release is scheduled for **August 19, 2026**; this is the first beta in that release cycle. - The release consolidates a large batch of Gutenberg-plugin features (versions 22.7 through 23.6) into Core across five themes: collaborative Notes, responsive/interactive styling, media pipeline improvements, admin navigation/personalization, and developer-facing APIs. - Key stakeholders: Core contributors and the release squad running the Beta/RC cycle, plugin/theme authors who need to adapt to iframed editor enforcement and Block API v3, testers in the Alpha/Beta support forum and Trac, and everyday site owners who get UX changes (Omnibar, command palette, DataViews) without any custom development. - Risk/tradeoff: this is pre-release software explicitly flagged as unsafe for production; the post is also a call to action — WordPress's release quality depends on volunteer beta testing, and the post frames that testing as directly load-bearing for stability. - Bottom line: no new user-facing decisions required yet — this is a testing-cycle checkpoint, five weeks out from the scheduled final release, with a clear list of what changed and how to try it in a disposable environment. ## 📖 Main Content WordPress 7.1 Beta 1 opens the testing window for the next major Core release, due August 19, 2026. The post is structured as a release-notes announcement: it opens with testing mechanics (four ways to install the beta, explicitly warning against production use), then walks through five feature clusters, and closes with a testing call-to-action and a haiku (a recurring WordPress release-post tradition). The feature clusters, in the order presented: 1. **Notes** — asynchronous collaboration tooling gets richer: inline text formatting (bold/italic/code/links/emoji with shortcuts), @mention tagging, multiple independent note threads per block, notes anchored to text selections rather than whole blocks, and auto-collapsing long notes. 2. **Responsive and interactive styling** — block appearance can now vary by screen size and by interaction state (hover/focus) entirely through the editor UI, with no custom CSS. Theme authors get to define their own breakpoints in `theme.json` rather than being locked to WordPress's defaults. 3. **Media pipeline** — image/media processing moves client-side (in-browser) with expanded format support: HEIC (the default iPhone photo format), UltraHDR, AVIF, WebP, and GIF-to-video conversion. Uploads get progress indicators and automatic retry on dropped connections. A new unified Media Editor Modal replaces the old inline cropping tool. Galleries can auto-pull attached media, and the Media Library defaults to infinite scroll (toggleable per-user). 4. **Admin navigation** — the admin toolbar (Omnibar) now persists inside the Site Editor and Block Editor rather than disappearing. The command palette (Ctrl/Cmd+K) groups results into Recent/Matching/Suggestions instead of one flat list. The Site Editor now respects the user's chosen admin color scheme. Visual revisions get a picker layout, autosave labeling, and a direct-to-revisions autosave notice. Comment threading gets a real UI fix: an editable "In reply to" dropdown scoped to the same post (explicitly not for moving comments across posts). 5. **New blocks and block-level fixes** — a Playlist block (with waveform visualization) and a Tabs block are new. A long-standing bug where background gradients were silently overridden by background images is fixed across Group, Verse, Accordion, Pullquote, Post Content, and Quote blocks. The HTML block now supports editable nested blocks (explicitly framed as useful for AI-generated raw-HTML content). Images get a "mark as decorative" toggle for screen-reader exclusion. Shortcode-to-Embed conversion is smarter. 6. **Global audience / developer foundation** — progress toward Unicode email address support (usernames, slugs, emails representing non-Latin scripts), Abilities API refinement (explicitly framed as serving "AI tooling," not just human developers), Block Bindings extended to List Item, custom icon registration for plugin/theme authors, enforced iframed post editor (with a compatibility note: Block API v2-or-lower blocks need updating to v3), a `wordpress/theme` package architecture review, and Connectors screen authentication improvements (username/application-password login plus a fix for a credential-autosuggest security gap). The post closes with attribution to seven contributors for proofreading/review — a small but consistent WordPress convention of crediting unglamorous editorial work, not just code. ### 🗒️ Notes - The four testing paths (Beta Tester plugin, direct zip, WP-CLI `wp core update --version=7.1-beta1`, Playground) are ordered from lowest-friction/most-realistic (plugin on a real install) to zero-setup/most-disposable (Playground, browser-only). - The Gutenberg-version list (22.7→23.6, ten linked posts) is the actual changelog surface — the beta-1 post itself is a curated digest, not the primary source of truth for what shipped. - "Enforced iframed editor" is the one item in the post with an explicit breaking-change warning for plugin/theme authors (Block API v2 or lower needs a v3 update) — everything else reads as additive. - The Connectors authentication item bundles a feature (username/app-password login) with a security fix (blocking browser autosuggest into the API key field) in the same bullet — worth separating when triaging for a security-focused audience. - "Mark as decorative" for images is the one explicitly accessibility-framed feature in the New Blocks section; screen-reader impact appears nowhere else in the post despite several UI changes (Omnibar persistence, revisions picker, command palette regrouping) that plausibly affect assistive-tech users. ## 📚 References - [WordPress 7.1 release schedule (Make Core)](https://make.wordpress.org/core/2026/07/03/wordpress-7-1-release-party-schedule/) — primary source for beta/RC dates - [Help test WordPress 7.1 (Make Test)](https://make.wordpress.org/test/2026/07/15/help-test-wordpress-7-1/) — primary source for what to test - [What's New in Gutenberg 23.5](https://make.wordpress.org/core/2026/07/01/whats-new-in-gutenberg-23-5-july-1-2026/) — most recent linked Gutenberg digest at time of writing - [Core Trac — major bugs](https://core.trac.wordpress.org/tickets/major) — known-issues tracker referenced for testers ## 🗣️ Paraphrase - **Testing mechanics paragraph**: Four ways exist to try the beta — a plugin-based channel switcher, a manual zip install, a WP-CLI one-liner, or an instant no-install Playground link — and the post is explicit that none of these belong on a live production site. - **Why testing matters paragraph**: Community testing is framed as a direct input to release quality, not a nice-to-have; the post routes bug reports to the support forum for informal reports and Trac for reproducible ones, and points to a running "known bugs" list so testers don't duplicate effort. - **Notes paragraph**: The commenting/annotation system inside the editor is maturing from a single flat thread per block into something closer to a real collaboration tool — multiple threads, inline anchoring, @mentions, and formatting. - **Styling paragraph**: Two long-requested capabilities — per-breakpoint styling and per-interaction-state styling — become editor-native, meaning site builders who previously needed a child theme or custom CSS for hover states or mobile-specific spacing can now do it through Global Styles or per-block controls. - **Media paragraph**: The upload/edit pipeline gets faster and more failure-tolerant by doing more processing in the browser, adds modern image formats (notably HEIC, since that's the iPhone default), and consolidates image editing into one modal instead of the older inline cropper. - **Admin paragraph**: A cluster of navigation and orientation fixes — persistent toolbar, smarter command palette grouping, color-scheme consistency, clearer revision history, a real UI fix for misthreaded comments, and a "look back" widget — aimed at making the admin feel less disjointed between the classic dashboard and the block-based editors. - **Developer paragraph**: API-facing changes (Abilities API, Block Bindings, custom icons, iframed editor enforcement, theme package review, Connectors auth) matter more to plugin/theme authors and integrators than to end users, and the iframed-editor item is the one with a concrete compatibility action required. ## 📰 Newsletter **WordPress 7.1 Beta 1 is out — kick the tires before August 19.** 🎉 If you've been waiting for hover-state styling without touching a CSS file, per-breakpoint block controls, or a Notes panel that finally supports @mentions and more than one conversation per block — Beta 1 has all of it. Spin it up in [WordPress Playground](https://playground.wordpress.net/?site-slug=kind-classic-mountain&networking=no&php=8.3&wp=beta&language=&multisite=no) with zero setup, or grab the [Beta Tester plugin](https://wordpress.org/plugins/wordpress-beta-tester/) on a throwaway install. Plugin and theme authors: check your Block API version. The editor now always runs iframed, and anything still on API v2 or lower needs a v3 update to keep rendering predictably. Media folks will appreciate HEIC support finally landing (yes, iPhone photos), plus AVIF, UltraHDR, and sturdier uploads that retry themselves when your Wi-Fi flakes out mid-transfer. Testing isn't glamorous, but it's the thing that keeps 7.1 from shipping surprises on release day — file what you find in the [Alpha/Beta forum](https://wordpress.org/support/forum/alphabeta/) or [Trac](https://core.trac.wordpress.org/newticket). Five weeks to go. ## ✅ Action Items #### DevRel - Developer advocacy: prep a short demo of interactive-state styling (hover/focus without CSS) for the next office hours or talk slot — it's a strong "look what you can do now" hook. - Education: draft a quickstart on the four Beta 1 testing paths, aimed at contributors who've never tested a beta before. - Developer experience: flag the Block API v3 enforcement change in any plugin/theme developer newsletter or changelog digest before RC. - Community management: monitor the Alpha/Beta support forum for recurring beta-1 issues to triage into Trac faster. #### OSPO - Security Management: track the Connectors credential-autosuggest fix as a security-relevant changelog line for any internal WordPress security digest. - Software Inventory: note the `wordpress/theme` package architecture review as a dependency-watch item for any theme tooling built on it. #### Community - Maintainers: circulate the "known bugs" Trac list to plugin/theme maintainers so QA doesn't duplicate already-tracked issues. - Contributors: recruit first-time testers via the Make Test post — low-barrier entry point for new contributors. #### WordPress - Core: confirm Block API v2→v3 migration guidance is linked from the Beta 1 post or a companion dev-note before RC. - Core Performance: verify client-side media processing claims (progress indicators, retry-on-drop) hold under real-world flaky connections, not just the demo case. - Core AI: the Abilities API querying/filtering refinements are explicitly framed for "AI tooling" — worth a dedicated dev-note walking through what changed for agent/automation builders. - Accessibility: audit whether Omnibar persistence, command palette regrouping, and the new revisions picker maintain keyboard/screen-reader parity with their prior single-purpose UIs — the post doesn't address this beyond the one "mark as decorative" image toggle. - Themes: alert theme authors to `theme.json` viewport breakpoint customization and the `wordpress/theme` package review — both are theme-author-facing changes needing dev-note coverage. - Plugins: alert plugin authors using inline cropping or old Media Editor patterns that a new unified Media Editor Modal is replacing prior UX. - Polyglots: flag the Unicode email address groundwork as relevant to translation/locale teams supporting non-Latin-script regions. - Support: prep Alpha/Beta forum moderators with a one-pager summarizing the five feature clusters so they can triage tester reports against the right area. #### The WPCC - Programs: no direct WPCC-specific action surfaced by this release-notes post; monitor for a funding/grants angle if any feature (e.g., Abilities API for AI tooling) becomes a fellowship or microgrant topic. ### FAIR - Not applicable to this source — the post contains no FAIR-network content (decentralized WordPress governance/federation); it's a Core release announcement. ## 🧪 Hypotheses - H1: Client-side media processing (browser-based format conversion) will measurably reduce server-side image-processing load and PHP memory spikes on shared hosting compared to WordPress 7.0. - H2: The Notes @mentions and multi-thread-per-block features will increase asynchronous collaboration activity (measured by Notes created per editing session) on multi-author sites after 7.1 ships. - H3: Enforced iframe isolation in the post editor will reduce the incidence of CSS-conflict bug reports between admin themes and block editor rendering, at the cost of a short-term spike in Block API v2 compatibility issues during the transition window. - H4: Interactive-state styling (hover/focus controls without custom CSS) will reduce the average number of custom-CSS snippets found in exported Global Styles JSON across a sample of sites upgrading to 7.1. - H5: HEIC/AVIF/UltraHDR support will reduce average uploaded-image file size on sites with a meaningful share of mobile (iPhone) contributors, compared to pre-7.1 JPEG-only fallback behavior. ### 📊 Methodology - H1/H5: Before/after telemetry comparison (opt-in, anonymized) of server resource usage and average media file size on a cohort of sites upgrading from 7.0 to 7.1, controlling for site traffic and media volume. - H2: A/B or before/after analysis of Notes usage logs (count, thread depth, mention frequency) on a sample of multi-author sites, comparing the 30 days before and after upgrade. - H3: Trac ticket tagging/classification of CSS-conflict vs. Block-API-compatibility bug reports filed in the 8 weeks surrounding the 7.1 release, compared to the same window around 7.0's release. - H4: Static analysis of Global Styles JSON exports (via a sampled, permissioned WordPress.org plugin telemetry or a volunteer-opt-in study) comparing custom-CSS block presence pre/post upgrade. ### ❓ Questions - What's the actual performance cost (CPU/battery) of moving media processing into the browser for users on low-power or older mobile devices? - Will the iframed-editor enforcement break more third-party blocks than anticipated, and is there a compatibility-shim path for unmaintained Block API v2 plugins? - How is "decorative image" detection surfaced to screen-reader users in practice — does the toggle actually strip alt-text semantics correctly across themes? - Does the Abilities API's AI-tooling framing signal a broader Core strategy for agent-driven site management, and if so, what's the security model for AI-initiated changes via Abilities? - Will Unicode email address support require corresponding changes in third-party auth/membership plugins that assume ASCII-only email validation? ### 🔮 Future Research - A systematic accessibility audit of the admin-navigation cluster (Omnibar, command palette, revisions picker) against WCAG 2.2 AA, since the post itself only addresses accessibility for one feature (decorative images). - Longitudinal tracking of Block API v2→v3 migration completion rates across the plugin directory following the iframed-editor enforcement. - A follow-up post or dev-note specifically for AI/automation builders using the expanded Abilities API, since this post only gestures at that audience in one bullet. ### 💡 Implications - **Practice**: Site builders and agencies should audit their custom CSS for hover/focus states and responsive breakpoints before 7.1 ships — much of it may become redundant, and maintaining both approaches risks specificity conflicts. - **Policy**: WordPress.org's plugin/theme review teams will likely need updated guidelines addressing Block API v3 compliance as a review criterion post-7.1. - **Security**: The Connectors credential-autosuggest fix is a reminder that admin-facing forms handling API keys need explicit `autocomplete="off"`-equivalent hardening; worth a broader audit of other secret-entry fields in wp-admin. - **Education**: New-contributor onboarding material (Make Test) gets a fresh, well-timed on-ramp with this beta cycle — a good moment for community education pushes. - **Funding**: No direct funding implications surfaced in this post; the Abilities API's AI-tooling framing could eventually intersect with sponsor interest in AI-WordPress integration work, but that's speculative from this source alone. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade ≈ 10–11 (technical release-notes prose, moderate sentence length, domain jargon like "Global Styles," "Block Bindings," "iframed editor" assumed familiar to the audience). #### 👀 Visual learners - Present: none — the source post (as scraped) contains no diagrams, screenshots, or labeled visuals despite describing highly visual UI changes (Omnibar, revisions picker, Media Editor Modal). - Improve: add before/after screenshots of the command palette regrouping, the new Media Editor Modal, and interactive-state style controls; a short GIF of hover-state styling in the editor would clarify the feature far faster than prose. #### 🔊 Aural learners - Present: none — text-only announcement. - Improve: a 2–3 minute audio changelog summary (common in WordPress "This Week in WP" style podcasts) covering the five feature clusters. #### 🗣️ Verbal learners - Present: the post defines new terms in context reasonably well (e.g., "Omnibar" is explained functionally on first use). - Improve: a short glossary callout for less-obvious terms (Block Bindings, Abilities API, Global Styles) would help readers unfamiliar with Core's internal vocabulary. #### 🧩 Kinesthetic learners - Present: the Playground link is a genuine hands-on, zero-setup testing path — strong fit for this learning style. - Improve: a step-by-step "try this in Playground" walkthrough (e.g., "open Playground → enable Notes → try an @mention") would convert the link into a guided lab. #### 🧠 Logical learners - Present: the feature list is organized into clear thematic clusters (Notes, Styling, Media, Admin, Blocks, Global audience, Developers). - Improve: a single summary table mapping feature → affected user role (site owner / editor / theme author / plugin author) would help logical learners triage relevance faster than prose scanning. #### 🧑‍🤝‍🧑 Social learners - Present: the post credits seven named contributors and links to community spaces (Slack #core-test, support forums). - Improve: an explicit call to discuss testing findings in a specific weekly Core-test meeting (with time/channel) would lower the barrier to social participation. #### 🧘‍♀️ Solitary learners - Present: the four independent testing paths (especially Playground and direct zip) support self-paced, solo exploration well. - Improve: a self-check list ("did you test X, Y, Z?") would help solo testers structure their own coverage without needing coordination. #### 🌿 Naturalistic learners - Present: none directly applicable — this is software release content with no ecosystem/environmental framing. - Improve: not applicable to this source — no natural-systems analogy is warranted for a release-notes post. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: the "mark as decorative" image toggle is the sole explicit screen-reader-facing feature mentioned. - Improve: the post gives no information on whether Omnibar persistence, the new Media Editor Modal, or the revisions picker were built/tested with proper landmarks and ARIA roles — this needs verification against the actual beta build, not assumed from the announcement. #### Keyboard navigation - Present: the command palette (Ctrl/Cmd+K) is inherently keyboard-first. - Improve: no mention of keyboard support for the new Tabs block (tabbed panels are a classic ARIA pattern that requires arrow-key navigation between tabs) — worth explicit verification. #### Contrast and readability - Present: not addressed in the source. - Improve: the Site Editor now reflecting admin color schemes could affect contrast ratios depending on scheme choice — worth a dedicated contrast check across all available admin color schemes. #### Text resizing and reflow - Present: not addressed in the source. - Improve: responsive/interactive styling controls are new enough that testers should explicitly verify 200%-zoom reflow behavior for blocks using the new breakpoint and hover/focus controls. #### Media and captions - Present: not addressed — the Playlist block's waveform visualization has no stated audio-description or transcript affordance mentioned in this post. - Improve: verify the Playlist block includes captions/transcript support, not just a visual waveform, before promoting it as an accessible way to "present podcasts, music, or audio content." #### Forms and interactions - Present: the Connectors screen fix (blocking credential autosuggest into the API key field) is a meaningful forms-security improvement. - Improve: no mention of inline validation or accessible error messaging for the new "In reply to" comment-parent dropdown or the Media Editor Modal's form controls. #### Standards reference - Gaps identified above (Tabs block keyboard pattern, Playlist block captions, admin color-scheme contrast, new-modal ARIA landmarks) map to WCAG 2.2 AA criteria 2.1.1 (Keyboard), 1.2.x (Time-based Media), 1.4.3 (Contrast), and 4.1.2 (Name, Role, Value) respectively — all need direct testing against the beta build rather than being inferable from the announcement text. ### 🌍 DEIB Assessment #### Cultural breadth - Present: the "Built for a global audience" section explicitly addresses Unicode email address support for non-Latin-script usernames/slugs/emails. - Improve: no mention of RTL (right-to-left) language support status for any of the new UI (Notes, Tabs block, Media Editor Modal) — worth flagging for Polyglots review. #### Inclusive language - Present: the post uses plain, jargon-light language relative to its technical subject; gender-neutral phrasing throughout. - Improve: terms like "Omnibar," "DataViews," and "Abilities API" are internal-community coinages without inline definition — a first-time reader outside Core contributor circles may struggle. #### Neurodiversity support - Present: the "Show more / show less" collapsing for long Notes reduces visual clutter, which incidentally helps neurodivergent readers manage information density. - Improve: the feature list itself is a long, dense wall of bolded sub-bullets with no visual chunking beyond headings — a scannable table (feature / one-line benefit) would reduce cognitive load. #### Representation - Present: the haiku-and-props tradition names and credits seven specific individual contributors by username, a small but consistent representation practice for the WordPress project. - Improve: no other representation signal present in this source type (a release-notes post isn't the right venue for broader representation claims). #### Psychological safety - Present: the post's tone toward testers is encouraging and low-pressure ("whether or not you have experience," "meaningful way for anyone to contribute"). - Improve: none needed — this is a reasonably safe, welcoming framing for an announcement of this kind. ### ✅ Logical Validity #### Strong reasoning - The post's structure is largely descriptive/enumerative rather than argumentative — it reports what changed rather than asserting contested claims, which limits the surface for logical fallacies. Where it does make a causal claim ("Testing... is a meaningful way... to contribute" implying tester participation improves release quality), the claim is well-supported by WordPress's actual open beta/RC process, which is documented and verifiable. - The compatibility warning about Block API v2 is a clear, specific, falsifiable technical claim (not a vague reassurance), which is a mark of good technical communication. #### Fallacies - No fallacies identified — this is a factual release-notes announcement with minimal persuasive/argumentative content. The genre (software changelog) doesn't invite the kind of reasoning errors this section is designed to catch. #### Tone of voice - Enthusiastic but restrained; typical WordPress.org release-post register — celebratory bolded feature names, a closing haiku as a light community in-joke, balanced against explicit, unambiguous safety warnings ("do not install, run, or test this version... on production or mission-critical websites"). ### 🛡️ DARVO Analysis - Not applicable to this source — DARVO (Deny/Attack/Reverse-victim-offender) analysis targets defensive rhetoric around an accusation or wrongdoing; this is a routine software release announcement with no accusation, conflict, or defensive framing present. ## 🎯 Conclusion - WordPress 7.1 Beta 1 is available now across four testing paths, with final release targeted for August 19, 2026. The release bundles roughly ten Gutenberg-plugin release cycles' worth of features into Core, organized around five clusters: richer Notes collaboration, no-code responsive/interactive styling, a faster and more format-flexible media pipeline, a more consistent and navigable admin, and expanded developer/API surface (with one concrete breaking change: Block API v2 support requires a v3 update under the newly-enforced iframed editor). - Practical next steps for readers: (1) spin up the release in Playground or a disposable local site, (2) if you maintain a plugin/theme using Block API v2 or lower, start the v3 migration now rather than waiting for RC, (3) file any bugs found via the Alpha/Beta forum (informal) or Trac (reproducible), checking the known-bugs list first, (4) theme authors should review the new `theme.json` breakpoint customization and the `wordpress/theme` package changes ahead of the stable release. ## 🔄 Refactor Appendix — WordPress 7.1 Beta 1 ### 📚 Literature Atoms (H3) #### [H1] Enforced iframed editor requires Block API v3 > [!quote] ID:rw_wp71b1_iframe > "The post editor now always runs inside an iframe, isolating the editing canvas from admin styles for more predictable rendering. Blocks using Block API v2 or lower should be updated to v3 for compatibility." **Context & use**: - Built for developers section, WordPress 7.1 Beta 1 announcement - The one explicit breaking-change warning in the entire post — directly actionable for any plugin/theme author still on Block API v2 **Tags**: #xref **Highlight**: [view highlight](readwise://wp71b1_iframe) <!-- atomicity: 1 idea ✓ --> #### [H2] Client-side media processing adds HEIC, AVIF, UltraHDR support > [!quote] ID:rw_wp71b1_media > "Image and media processing moves into the browser, now with broader format support that includes HEIC (the default format for iPhone photos), UltraHDR, AVIF and WebP support built in, plus GIF-to-video conversion for lighter, more efficient files." **Context & use**: - "A smoother media experience" section - Directly relevant to any content team where contributors upload from iPhones — HEIC has historically required a server-side conversion plugin **Tags**: #xref **Highlight**: [view highlight](readwise://wp71b1_media) <!-- atomicity: 1 idea ✓ --> #### [H3] Interactive-state and responsive styling now editor-native > [!quote] ID:rw_wp71b1_styling > "Style how blocks respond to interaction, like a button changing color on hover or focus, using a standardized set of controls for both Global Styles and individual block instances." **Context & use**: - "Style it your way, on any screen" section - Removes a common reason site builders reach for custom CSS or a child theme **Tags**: #xref **Highlight**: [view highlight](readwise://wp71b1_styling) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Release-notes posts signal breaking changes by specificity, not volume **Claim** (one sentence, Courtney's voice): When a software release-notes post is otherwise purely additive in tone, the one item phrased as a specific, falsifiable compatibility requirement (not a vague caveat) is the one worth treating as an actual action item. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds for well-edited, high-volume open-source changelogs (WordPress Core, similar large projects) where enumerative feature lists dominate; breaks down for changelogs that bury breaking changes in prose or where "improvements" and "breaking changes" aren't distinguishable by phrasing alone. **Links**: - [[WordPress core release process]] — because applies-in Core beta/RC review <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Check whether the Playlist block's waveform visualization ships with a captions/transcript affordance, or if it's visual-only — accessibility gap worth flagging. #fleeting #inbox - [F2] The Abilities API's explicit "AI tooling" framing in this release is worth tracking across future WordPress core posts as a signal of Core's AI/agent strategy. #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Audit courtneyr.dev and Outpost & Co. plugin blocks for Block API version — confirm none are still on v2 before WordPress 7.1 RC — WordPress 7.1 compatibility #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/WordPress 7.1 Beta 1.md|WordPress 7.1 Beta 1 by wordpress.org]] ## Highlights - - **Client-side media processing**: Image and media processing moves into the browser, now with broader format support that includes HEIC (the default format for iPhone photos), UltraHDR, AVIF and WebP support built in, plus GIF-to-video conversion for lighter, more efficient files. Uploads are also more resilient, with a progress indicator and automatic retries if your data connectivity drops off. ([View Highlight](https://read.readwise.io/read/01kxneypf1yy94y0b1mn9814gn)) - Note: HEIC support closes a long-standing gap for iPhone-sourced media uploads. - Tags: atom/literature/h2 - - **Enforced iframed editor**: The post editor now always runs inside an iframe, isolating the editing canvas from admin styles for more predictable rendering. Blocks using Block API v2 or lower should be updated to v3 for compatibility. ([View Highlight](https://read.readwise.io/read/01kxneynshtxfqy39pz2qwngab)) - Note: Only explicit breaking-change warning in the post — actionable for plugin/theme authors on Block API v2. - Tags: atom/literature/h1