WordPress 7.1 Field Guide - CourtneyR.dev's 2nd Brain

WordPress 7.1 Field Guide ![rw-book-cover](https://d34adp677peecb.cloudfront.net/static/images/article0.00998d930354.png) 🔗 **Source:** [WordPress 7.1 Field Guide](https://make.wordpress.org/core/2026/08/05/wordpress-7-1-field-guide/) > [!note]+ Document Notes > tags: [wordpress-core, wordpress-7-1, developer-notes, release-preparation, block-editor, backward-compatibility] > author: Milana Cap > source: Make WordPress Core > reference: https://make.wordpress.org/core/2026/08/05/wordpress-7-1-field-guide/ > date created: 2026-08-05 11:11 > > # 🏷️ Title: WordPress 7.1 Field Guide >  ## 🧭 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 7.1 Field Guide](https://make.wordpress.org/core/2026/08/05/wordpress-7-1-field-guide/) - [WordPress 7.1 release schedule](https://make.wordpress.org/core/7-1/) ## 📝 Summary - WordPress 7.1 includes more than 310 closed Core Trac tickets, including over 100 enhancements and feature requests and more than 180 bug fixes. The guide also counts almost 600 Gutenberg enhancements and more than 630 Gutenberg bug fixes. - Major developer-facing areas include client-side media processing, accessibility, the Abilities API, Global Styles, the SVG Icon API, DataViews and DataForm, the iframed editor, design-system theming, the persistent admin bar, and updated external libraries. - Plugin and theme developers are the main risk owners because several changes alter editor document boundaries, REST schema output, media behavior, toolbar navigation, component behavior, and third-party dependency expectations. - The guide names deferred work as carefully as shipped work: React 19, real-time collaboration, the On This Day widget, and broader merge proposals aren't part of WordPress 7.1. - Bottom line: treat the field guide as the official compatibility map, then test each relevant dev note against a pinned 7.1 release candidate or final build. ## 📖 Main Content - The guide is a release-routing document. It groups changes by developer impact and points to dev notes, Trac tickets, and Gutenberg work for implementation details. - Media work moves supported image operations into the browser before upload and expands REST support for dimension checks, quality choices, and registering one sideloaded file across image sizes. Infinite scrolling becomes the Media Library grid default, with a per-user opt-out. - Accessibility work changes list-table semantics, introduces a shared accessible tooltip mechanism, and improves focus, contrast, keyboard, pointer, setup, widget, navigation, and editor behavior. - The Abilities API gains filtered discovery, execution lifecycle hooks, a unified public exposure flag, client-compatible JSON Schema preparation, and smaller refinements. These changes affect both server registration and external clients. - Editor work includes new block supports, editable supported blocks inside Custom HTML preview, and completion of the iframe-based post editor even when legacy meta boxes exist. Plugins that reach across the editor document boundary must test JavaScript and CSS assumptions. - The release also adds design-system theming foundations, keeps the toolbar present through supported editor navigation, and updates jQuery UI to 1.14.2. - Release counts and dev notes describe scope, not runtime proof. A target build, fixtures, and observed results are still required before claiming compatibility. ### 🗒️ Notes - The field guide was published during the release-candidate phase and targets extenders, Core developers, and others tracking WordPress development. - Its ticket and line-change counts communicate size but don't measure risk. One boundary change can matter more to a plugin than hundreds of unrelated fixes. - Client-side media processing shifts part of the upload pipeline into the browser. Test format support, large images, failed transforms, sideload registration, and server fallback behavior. - Media Library infinite scrolling changes the default browsing pattern. Test keyboard movement, screen-reader announcements, large libraries, selection state, and the per-user opt-out. - Accessible tooltips replace title-attribute and pointer-only patterns with a shared convention. Test naming, description, focus order, escape behavior, hover, touch, and zoom. - Changed row headers improve list-table semantics but may expose brittle selectors or custom-column assumptions. - The Abilities API public flag and JSON Schema preparation are linked concerns: discovery must match exposure policy, and exposed schemas must remain consumable by clients. - Global Styles gains responsive variations, configurable viewports, more interaction states, and text shadow. Theme authors should test serialization, inheritance, presets, and editor/front-end parity. - The SVG Icon API creates a standard registration and rendering path. Check escaping, accessible names, view boxes, theming, and duplicate identifiers. - DataViews, DataForm, and View Config continue to change. Extensions should test supported views and layouts instead of depending on internal component shape. - The enforced editor iframe is the highest-risk boundary change for extensions that query the parent document, inject global CSS, bind document-level events, or assume meta boxes disable iframe mode. - Persistent toolbar navigation raises lifecycle questions for extensions during client-side navigation: mount, unmount, state reset, and stale handlers. - jQuery UI 1.14.2 needs focused regression tests for plugins that depend on its interaction behavior or styling. - The guide correctly records exclusions. React 19 and real-time collaboration remain outside the shipped 7.1 scope, so they shouldn't appear in compatibility claims for this release. ## 📚 References - [WordPress 7.1 Field Guide](https://make.wordpress.org/core/2026/08/05/wordpress-7-1-field-guide/) - [Client-Side Media Processing in WordPress 7.1](https://make.wordpress.org/core/2026/07/22/client-side-media-processing-in-wordpress-7-1/) - [Post list tables row headers changed](https://make.wordpress.org/core/2026/08/03/post-list-tables-row-headers-changed/) - [Introducing name and informational tool tips in WordPress 7.1](https://make.wordpress.org/core/2026/08/03/introducing-name-and-informational-tool-tips-in-wordpress-7-1/) - [A unified public exposure flag for Abilities in WordPress 7.1](https://make.wordpress.org/core/2026/08/04/a-unified-public-exposure-flag-for-abilities-in-wordpress-7-1/) - [JSON Schema preparation for client compatibility in WordPress 7.1](https://make.wordpress.org/core/2026/07/31/json-schema-preparation-for-client-compatibility-in-wordpress-7-1/) - [Iframed Editor Changes in WordPress 7.1](https://make.wordpress.org/core/2026/08/03/iframed-editor-changes-in-wordpress-7-1/) - [Miscellaneous Editor Changes in WordPress 7.1](https://make.wordpress.org/core/2026/08/04/miscellaneous-block-editor-changes-in-wordpress-7-1/) - [React 19: punted beyond WordPress 7.1](https://make.wordpress.org/core/2026/07/24/react-19-punted-beyond-wordpress-7-1-experiment-in-gutenberg/) ## 🗣️ Paraphrase WordPress 7.1 is broad, but the practical developer story is a set of changed boundaries: more media work happens in the browser, accessibility semantics are stricter, abilities are easier to expose to clients, style and data APIs expand, and the post editor consistently lives in an iframe. The safest response isn't to scan the ticket count and assume compatibility. Map each product's integration points to the linked dev notes, run controlled tests on a pinned build, and keep deferred experiments out of 7.1 claims. ## 📰 Newsletter WordPress 7.1's Field Guide is the compatibility map worth keeping beside your test plan. The release touches media processing, accessible admin patterns, the Abilities API, Global Styles, DataViews, the editor iframe, toolbar navigation, and bundled libraries. The most useful detail may be the boundary list: React 19 and real-time collaboration didn't ship. Start with the [Field Guide](https://make.wordpress.org/core/2026/08/05/wordpress-7-1-field-guide/), follow only the dev notes that intersect your code, and test those paths on a pinned build. ## ✅ Action Items #### DevRel - Publish a change-to-audience matrix for plugin, theme, agency, host, and client developers. - Build short demos for the editor iframe, client-side media, accessible tooltips, and public abilities. - Track questions and failures by dev-note area, then route evidence to the owning Core component. #### OSPO - Record 7.1 dependency, license, security, and contribution-policy changes. - Help downstream teams distinguish shipped Core behavior from experimental Gutenberg work. - Keep a public compatibility evidence format that names build, fixture, expected state, and result. #### Community - Host contributor testing sessions around high-risk extension boundaries. - Pair maintainers with accessibility and API reviewers. - Share sponsor-supported test outcomes without turning sponsorship into release authority. #### WordPress - Core: maintain the field guide as a release-scoped index and correct stale inclusion claims. - Core Performance: profile media processing, large Media Libraries, and theme JSON paths. - Core AI: test Abilities API exposure and schema behavior with mixed ability calls. - Core Program Team: track cross-component blockers and publish release-scope changes. - Mobile: test REST schema and media-upload effects in app clients. - Playground: publish reproducible 7.1 extension fixtures. - Community: recruit plugin, theme, host, and assistive-technology testers. - Training: create labs for the iframe boundary, abilities, and new style APIs. - Marketing: keep shipped, experimental, and deferred claims distinct. - Support: prepare triage prompts for media, editor, and toolbar regressions. - Design: document token and interaction-state behavior. - Documentation: connect API references to migration examples. - Photos: check image upload and metadata workflows. - TV: test media and caption management paths. - Polyglots: review new interface strings and tooltip context. - Accessibility: audit row headers, tooltips, infinite scroll, focus, and reflow. - Meta: monitor Make/Core links, profiles, and contributor tooling. - CLI: add smoke-test recipes for plugin and theme compatibility. - Hosting: test upload limits, REST media paths, cron, multisite HTTPS, and PHP matrices. - Tide: scan ecosystem code for risky iframe, jQuery UI, and title-attribute patterns. - Openverse: test media ingestion and metadata against changed endpoints. - Themes: test Global Styles, templates, viewports, pseudo states, and editor parity. - Plugins: test document-boundary code, toolbar items, abilities, schemas, and dependency behavior. #### The WPOCC - Fund small compatibility sprints and maintainers working on affected extensions. - Require public milestones, reproducible fixtures, and outcome reports. ### FAIR - Keep compatibility artifacts portable and independently repeatable. - Publish operator responsibilities, funding relationships, and sunset conditions. - Sign release-test manifests so downstream claims can be traced to a build and fixture. ## 🧪 Hypotheses - Plugins that query the top-level editor document will show more regressions than plugins using supported editor APIs. - Client-side media processing will reduce server work for supported images but expose browser-memory and format-support differences. - A unified public abilities flag will reduce exposure inconsistency across REST and external-client integrations. - Shared accessible tooltips will improve keyboard and screen-reader access when implementations follow the documented pattern. - Explicitly listing deferred features will reduce false 7.1 compatibility claims. ### 📊 Methodology - Pin WordPress 7.0.2 as control and a specific 7.1 RC or final build as treatment; record commit or package identity. - Build fixtures for legacy meta boxes, custom editor scripts and styles, media uploads, public and private abilities, schema edge cases, DataViews, toolbar items, and block style variations. - Run browser, REST, PHPUnit, visual-regression, keyboard, screen-reader, zoom, and multisite checks. - Compare exact outputs: DOM boundary, registered hooks, REST schemas, capability decisions, media metadata, generated markup, console errors, and network requests. - Restore fixtures and rerun cleanly. Treat dev-note claims as expected behavior and observed test output as evidence. ### ❓ Questions - Which editor extensions still rely on parent-document selectors or global CSS? - How do browsers differ in memory use and output quality for client-side image processing? - Can an ability be discoverable through one path while correctly hidden through another? - Which View Config and component APIs are stable enough for third-party production use? - What migration signals will warn developers before a future React 19 release? ### 🔮 Future Research - Measure plugin-directory use of cross-frame DOM access and deprecated tooltip patterns. - Build a client-compatibility corpus for unusual but valid JSON Schemas. - Compare Media Library infinite-scroll accessibility across assistive technologies. - Track deferred initiatives separately so future field guides can show when and why scope changed. ### 💡 Implications - Practice: compatibility work should follow integration boundaries, not ticket volume. - Policy: release communications need explicit shipped, experimental, and deferred labels. - Security: public ability exposure and SVG rendering require least-exposure and output-safety checks. - Education: examples should pair a migration pattern with a reproducible test. - Funding: sponsors can fund ecosystem testing while evidence and release decisions remain public. ### 🧠 Learning Styles Assessment - Reading level estimate: roughly grade 14 by Flesch-Kincaid because the guide uses long sentences, API terms, and WordPress-specific vocabulary. #### 👀 Visual learners - Present: headings, lists, counts, and embedded dev-note cards. - Improve: add a shipped/deferred matrix and before/after boundary diagrams. #### 🔊 Aural learners - Present: no audio version is linked. - Improve: add a short narrated release-risk overview. #### 🗣️ Verbal learners - Present: short feature summaries and glossary expansions. - Improve: define the practical consequence of each API change in one sentence. #### 🧩 Kinesthetic learners - Present: links to implementation notes and tickets. - Improve: add copyable test recipes and Playground blueprints. #### 🧠 Logical learners - Present: categorized scope and quantitative release counts. - Improve: add a dependency map from changes to affected extension patterns. #### 🧑‍🤝‍🧑 Social learners - Present: contributor attribution and public discussion links. - Improve: add testing-session and support-channel routes. #### 🧘‍♀️ Solitary learners - Present: the guide supports self-directed reading. - Improve: add a personal compatibility checklist. #### 🌿 Naturalistic learners - Present: ecosystem scope is implicit. - Improve: show lifecycle costs for browser, server, and dependency changes. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: structured headings, navigation, links, and an accessible-changes section. - Improve: reduce glossary duplication in extracted text and confirm embedded cards have useful names. #### Keyboard navigation - Present: the source discusses keyboard and focus improvements. - Improve: publish keyboard test steps for tooltips, lists, and infinite scrolling. #### Contrast and readability - Present: short grouped sections aid scanning. - Improve: verify embedded cards and code against WCAG 2.2 AA contrast. #### Text resizing and reflow - Present: core block markup should reflow. - Improve: test long glossary popovers and the table of contents at 200% and 400%. #### Media and captions - Present: no essential audio or video is required. - Improve: caption any future demos and provide transcripts. #### Forms and interactions - Present: the guide calls out names, tooltips, focus, and pointer interaction. - Improve: document error and dismissal behavior for each shared pattern. #### Standards reference - Map checks to WCAG 2.2 AA, especially 1.3.1, 1.4.3, 1.4.10, 2.1.1, 2.4.3, 2.4.7, 2.5.8, 3.3.2, and 4.1.2. ### 🌍 DEIB Assessment #### Cultural breadth - Present: the open project and contributor model has global reach. - Improve: link locale, multilingual, RTL, and regional-device test results. #### Inclusive language - Present: the article generally uses role-based, neutral language. - Improve: reduce unexplained jargon outside glossary widgets. #### Neurodiversity support - Present: predictable categories and a table of contents. - Improve: add a compact risk summary and consistent labels for required action. #### Representation - Present: contributor credits identify collaborators. - Improve: report testing participation by role and region without tokenizing contributors. #### Psychological safety - Present: deferred work is framed as validation, not failure. - Improve: provide clear, respectful bug-reporting and escalation routes. ### ✅ Logical Validity #### Strong reasoning - The guide uses classification well: feature areas and linked dev notes let readers trace claims to implementation discussions. - It explicitly distinguishes included work from deferred work, which prevents a common scope error. - Quantitative counts support the claim that 7.1 is broad, though they don't establish risk or quality. #### Fallacies - No major formal fallacy drives the article. - Possible metric substitution: ticket and line counts can be mistaken for impact. Fix by pairing counts with compatibility severity and affected extension patterns. - Possible appeal to authority if the guide is treated as runtime proof. Fix by naming it as an authoritative scope index and pairing it with executed tests. #### Tone of voice - Factual, appreciative, and developer-oriented. The article balances release celebration with concrete cautions and deferred scope. ### 🛡️ DARVO Analysis - Not applicable. The guide doesn't respond to allegations or use denial, attack, or victim-offender reversal. ## 🎯 Conclusion WordPress 7.1 changes several boundaries that extensions depend on: browser-side media work, accessibility semantics, ability exposure, client schemas, editor framing, navigation lifecycle, style systems, and libraries. Use the field guide to select tests, use linked dev notes to define expected behavior, and use a pinned build plus controlled fixtures to establish compatibility. ## 🔄 Refactor Appendix — WordPress 7.1 Field Guide > [!question] Lingering Questions > - Which plugin patterns still cross the editor iframe boundary? > - Which JSON Schema shapes remain difficult for common clients? > [!idea] Article Ideas > - A release-audit matrix for WordPress 7.1 extension boundaries. > [!info] Cross Reference > - [[WordPress 7.1]] — because extends the release compatibility evidence map. > - [[Abilities API]] — because applies-in public exposure and client schema testing. > [!example] Fiction & Worldbuilding > [!abstract] Vocabulary > - Field guide: a release-scoped index of developer changes and migration notes. ### → Things 3 action handoff - [ ] Build a WordPress 7.1 boundary-focused extension test matrix — context #things - [ ] Run iframe, abilities, media, and accessibility fixtures on a pinned RC — context #things ### Bib capsule - Milana Cap, “WordPress 7.1 Field Guide,” Make WordPress Core, August 5, 2026. ### Author's thesis - WordPress 7.1 contains a wide set of developer-facing changes, and extenders should use the guide and linked dev notes to prepare and test. ### Key arguments - Browser media APIs, accessibility conventions, ability exposure, and editor framing change extension touchpoints. - Expanded style, data, icon, and component APIs create new supported paths. - Deferred experiments aren't part of WordPress 7.1 and must remain outside release claims. ### New media APIs move work before upload > [!quote] ID:rw_01kz97avvhnped5pm1tjyy2hxb > New client-side media processing APIs allow supported image operations to happen in the browser before a file is uploaded. Related REST API changes support validating image dimensions, selecting size-aware encoding quality, and registering a sideloaded file for multiple image sizes. > > [view highlight](https://read.readwise.io/read/01kz97avvhnped5pm1tjyy2hxb)  ### Accessible tooltips replace fragile title patterns > [!quote] ID:rw_01kz97ay6530r8ss3cca5w6az9 > WordPress 7.1 introduces a shared mechanism for accessible name and informational tooltips. Core now uses this mechanism in selected interfaces, giving developers a consistent pattern for presenting supplementary information without relying on inaccessible title attributes or pointer-only interactions. > > [view highlight](https://read.readwise.io/read/01kz97ay6530r8ss3cca5w6az9)  ### Public abilities need client-safe schemas > [!quote] ID:rw_01kz97atddgcejed9gy45tsbmr > WordPress 7.1 builds on the Abilities API introduced in WordPress 6.9, making abilities easier to discover, expose, validate, and integrate with external clients. The release adds filtering to `wp_get_abilities()`, execution lifecycle hooks, a unified `public` exposure flag, client-compatible JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. Schema preparation, and several smaller API refinements. > > [view highlight](https://read.readwise.io/read/01kz97atddgcejed9gy45tsbmr)  ### Editor extensions must respect iframe boundaries > [!quote] ID:rw_01kz97awwffynknt725tgj8980 > WordPress 7.1 completes the move to an iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser.-based post editor, including for sites that register legacy metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes. This creates a more consistent editing environment, but plugins that rely on reaching across the editor document boundary should review their JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. > [https://www.javascript.com](https://www.javascript.com/) and CSSCSS Cascading Style Sheets. for compatibility. > > [view highlight](https://read.readwise.io/read/01kz97awwffynknt725tgj8980)  ### Release boundaries include explicit exclusions > [!quote] ID:rw_01kz97az8rbjftk49brn58ratm > Not every feature explored during the release cycle was ultimately included in WordPress 7.1. The following initiatives were deferred, changed direction, or remained experimental, giving contributors more time to validate their design and implementation before they reach Core. > > [view highlight](https://read.readwise.io/read/01kz97az8rbjftk49brn58ratm)  ### 🧠 Permanent Candidates #### Release notes define scope, not runtime proof - An official field guide identifies expected scope, while executed tests establish behavior. - [[WordPress release auditing]] — because extends the evidence hierarchy for release claims.  #### Compatibility tests follow changed boundaries - A compatibility plan starts with changed integration boundaries. - [[Extension compatibility matrix]] — because applies-in WordPress release testing.  ### ✏️ Fleeting Queue - Compare current plugin code against editor iframe and public-ability exposure patterns. - Turn the field guide's shipped/deferred split into a reusable release checklist. Processed: WordPress 7.1 Field Guide - Literature atoms: 5 / 5 cap - Permanent candidates: 2 / 3 cap - Fleeting items: 2 - Things 3 actions: 2 / 2 cap - Konik tags used: [#xref, #articleseed] - Triage callouts populated: [Lingering Questions, Article Ideas, Cross Reference, Vocabulary] - Quality gates: [✓ verbatim quotes, ✓ atomicity, ✓ annotated links, ✓ YAML hygiene, ✓ triage routing, ✓ highlight links] - Override conditions triggered: dense release guide uses 5 literature atoms  📄 **Full text:** [[Full Document Contents/Articles/WordPress 7.1 Field Guide.md|WordPress 7.1 Field Guide by Milana Cap]] ## Highlights - New client-side media processing APIs allow supported image operations to happen in the browser before a file is uploaded. Related REST API changes support validating image dimensions, selecting size-aware encoding quality, and registering a sideloaded file for multiple image sizes. ([View Highlight](https://read.readwise.io/read/01kz97avvhnped5pm1tjyy2hxb)) - Note: Client-side media work moves supported image operations into the browser and adds REST validation and registration support. - Tags: media-api, atom/literature/h1, wordpress-7-1 - WordPress 7.1 introduces a shared mechanism for accessible name and informational tooltips. Core now uses this mechanism in selected interfaces, giving developers a consistent pattern for presenting supplementary information without relying on inaccessible title attributes or pointer-only interactions. ([View Highlight](https://read.readwise.io/read/01kz97ay6530r8ss3cca5w6az9)) - Note: The shared tooltip mechanism replaces fragile title-attribute and pointer-only patterns with an accessible core convention. - Tags: atom/literature/h2, accessibility, wordpress-7-1 - WordPress 7.1 builds on the Abilities API introduced in WordPress 6.9, making abilities easier to discover, expose, validate, and integrate with external clients. The release adds filtering to `wp_get_abilities()`, execution lifecycle hooks, a unified `public` exposure flag, client-compatible JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. Schema preparation, and several smaller API refinements. ([View Highlight](https://read.readwise.io/read/01kz97atddgcejed9gy45tsbmr)) - Note: Abilities API changes improve discovery, validation, lifecycle observation, public exposure, and client compatibility. - Tags: wordpress-7-1, abilities-api, atom/literature/h3 - WordPress 7.1 completes the move to an iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser.-based post editor, including for sites that register legacy metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes. This creates a more consistent editing environment, but plugins that rely on reaching across the editor document boundary should review their JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. [https://www.javascript.com](https://www.javascript.com/) and CSSCSS Cascading Style Sheets. for compatibility. ([View Highlight](https://read.readwise.io/read/01kz97awwffynknt725tgj8980)) - Note: The post editor now consistently uses an iframe, including on sites with legacy meta boxes, so cross-frame assumptions require testing. - Tags: wordpress-7-1, atom/literature/h4, block-editor - Not every feature explored during the release cycle was ultimately included in WordPress 7.1. The following initiatives were deferred, changed direction, or remained experimental, giving contributors more time to validate their design and implementation before they reach Core. ([View Highlight](https://read.readwise.io/read/01kz97az8rbjftk49brn58ratm)) - Note: The field guide explicitly separates shipped work from deferred or experimental initiatives. - Tags: wordpress-7-1, release-scope, atom/literature/h5