The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site forย general updates, status reports, and the occasional code debate. Thereโs lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
WordPress 7.1 is set to be released on August 19th, 2026. This release advances how people work together in WordPress and opens up new functionality for all to benefit from. New Notes features, including suggestion mode and emoji reactions, make asynchronous feedback richer and more interactive. Meanwhile, real-time collaboration remains an exciting focus area with a few strategic decisions remaining to shape exactly how itโll show up in the WordPress experience. New options for responsive styling and pseudo-state styling, two longstanding areas of feedback, expand what you can do directly in the Site Editor without needing to use CSSCSSCascading Style Sheets.. A new Guidelines feature adds a persistent, structured way to encode editorial rules into WordPress, helping you keep your voice and preferences when collaborating with AI. Several new options make it easier to find your way around: see when a blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. inherits its styling from a global setting, set key details about your site in a new Identity section in the Site Editor, find what you need faster with recently used commands and suggestions shown in the command palette, and enjoy the familiarity of the adminadmin(and super admin) bar inside any of the editors. The experience of uploading and using media gets numerous updates, including a new free-form image cropper to get your images just right and client-side media improvements that support more image formats and add resiliency throughout. For those building on top of WordPress, numerous APIs are slated for more features and fixes. Expanded Unicode support is in the works so email addresses, usernames, and slugs can better reflect WordPressโ global audience. Finally, to round out the release are a slew of smaller yet important delights like a new โOn This Dayโ dashboardย widgetWidgetA WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user., new blocks, and various writing flow improvements.
As always, whatโs shared here is being actively pursued, but doesnโt necessarily mean each will make it into the final release of WordPress 7.1.
For those who want to be involved in the release in a different, more hands on way, thereโs a new dedicated outreach effort for WordPress 7.1 to ensure collaborative editing gets the collaborative testing it needs. Learn more here.ย
AI
AI Client iteration
The AI Client is the foundational piece for running AI programmatically inside WordPress, and for 7.1 the focus stays on empowering pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. authors. Two notable capabilitiescapabilityAย capabilityย is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on theirย role. For example, users who have the Author role usually have permission to edit their own posts (the โedit_postsโ capability), but not permission to edit other usersโ posts (the โedit_others_postsโ capability). are planned: generation streaming, introduced first in the PHP AI Client as an initial effort to unlock full usage in a future release, and embeddings, which represent content as vectors to enable meaning-based search across a site. These arrive alongside minor fixes that keep improving the reliability of the AI Client.
After landing a new framework for registering and managing connections to external services in 7.0, work is underway for connectors to gain more ways to authenticate beyond APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. keys. The plan is to start simple with adding username/application password support similar to the existing API key flow and then explore more general, declaratively-defined connection forms (URLs, a default-models dropdown, and more) in PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher, advancing the DataForm API in the process.ย
After shipping early as an experiment in GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses โblocksโ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/ to gather feedback, a new Guidelines feature lets you define writing and content guidelines that tie into AI tooling, with the ability to import/export guidelines between sites. This brings a persistent, structured system for encoding editorial rules, brand voice, and content standards directly into WordPress for humans and AI alike. As more collaboration happens directly in WordPress, this brings consistency and personalization to that collaboration.
The command palette now groups results into clear sections for recent, suggested, and matching commands. The recently used list is saved to your preferences so they persist across sessions. The design was also updated to make the list of resulting commands easier to scan and understand.
The Site Editor sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. and overall shell now follow the set WordPress admin color scheme instead of always using a fixed dark background. This ensures broader consistency across all parts of the WordPress experience when personalizing the admin with a color scheme of your choosing.
Work is underway to migrate DataViews onto the new Design System primitives for a more consistent look and feel, and to consolidate Quick Edit with the editor inspector so editing a postโs details feels the same wherever you do it. The DataForm API itself is growing more capable, including support for disabling individual controls. The Site Editorโs Pages, Templates, and Patterns screens are also becoming more extensibleExtensibleThis is the ability to add additional functionality to the code. Plugins extend the WordPress core software., with a new server-side REST endpoint that lets plugin authors register their own view and form configuration.
A dedicated Design โ Identity screen brings the essentials of your siteโs identity into one place, with an inline media editor for your logo and favicon and quick editing of your site title and tagline. The aim is to make these foundational settings simple to find and easy to update without digging into templates or needing to go searching in Settings.ย
Work continues on the shared component library in wordpress/ui and the underlying theming system that powers it. A highlight of this cycle is graduating ThemeProvider from experimental to a stable, public API, alongside finalizing the public token names (background, foreground, and stroke renames), and adding new theme-customization tokens for corner radius and element sizing. In parallel, key parts of the editor UIUIUser interface begin adopting improved components, with flyout menus extending to transforms, style variations, and the block ellipsis and transform menus.
The dashboard is getting a new โOn This Dayโ widget that resurfaces past content, a popular feature across many different platforms.ย Get motivated by looking back on what youโve written and write more content today for future reminders.
Followthis pull request introducing the โOn This Dayโ widget for more information.
Persistent admin bar across editors (aka omnibar)
The admin bar is getting some nice polish ahead of being easily accessible in the Site Editor and Block Editor. Having landed as an experiment in Gutenberg first, this work brings the toolbar into the editing experience so the admin bar is with you wherever you are. The design update removes the โHowdyโ greeting, replaces the home icon with the site icon, makes the profile avatarAvatarAn avatar is an image or illustration that specifically refers to a character that represents an online user. Itโs usually a square box that appears next to the userโs name. a circle rather than a square, and updates the legacy Dashicons icon font with wordpress/icons SVGs throughout the admin bar.
RevisionsRevisionsThe WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. iterations
After landing visual revisions in 7.0, this release focuses on making them even easier to read and navigate between. Planned improvements include a spark line view in the scrubbing toolbar to better visualize the history of changes, persistent URLs to allow sharing a link to a particular revision, and more.
The Abilities API gives developers and AI tooling a structured, queryable way to expose what a WordPress site can do. This cycle advances querying and filtering of abilities and implements a curated set of coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. abilities (including site settings, current-user info management, and general site awareness).
The post editor has been moving toward always running inside an iframeiframeiFrame 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., which isolates the editing canvas from the adminโs styles and lets viewport-relative units and media queries work against the canvas instead of the browser window. Today the editor still drops back to a non-iframed mode whenever a block using Block API version 2 or lower is present. To make the rollout gradual, the current plan is to enforce iframing for block-based themes in this release, then extend it to all themes in a future release. In both cases, blocks need to be on Block API version 3 to work in the iframed editor, and a migrationMigrationMoving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. guide is available to help extenders get there.
Extended Unicode support in email addresses, usernames, and slugs
This release is looking to broaden Unicode support so email addresses, usernames, and slugs better reflect WordPressโ global audience. This work centers around allowing storing Unicode email addresses (Core-31992) so functions like is_email(), sanitize_email() and antispambot() can be extended to support non-ASCII addresses.ย
ReactReactReact is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces.
https://reactjs.org 19 Upgrade
WordPress is upgrading from React 18 to React 19. This update will first be merged into the Gutenberg plugin ahead of an eventual pathway to Core. In this upgrade, there are several new APIs, major updates to TypeScript types, changed behaviors and more. Plugin and theme developers, please help test and review whatโs coming as early and as much as possible. To help with testing, install and activate the latest version of Gutenberg, head to the experiments page, and turn on the โReact 19โ experiment.
After WordPress 7.0 introduced the foundations of the SVG Icon API (the icon registry, a REST endpoint, and the core Icon block), 7.1โs iteration centers on opening the API up to third parties with new public functions like register_icon() and unregister_icon(), core-icons theme support, SVG sanitization and namespace validation, and collection support (similar to the Font Library) so agencies and product makers can ship their own branded icon sets. The work also explores a reusable icon picker modal for any block, Icon block enhancements like flip and rotate, and making the hardcoded icons in blocks such as Navigation, Breadcrumbs, and Details selectable through the Icon API. Alongside the API work, the core icon set itself is getting a visual refresh, with prominent icons redrawn as stroke-based designs for a more consistent, modern look.
ย Deprecating the Classic block As a first step towards making the Classic block and TinyMCE opt-in, the Classic block is planned for deprecation in 7.1, and will no longer appear in the block inserter. The related work improves migration and conversion paths and prepares the next step for making the Classic block and TinyMCE opt-in, so sites that donโt rely on the classic experience would get a lighter, faster editor.
Every new block added to Core means new possibilities for all, without needing to rely on third party blocks. 7.1 has a few new Core blocks slated for inclusion:
Playlist block, with additional waveform audio visualization.
Table of Contents block, automatically generating navigable links to the headings in your content.
New block support for the HTML block, making it possible to have editable blocks inside of a custom HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. block. This is especially useful with AI generated sites, since LLMs often create custom HTML.ย
An shortcode transform was added to the Embed block, so converting or pasting shortcodes now creates a proper Embed block instead of leaving raw shortcodeShortcodeA shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. text behind.
The Group block added support for background gradients through a new background.gradient block support, allowing gradients and background images to work together without conflicts.ย While limited to the Group block for now, block authors can adopt this new support using a simple register block type filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. before it comes to more Core blocks.
This is a great area to contribute to the release. If interested, please help with the Dialog block for transcripts and conversations and the Marquee block for scrolling, animated content as these both are on the list of blocks to add but donโt have a champion.ย
Writing flow and drag-and-drop improvements
To ensure writing and arranging content continues to get smoother, a dedicated focus is on chipping away at everyday pain points in the writing experience. This includes a wide range of focuses from improving drag and drop to ensuring multi-selection works on touch devices.
Notes have a range of planned improvements that include notes on specific content within a block and across multiple blocks, rich text in notes, notifications for replies and follows, emoji reactions, a minified notes experience, and an โapply suggestionsโ feature.ย All of these help provide a richer, more interactive experience of collaborating with others directly in the editor.
Imagine a world with no post lock screen and with collaborators of all kinds (human and AI) working together to share content with the world through WordPress. After a monumental effort ahead of the last release, real-time collaboration marches ahead with that vision in mind and with big, open strategy questions around:
These decisions, along with the readiness of the feature, are the key aspects to get right for all of WordPress and to align with project leadership on. They impact who gets access to the feature and what the experience will be like. To help aid the decision making and reliability of the feature, thereโs a new dedicated outreach effort for WordPress 7.1 to ensure collaborative editing gets the collaborative testing it needs. Please consider getting involved and learn more here.ย
When youโre styling a block, it isnโt always clear which styles are coming from the theme, a parent, or global styles. This work explores surfacing inherited styles clearly in the sidebar so you can understand where a blockโs styles are coming from and edit at the right layer of styling, whether thatโs a global or local change.
A standardized way to style interactive states is taking shape. Support for pseudo-state styling such as hover, focus, and active has landed for both Global Styles and individual block instances, building on the broader โstatesโ effort. Further work, including custom states like styling the current menu item, continues beyond 7.1. All of this work means you can begin to style how blocks respond to interaction, like buttons changing color on hover, all without writing a line of CSS.
With WordPress 7.0, the experience of using patterns shifted to be more like editing a single block with a focus on content changes than exposing every tool available for every block in a pattern. For this cycle, work will focus on UXUXUser experience improvements based on feedback around this change, bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes, and general maintenance.ย
Responsive styling for blocks has been a long requested feature and 7.1 aims to be a big step towards more support. Building on the same style states mechanism that powers the interactive states styling for blocks, this work lets you define how a block looks at different screen sizes. This means you can apply responsive styles, like a font size at a certain viewport, directly in the editor without writing custom CSS. The feature will be available both for global styles that apply across every instance of a block, and for individual block instances. The aim is to make responsive design a built-in, first-class part of the editing experience.
After adding the ability to hide or show blocks based on viewport, theme-configurable breakpoints defined in theme.jsonJSONJSON, 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. are being added to provide more flexible, customizable responsive styling.
After being punted from 7.0, client-side media processing keeps getting more capable and resilient ahead of this release. The work spans HEIC image support, Ultra HDR support, GIF-to-video conversion, more resilient uploads that retry on failure and resume after a crash or going offline, video transcoding to web-safe formats, optimization of previously uploaded media, and local poster generation during video upload so pages can render before a video finishes loading.
The Media editor modal replaces the existing inline cropping tool in the Block Editor. The modal keeps the familiar Crop button as the entry point, and brings freeform and aspect-ratio cropping, flip, fine-grained and snap rotation, and metadata editing into one dedicated workflow.
Galleries are becoming more dynamic and easier to build, with better handling of the legacy gallery shortcode on conversion, dynamic galleries that can sort or pull media attached to a post, and a quicker path in the inserterโs media tab to images attached to the current postย with thumbnails shown directly.ย
The core performance change planned for 7.1 is an update to speculative loading: when both object caching and page caching are detected, the default eagerness would move from conservative to moderate, prefetching and prerendering more readily on sites equipped to handle it so navigation feels faster.
Two further efforts are being iterated on within feature plugins you can install and benefit from today. Work in the View Transitions plugin centers around bringing smooth, animated transitions between pages on the front end. Work in the Enhanced Responsive Images plugin computes more accurate sizes values in block themes so browsers download appropriately sized images. Both are in active development, and interested contributors are welcome to help move them forward.
If you have something youโre working on that you donโt see reflected in this post, please share a comment below so we can all be aware! If youโre reading this and want to help, start with the above items and/or pingPingThe act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test itโs connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of โPing me when the meeting starts.โ me (@annezazu) in the 7.1 release leads channel. I have a list of projects that were punted from this release that Iโm happy to talk to people about taking on.ย
The live meeting will focus on the discussion for upcoming releases, and have an open floor section.
The various curated agenda sections below refer to additional items. If you haveย ticketticketCreated for both bug reports and feature development on the bug tracker.ย requests for help, please continue to post details in the comments section at the end of this agenda or bring them up during the dev chat.
The discussion section of the agenda is for discussing important topics affecting the upcoming release or larger initiatives that impact the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Team. To nominate a topic for discussion, please leave a comment on this agenda with a summary of the topic, any relevant links that will help people get context for the discussion, and what kind of feedback you are looking for from others participating in the discussion.
Open floor ย ๐๏ธ
Any topic can be raised for discussion in the comments, as well as requests for assistance on tickets. Tickets in the milestone for the next major or maintenance release will be prioritized.
Please include details of tickets / PRs and the links in the comments, and indicate whether you intend to be available during the meeting for discussion or will be async.
Weโve just merged a change that will be part of WordPress 7.1 that hides the Classic blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. from the block inserter by default. The Classic block stays registered, every existing Classic block keeps working and remains editable, and a new filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. lets anyone bring it back into the inserter. This post explains what changes, why, and how to opt back in if needed.
Whatโs changing
Starting in WordPress 7.1, the Classic block (core/freeform) no longer appears in the block inserter (#11712, Trac #65166, originally #77911 in GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses โblocksโ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/). In practice, this means you canโt add a new Classic block from the inserter, the block library, or slash commands.
Nothing else about the block changes:
The Classic block remains registered.
All existing Classic blocks (including any <!-- wp:freeform --> content) continue to render and stay fully editable, exactly as before.
The Classic editor and the underlying TinyMCE experience are untouched. If a post type doesnโt use the block editor, nothing here applies to it.
This is purely about steering new content away from the legacy Classic block, not about removing anything you already have.
To be clear: the Classic editor is not affected at all by this change. This is strictly about the Classic block inside the block editor. If you use the Classic editor (for example, via the Classic Editor pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. or on post types that donโt use the block editor), your experience stays exactly the same.
Why weโre doing this
The Classic block has been the bridge from the pre-block era into the block editor, and it has served that role well. But itโs also the one block in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. that doesnโt behave like a block:
Architectural consistency. Every other Core block is a node in the block tree. The Classic block is the lone exception, opaque HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. rendered through a separate editor embedded inside the block editor. Keeping it as a default inserter option works against the block-first model on which the editor is built.
Reducing the inflow. The migrationMigrationMoving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. path away from Classic content (Convert to Blocks) has existed for years, and Classic usage keeps shrinking. Hiding the block from the inserter stops new Classic content from being created, so that set keeps getting smaller rather than growing.
Maintenance leverage. Many block-library improvements have to special-case the Classic block. Each special handling may be small on its own, but cumulatively, this may slow down work that benefits every other block.
The broader, longer-term goal, which will be covered separately as it matures, is to make the Classic block fully opt-in and eventually to lay the groundwork for loading TinyMCE only when itโs actually needed. WordPress 7.1 is just the first user-facing step on that path. None of the later steps are happening in 7.1, and each will get its own discussion and dev notedev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase..
Opting back in
If you (or your users) still want the Classic block available in the inserter, thereโs a dedicated filter: wp_classic_block_supports_inserter.
If youโd rather not write code, thereโs a small plugin that does exactly this, Enable Classic Block, which flips the filter on for you. The plugin has already been submitted for approval to the WordPress Plugin Directory.
Backward compatibility
This change is opt-out by design and doesnโt break anything:
No content is modified or migrated. Existing Classic blocks are left exactly as they are.
The block, its edit behavior, and the Convert to Blocks action all continue to work.
The core/freeform block remains registered, so any code that relies on it being present keeps functioning.
Restoring the previous behavior is a one-line filter (or one tiny plugin) away.
Whatโs next
Alongside this change, weโre investing in the surrounding experience so that moving away from the Classic block is smoother for everyone:
A deprecation/migration notice (experimental). Thereโs an experiment in Gutenberg that surfaces a notice inside existing Classic blocks, with one-click actions to convert the content to blocks or to a Custom HTML block. Weโre exploring this as a gentle way to highlight that the Classic block is being phased out and to make the migration path more discoverable. Itโs behind an experiment flag for now while we refine it for a WordPress release.
Improving everything around it. In parallel, weโre improving and fixing the pieces that live by the Classic block: the Custom HTML block, the Convert to Blocks path, freeform handling and conversion, and related compatibility layers. The goal is that by the time Classic content needs to move, the tools to move it are solid.
These, alongside other planned next steps, can be tracked in the dedicated tracking issue.
Weโd love your feedback
This is an early step in a longer effort, and we want to get it right. If you maintain plugins or custom integrations, run large sites, or have workflows that depend on the Classic block, weโd really like to hear from you, especially around migration and bulk-conversion needs.
A huge congratulations, and a giant thank you to everyone who helped make WordPress 7.0 happen! The release was only made possible by your dedication and hard work. You all are heroes!
Now that the development cycle is over, itโs time for a retro. Youโre invited to share your thoughts on the 7.0 cycle, on processes, squad, or anything else about the release cycle. I know you all have :a lot: to say after that whirlwind, so please do! Feedback loops help uncover what is and is not working so that the release process can be improved.ย
Please share your feedback using this form or by dropping a comment below. Even contributors who did not contribute directly to the release are welcome.
Someone who was simply watching the release will have thoughts and opinions that vary from someone who was more heavily involved. Itโs important for diverse perspectives to be represented in feedback for big picture clarity. So no matter who you are, please speak up!
The survey is not anonymous, but submissions will be anonymized in the follow up summary. Your wordpress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ username is only needed for any additional questions.
The form and comments will be open until July 20, 2026, and a summary of feedback will be published soon after.
Thank you for taking the time to give your valuable feedback, and thank you again for your amazing investments in 7.0 โArmstrongโ. Together, future release cycles will be even better!
We propose merging Knowledge, a new wp_knowledgecustom post typeCustom Post TypeWordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept., into WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. for the 7.1 release, with Guidelines as the first feature built on it.
Knowledge is a general primitive for storing author-facing and agent-facing site knowledge as standard WordPress content: a post type with a type taxonomyTaxonomyA taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies., the existing roles and capabilitiescapabilityAย capabilityย is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on theirย role. For example, users who have the Author role usually have permission to edit their own posts (the โedit_postsโ capability), but not permission to edit other usersโ posts (the โedit_others_postsโ capability)., native revisionsRevisionsThe WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision., and REST access. Guidelines uses it to give site owners a first-class place to capture the standards that shape how content is written and edited, such as voice, tone, image preferences, and per-blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. rules.
The implementation is operational in the GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses โblocksโ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. and has been exercised by production integrations. It builds on the Guidelines experiment, proposed in February and landed in Gutenberg 22.7 in March, then shaped through community feedback into a consolidated design and stabilized for core.
Purpose & goals
Most sites already have content standards, but they live outside WordPress in documents, wikis, and institutional knowledge. Guidelines gives them a canonical home inside WordPress, available where they matter: during writing and editing.
A single store of standards serves everyone who works on a site: writers and editors applying them by hand, plugins reading them, and AI assistants drawing on them too. Each of these needs the same thing, persistent and structured knowledge about the site, and today there is no shared place to keep it. Without a common primitive, every plugin ships its own storage, its own permissions model, and its own REST surface. That is exactly the kind of fragmentation WordPress core has historically prevented, the same way wp_template, wp_block, and nav_menu_item prevented parallel solutions in their domains. Core owns the primitive. The community decides what to build on it.
The name follows that intent. โGuidelineโ describes prescriptive records well but fits memories and working notes much less naturally, while โKnowledgeโ covers both procedural content (how work should be done) and declarative content (what is known). Knowledge names the namespace. Individual records are referred to by their concrete type, a guideline, a memory, a note. The user-facing feature in WP Adminadmin(and super admin) remains Guidelines, the same way the attachment post type surfaces as Media at /wp/v2/media.
The goals, concretely:
Provide a canonical storage primitive for author-facing and agent-facing site knowledge
Ship Guidelines as the first feature built on it, demonstrating the primitive in core
Replace fragmented plugin-specific storage, capabilitycapabilityAย capabilityย is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on theirย role. For example, users who have the Author role usually have permission to edit their own posts (the โedit_postsโ capability), but not permission to edit other usersโ posts (the โedit_others_postsโ capability)., and REST models with one shared foundation
Non-goals
This merge ships storage and access, not intelligence: no AI provider, no model, no retrieval algorithm, and no autonomous memory system. The specifics below are intentionally out of scope. They remain open topics, just not blockers:
No decay, consolidation, or retrieval mechanism in core. Consuming tools accommodate staleness above the primitive.
Further built-in types are deferred and can be registered by plugins in the meantime:
skill โ a procedure that can load and apply a guideline, is planned for 7.2 pending settled loading and discovery semantics (ai#430)
plan โ task-scoped working state for a multi-step task, pending a side-effect and lifecycle model
artifact โ a reference to a versioned work product distinct from the freeform text covered by note, explored separately
Load applicability of scopes (when a scopeโs guidance applies beyond the universal site scope) is left for its own discussion.
Session state and cross-site user preferences live above the primitive.
Encryption at rest is orthogonal hardening that can land later without changing the data model.
What we propose to merge in 7.1
The wp_knowledge custom post type with native revision support
The wp_knowledge_type taxonomy and the wp_knowledge_types registration filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.
The built-in types guideline, memory, and note (defined below)
The *_knowledge_item capability namespace and the access model described below
The generic /wp/v2/knowledge REST routes for working with knowledge records like other post types
The Guidelines Settings page: per-scope guideline records, a filterable scope registry as the source of truth for the UIUIUser interface, and a read-only registry route at /wp/v2/knowledge/guideline-scopes
The knowledge management ability, registered through the Abilities APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., is expected to follow in a later release.
Built-in types
Each type is defined by what the record represents and how it is applied:
guideline โ a standard, pure text that is the source of truth, such as voice, tone, image guidance, or per-block rules. A guideline does nothing on its own. It is there to be applied, either directly by an ability that pulls the text in or through a skill that loads it. The site-wide standards managed on the Settings page carry this type.
memory โ durable context explicitly saved or approved for future use, such as user preferences, stable facts, and profile context. Records are private and author-owned. The explicit save-or-approve rule is deliberate: core ships a storage primitive, not a memory architecture. Decay, consolidation, and retrieval remain things to build on top.
note โ private freeform working text, such as sticky notes, drafts, and notes synced from external tools. A record saved without a type falls back to note.
Plugins register their own types through the same filter. A plugin might add a glossary type to keep domain terminology consistent across writers, editors, and any agent that reads it:
Core relies only on the semantics of the built-in slugs it ships. Plugin types are free to define their own behavior.
Guideline scopes
Guideline scopes define the sections shown in Settings โ Guidelines and the reserved slugs used to address the corresponding guideline records. Core ships scopes such as Site, Copy, Images, and Blocks, each one a guideline record at a reserved slug like guideline-copy. Plugins register additional scopes through a filter, and the Settings page reads the registry through a read-only REST route at /wp/v2/knowledge/guideline-scopes.
Scopes are not knowledge types. The wp_knowledge_type taxonomy answers what kind of record this is (guideline, memory, note). The scope registry answers where a guideline applies in the Guidelines UI. A scope is addressed by its reserved slug, not a taxonomy term, since a term per scope would attach to exactly one record and duplicate identity into a second system.
Privacy, security, and access model
Knowledge records are not exposed as a public index. The post type is registered as an internal storage primitive, not a front-end content type: it is not publicly queryable, and management flows through the Guidelines UI, REST, and registered programmatic surfaces rather than a native public post-type UI. Collection reads require authentication, per-item reads are capability-checked through read_post, and non-publishers can only create private records. New records default to private on creation.
Actor
Site-wide guideline records
Own private records
Othersโ private records
Publish / manage global records
Subscriber
No
No
No
No
Contributor
Read where capabilities allow
Create, read, edit, delete
No
No
Author / Editor
Read where capabilities allow
Create, read, edit, delete
No
No
Administrator
Manage
Yes
Yes
Yes
This matrix reflects the access policy from gutenberg#78296 and will be aligned exactly with the final core patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing.. The built-in type set is defined in code through a filter, while the underlying taxonomy terms are created lazily when a record is first saved with a given type, so authoring a record can create its term. Revisions are retained, and autosave is disabled, since knowledge records have no editor session.
Testing
Enable the Guidelines experiment in Gutenberg and verify:
Settings โ Guidelines renders its sections from the scope registry, and each scope can be edited, revised, and restored through the REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think โphone appโ or โwebsiteโ) can communicate with the data store (think โdatabaseโ or โfile systemโ)
https://developer.wordpress.org/rest-api/
The scope registry route returns core scopes and plugin-registered scopes
A Contributor can create and read only their own private records, and a Subscriber cannot access the post type through REST
REST collection reads require authentication, and non-publishers cannot create published records
No knowledge records are exposed through front-end public queries
Automated coverage for the controller, capability mapping, and type registry ships with the implementation and will be part of the core patch.
FAQ
Is this an AI-only feature? No. The storage primitive is already used for plain note-taking and draft syncing with no AI involved, and the Guidelines experience serves any multi-author site that wants consistent standards. AI tools are one consumer among several.
Does WordPress now have a โmemory systemโ? No. Core ships storage with a clear access policy. A memory record is a durable context a user explicitly saved, comparable to a private post. Anything resembling a memory architecture, including relevance ranking, decay, or consolidation, is left to plugins and integration layers by design.
What about existing plugins that store AI context their own way? Nothing breaks. Plugins can keep their own storage or adopt the shared primitive to gain interoperability, revisions, and the capability model for free.
The naming and scope model are settled, so this proposal moves forward on that basis unless a blockerblockerA bug which is so severe that it blocks a release. surfaces. The open question is narrower: is the API ready to stabilize for core? The names freeze at WordPress 7.1 BetaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 on July 15, when the post type, taxonomy, REST routes, capabilities, and type slugs become long-term compatibility commitments. Feedback that would block stabilizing for core is most useful in the next three weeks, while there is still room to act on it.
Call for feedback
The questions below are where input matters most before these decisions become core commitments:
Is wp_knowledge the right long-term name for the primitive, and are guideline, memory, and note the right built-in type slugs?
Are the capability boundaries in the access model correct?
Is anything missing that should be settled before these names become core compatibility commitments?
Since WordPress 7.0 was released, contributors have kept aย close eyeย on incoming reports to theย WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ย Support Forums,ย TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., and theย GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses โblocksโ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/ย repository onย GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the โpull requestโ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/. The volume and severityseverityThe seriousness of the ticket in the eyes of the reporter. Generally, severity is a judgment of how bad a bug is, while priority is its relationship to other bugs. of tickets mean that the maintenance release should be prepared phlegmatically.
Specific times for RCrelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). and General release will be announced in the 7.0 Release Leads room and will be based on availability of individuals helping with the release.
Targeted Fixes
WordPress 7.0.1 is intended as aย bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.-fix only maintenance release. Tickets will be included provided they are issues introduced during the 7.0 cycle or intentionally deferred at the end of the 7.0 cycle. You can follow trac report 4 or the 7.0.x editor tasks board for proposed fixes.
Bug Scrubs will happen in theย #core roomย duringย the times posted above. Each of the open tickets is going to require development work along with testing and review. You can alsoย run your own scrubsย to help ensure that all of the correct tickets are fixed in this release. Additionally,ย some locales have strings in 7.0 in need of translation.
General coordination for the release will happen in theย #7-0-release-leads channelย and decisions around code for the release will be made in theย #coreย room.
Since the blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor was first merged into wordpress/wordpress-develop (leading up to the WordPress 5.0 release), there has always been a considerable amount of manual work required to sync the necessary changes in the gutenbergGitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the โpull requestโ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ repository into SVNSVNSubversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase.. During the early phases of the 7.0 release cycle, #64393 worked on making changes to the wordpress-develop build scripts with the goal of simplifying this process.
While the initial iteration of these changes committed in [61438] removed some of that manual friction, specific parts of the change disrupted a few important contributor workflows due to the way that PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher files were removed from version controlversion controlA version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories. and added to the .gitignore file. These particular PHP files were shared in both repositories, and the idea of removing them was to ensure that the source of truth remains clearly in the GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses โblocksโ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/ repository. Instead of existing in both repositories, a script would create the files in the working copy of the wordpress/wordpress-develop repo.
What went wrong?
Unfortunately, there were a number of unanticipated side-effects of this change:
A number of existing integrations started failing where the build script was not run due to the fact that WordPress calls require directly on these files to load them. This included the distributed hosting tests.
Several files that were previously minified by the build script no longer were (see #65007, #64909)
While the source of truth of these files lives in Gutenberg, itโs valuable to know when the updates were brought into CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. and what those updates were. Development in the Gutenberg pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. runs at a different pace than in Core, which means that diagnosing changes to these files from the Gutenberg side is considerably more difficult and time-consuming than when there are changes in version control, which provide pins for when defects are introduced or resolved.
Technically, there was a dual source of truth for these files before the change. The ultimate copies which made it into a WordPress release were those which had been committed into SVN, while the Gutenberg plugin might ship changed or updated files. After the change, that โultimateโ copy no longer existed in SVN, except in the final release bundles. The โsource of truthโ for the files in both contexts (WordPress and the Gutenberg plugin) lived solely in Gutenberg, but might actually be different from each other due to the new commit hash pinning in wordpress-develop.
Because these files were removed and the change added this new requirement to run the build step, major delays were introduced to any workflow which steps through commits. Even after a series of optimizations, this added over nine hours of runtime just to walk the 800+ commits from 6.8.5 to 6.9.0.
Version history for these files was severed in the change, making it suddenly look like the files were never part of the repository. Any attempts to review the history required custom git commands not usually available in IDEs or GitHubโs UIUIUser interface.
Files that were removed from version control were abandoned on the build server, which did not clean up properly. This resulted in removed files persisting and being included unintentionally in the betaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. and RCrelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). versions (see #64716 and #65418).
While it happens from time to time that someone accidentally updates the code in one of these files in the Core repository instead of in Gutenberg where it should be done, the .gitignore directives hide any of those accidental changes, frustrating an already confusing situation. All git-based tooling (IDEs, git, git GUIs, linters, etcโฆ) is unable to see or revert changes to these files, giving a false sense of safety when someone checks in code that will unexpectedly fail once running on a different computer.
What was resolved?
Two fundamental problems needed to be resolved:
Files that are required by WordPressโ boot sequence needed to be restored.
The version history continuity for these files would ideally need to restored.
On one hand, reverting the original change would have been an easy way to restore the missing files. But doing so would make it appear as though the revert commit was introducing brand new files with the same name as the ones which had been deleted, rather than restoring the deleted files. The history before January 5 would have remained lost. A revert or a new commit which copies the files back remained an easy option, but something else was worth pursuing: restore the files with their history.
The chosen resolution was to create a branchbranchA directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". of the code from the revision just before [61438], restore all of the files which were removed, and then perform a merge of the branch back into trunk to reconnect the version history. Until this point, creating branches was normal in the WordPress codebase for each release, but none had been reintegrated into trunk through a merge.
The merge commit provided an opportunity to restore the file contents and connect them to their history. While the original plan was to create a branch with a single commit (the merge commit itself) @desrosj had the suggestion that it would be valuable if the intervening history of changes could also be represented. In other words, to create the restore branch as an effective revert of the decision to remove all these files, not just the file objects themselves.
The result is that the restore branch contains a sequence of commits, where each is associated with a Gutenberg-sync commit in the upstream trunk branch. These commits modify the deleted files and introduce new files that would have been added had it not been for the .gitignore and svn:ignore changes. This is tantamount to checking out trunk at each Gutenberg sync commit, reverting the .gitignore changes, running npm run build:dev, and then adding the no-longer-ignored files (but the details are more complicated than this).
After the final merge, itโs now possible to examine one of the affected files and immediately know at which Gutenberg sync commit it changed and how. Supposing someone discovered that an issue appeared within the first quarter of 2026, this additional granularity might save the need to scan through hundreds of commits when debugging.
What was the process for the resolution?
The original change itself serves as a cautionary guide on how far-reaching the effects can be for fundamental changes to WordPressโ development infrastructure. Because no restoration-merge had ever occurred, it was worth performing full diligence to prevent similar blowback while trying to fix the repository.
The approach was discussed early on and remained open for a long time to allow for rarer implications to surface โ many did. The topic was brought up in Trac, in the #core channel in SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/, and during weekly Developer Chats in #core. The solution was brought to the attention of the systems team for their input, and as much as was possible, the restore was simulated at every stage to catch any failures which could be reasonably anticipated โ many were.
git is a more powerful companion in situations like this than svn is, but ultimately all of WordPressโ code must begin its life in svn. Therefore, a script was created to prototype a resolution in git to produce the desired outcome in a way that could be tested in local checkouts as well as run the test suite. The goalpost for this test branch was that, if done correctly, in the merge with trunk inside of its PR, there would be no follow-up commits from the bot that runs the build command (because no files would be changed through the build). The simulation script made it easy to adjust strategies and add missing steps once certain problems surfaced. One such problem was that some files didnโt make it at the right time into one of the grunt lists when it should have; this could have involved a lot of manual work, but it didnโt because of the script. The script still involved a lot of effort, but as many times as it ran, rebuilding the branch within a few minutes, it was clear that it was paying off.
Once the git branch was ready it was time to ensure that the steps in svn would actually produce that desired outcome once synchronized. For this, @abbe provided a test copy of the develop.wordpress.org Subversion repo that could be used to verify the flow. A second script stepped through each commit from the git branch and created mirrored commits on the svn side, then performed a merge into the test repoโs trunk branch. The goalpost for this side was that the end result matched identically to the final exploratory git branch. In the end, it took fifteen full iterations of the simulated branch creation to get the expected result. Imagine finding out all of the little nuances only afterdeployingDeployLaunching code from a local development environment to the production web server, so that it's available to visitors. to production!
With all of the details then ready, it was go-time and time to deployDeployLaunching code from a local development environment to the production web server, so that it's available to visitors. for real. Sadly, not all aspects of the flow were testable beforehand, and problems did arise which stalled the restoration. The โbuildโ server2 got stuck while processing commits due to a fatal Grunt error and @aidvu had to step in and manually clear up the issues on that server. However, while delayed, all it took to reach the successful end was running the script once more. Thankfully, after preparing each commit and before pushing them, a pause step was built-in for manual review before committing to the commit, and this allowed coordination with systems (itโs ideal to build natural throttles in to automation to avoid billions of errors per second).
What is important to understand about this merge?
When working with merged branches, git automatically represents commits from all of the branches in history, but svn doesnโt. This means that git-based workflows should be working without any trouble. But for those working in svn, a basic svn log will not show the corresponding sync-commits from the branch. One has to run svn -g log to see them. Any svn-based tooling will therefore hide the commits by default.
There is one solvable nuance that was cut from scope for this resolution: commit authors and timestamps. While it was demonstrated to be technically possible to match the sync commits with their associated commits in the upstream trunk branch, this would have required rewriting metadata in svnafter making the commits, and there was no certainty that this wouldnโt interrupt the git-svn sync. Therefore, while each sync-commit matches another commit from January 5 through March 26, each of the restore-branch sync-commits appears in a bunch on March 26. This is a minor issue; regrettable but acceptable given the sensitivity of the work done to bring the repository back into a proper state.
What still remains to be done?
A few issues arose during the restoration, some of which highlighted pre-existing problems.
The git and subversion โignoresโ lists are incompatible and out of sync. These need to be harmonized and it would be ideal to have an automated process flag discrepancies before they are committed (#64971).
A number of files have been deleted from the git repository over time which were never removed from the subversion side. This leaves stale files in svn and on the build server. These need to be identified, removed, and added to the $_old_files array in wp-admin/includes/update-core.php (see #65418). Automated detection would be helpful here as well (see #64878).
The continued discrepancy between WordPress Coding StandardsWordPress Coding StandardsThe Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook.
May also refer to The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the PHP coding standards. preferences between the Gutenberg and Core repositories remains an obstacle to harmony between the projects. Rulesets should be normalized or removed from the repositories so that accepted changes donโt suddenly reject PRs when synchronizing. This issue also recently came up when restoring the WordPress documentation, as PHP code which was accepted in Gutenberg broke the docsโ generation process once built in Core. This was due to the use of syntax forms which were already known to break tooling and integrations.
Functions and hooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. maintained upstream in the gutenberg repository that are built from the new template files in the wp-build package lack proper PHP Docblockdocblock(phpdoc, xref, inline docs) comments. Mainly, action and filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. hooks had incorrectly formatted Docblocks (fixed in Gutenberg-78826), and missing @since tags (see Gutenberg-76727).
A few other unrelated issues persist as a result of the build change.
The workflow for developing simultaneously with the Core and Gutenberg repositories needs to be restored, as the traditional approach of mounting the Gutenberg plugin into the wp-content/plugins/ directory was severed in the change.
Thanks you!
A heartfelt โthank youโ goes out to everyone who helped with overhauling the build script to reduce friction between the two code bases, and/or this effort to restore file history:
January 6 โ The first set of problems was reported.
February 23 โ An initial git branch was proposed which restored the files in their final state.
March 6 โ The restore branch was created in Subversion, and successfully synchronized to git.
March 18 โ An expanded git branch contained a commit for every associated Gutenberg sync commit in Core.
March 24 โ Systems provided a test svn repository from a backup of develop.svn.wordpress.org where a final merge could be tested before being applied to the production repository.
March 26 โ The branch was merged into Core, restoring the files and their change history.
Props to @amykamala and @desrosj who reviewed this post before publishing.
The wordpress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ build server checks out each commit to the wordpress-develop SVN repository, runs npm install, npm run build, and then commits any changes to the build directory to the core.svn.wordpress.org repository. All release packages are created from this repository. โฉ๏ธ
As with the 6.7, 6.8, 6.9, and 7.0 release cycles, WordPress 7.1 will continue the approach of forming a smaller, focused Release Squad.ย This streamlined structure places more emphasis on collaboration with the various Make Team Reps, who are encouraged to help coordinate efforts from within their respective teams.ย The goals are to reduce the overhead on the Release Squad while still ensuring each Make Teamโs contributions and priorities are represented throughout the cycle, and to reduce overlap between a Make Team RepTeam RepA Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. and that teamโs Release Squad Leads.ย Noteworthy Contributors will be captured from Team Reps towards the end of the release cycle.
The number of volunteers far exceeded the available squad roles, so we selected folks whose experience and focus best aligned with the needs of the 7.1 release.ย If you werenโt selected this time, your contributions are still incredibly valuable, and there are plenty of ways to stay involved throughout the release cycle, including testing, bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs, triage, documentation, and more.ย Every contribution helps move WordPress forward, and weโre grateful for your continued participation.
Big thanks to everyone who volunteered for the release squad, and heartfelt appreciation to everyone helping move WordPress 7.1 forward through testing, triage, documentation, bug scrubs, and more.ย Your efforts make this release possible, and thereโs a lot to be excited about as WordPress 7.1 comes together!
โWhatโs new in GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses โblocksโ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/โฆโ posts (labeled with the #gutenberg-new tag) are posted following every Gutenberg release on a biweekly basis, showcasing new features included in each release. As a reminder, hereโs an overview of different ways to keep up with Gutenberg and the Editor.
Gutenberg 23.4 brings resilient media uploads, continued media editor refinements, visual updates for the Site Editor and experimental dashboard, new Grid transforms, and developer-facing improvements for DataViews and design-system foundations and a whole lot more. Thanks to everyone who contributed to the release.
Preparing WordPress for ReactReactReact is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces.
https://reactjs.org 19
23.4 introduces a new experimental flag that can register version 19 of React runtime scripts: react, react-dom, and react-jsx-runtime. This gives developers a way to test plugins, themes, blocks, and editor integrations against the React 19 runtime before it becomes the default (#79077, #78685, #79142). To test, head to the experiments page /wp-admin/admin.php?page=experiments-wp-admin and activate the โReact 19โ experiment.
Tips for testing: Although React 18 and 19 APIs are practically identical, there are some runtime incompatibilities that had to be resolved with an additional compatibility layer. When testing a pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. or theme with the React 19 experiment, developers should pay close attention to any warnings and console errors. Test all custom adminadmin(and super admin) pages that your plugin registers and that use React. Test everything in the editor UIUIUser interface that uses refs, ref callbacks, portals, or third-party component libraries. Review your build pipeline to check that usages of react/jsx-runtime link to the externalized WordPress script instead of bundling it.
The Site Editor follows your admin color scheme
The Site Editor sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. and page shell now follow the userโs WordPress admin color scheme instead of always using a fixed dark background. This brings the Site Editor chrome closer to the rest of the admin experience across color schemes (#78397).
Media
The media editor modal received a round of usability and design improvements. Editable attachment fields appear at the top of the details panel (#78896, #78792). The mobile toolbar has been updated to include aspect ratio control, zoom uses plus and minus buttons (#78935, #78928, #79011, #79024).
Client-side media processing introduced an upload progress snackbar to the BlockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor, including batch upload counts (#77249). The upload queue will pause while offline, resuming automatically when the connection returns (#76765).
Columns and Gallery blocks can transform into grid layouts
Block transforms can now target a specific variation of another block. In practice, this enables new transforms from Columns and Gallery blocks into a Grid variation, preserving content while changing the layout type (#78713).
Other notable highlights
UltraHDR image support โ UltraHDR JPEGs are detected during upload, originals are kept unmodified, and resized sub-sizes preserve the ISO 21496-1 gain map (#74873).
New Dashboard experience experiment โ A new Events widgetWidgetA WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. for upcoming WordPress community events was added (#78553), as well as a responsive grid columns with container breakpoints (#78732).
DataViews configuration becomes filterable โA new filterable APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. extracts entity view configuration out of the REST controller and into a reusable function (#78977).
Playlist block โ Adds a visualization style selector for waveform styles, plus a track length setting (#76147, #78954).
Login/out block โ This block can now be inserted inside the Navigation Submenu block (#75497).
Block transforms โ For transforms, you can target a variation of another block (#78713).
Real time collaboration (RTC) reliability work โ RTC shipped improvements including a separate document persistence endpoint, collaborator overlay rerenders, polling improvements, forbidden room handling, CRDT typing fixes, and undo manager fixes (#78891, #78636, #78811, #78748, #78756, #78864).
Revert client-side media processing plugin-only gate. (76751)
Enhancements
Tooltip migrationMigrationMoving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies.: Boot consumers + shell-level Tooltip.Provider (5/5). (78692)
Upload Media: Add retry with exponential backoff and networknetwork(versus site, blog) resilience. (76765)
Use search_columns=post_title for parent page selector REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think โphone appโ or โwebsiteโ) can communicate with the data store (think โdatabaseโ or โfile systemโ)
https://developer.wordpress.org/rest-api/ searches. (78683)
Data Layer
RTC: Add separate doc persistence endpoint. (78891)
RTC: Re-render collaborators overlay when the block tree changes. (78636)
Maintain absolute stroke-width regardless of icon-size. (78774)
Font Library
Fix Update button staying active when changes are reverted. (78567)
Client Side Media
Extract entity view configuration into a filterable API. (78977)
New APIs
Extensibility
Extract entity view configuration into a filterable API. (78977)
Bug Fixes
Build: Document the hooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. generated by the wp-build page templates. (78826)
Scripts: Use require.resolve for SVG webpack loaders to fix pnpm compatibility. (78777)
[Content Types]: Fix extra Page padding causing vertical scrollbar. (78661)
env: Replace extract-zip with adm-zip to fix hang on Node 24.16. (78828)
wp-build: Fix black flash on wp-admin pages before hydration. (78493)
Block Library
Common CSS: Avoid false-positive border-style on custom properties. (77476)
Fix playlist metadata edits recreating player. (78876)
Fix type ofย $block_instanceย parameter inย block_core_image_render_lightbox(). (78790)
Paragraph: Strip stale block-support classes from className during align attribute migration. (78731)
Prevent font-size propagation in Navigation items causingย emย compounding. (77419)
ShortcodeShortcodeA shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. block: Fix editor crash when selecting transform menu. (78770)
Writing flow: Delete at end of nested list item should merge into next block. (78742)
Image block: Donโt show crop icon while image is uploading. (79103)
Media
Media Editor: Fix media editor sidebar close button label. (78895)
Media Editor: Fix sidebar overflowing the modal between the small and medium breakpoints. (78931)
Media Editor: Keep crop handles operable on large images. (79011)
Media Editor: Remove lag when toggling the sidebar. (79024)
Elements: Align class name parsing with custom CSS implementation. (79023)
Elements: Guard against non-string className in render filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.. (78841)
Preserve nested list when deleting a selection across sibling list items. (78776)
Client Side Media
Media: Skip cross-origin isolation on the classic-theme site editor home route. (78404)
Upload Media: Gate very large images out of client-side processing. (78949)
Plugin
Fix Gutenberg plugin assuming its directory is named โgutenbergโ. (78705)
Fix experiments page form layout with box-sizing and width. (78910)
Data Layer
RTC: Fix CRDT deferred updates resulting in jumbled typing. (78756)
RTC: Fix Yjs undo manager to update UI state when undo stack changes. (78864)
Post Editor
Editor: Fix keyboard activation of the template actions preview. (78641)
Notes: Show default avatarAvatarAn avatar is an image or illustration that specifically refers to a character that represents an online user. Itโs usually a square box that appears next to the userโs name. in the indicator when user avatars are disabled. (78849)
Connectors screen
Fix: Block auto-complete for AI API Keys in Connectors. (78946)
Icons
Revert โIcons: Maintain absolute stroke-width regardless of icon-size (#78774)โ. (78854)
Dashboard
Fix Add widget error on non-secure HTTPHTTPHTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. origins. (78850)
Block API
Block Visibility: Keep hide-everywhere working after a block opts out of visibility support. (78780)
AccessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both โdirect accessโ (i.e. unassisted) and โindirect accessโ meaning compatibility with a personโs assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)
Boot navigation: Wrap items in a list role for valid listitem semantics. (78829)
Block Editor
Inserter: Fix error being thrown for spoken message when inserting default/direct block. (79004)
Block Library
Navigation Link: Fix duplicate block htmlHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. attributes in editor. (78973)
Patterns
Fix focus loss when closing the Create pattern dialog from the block toolbar. (78957)
DataViews: Add DataViews components to components manifest. (78960)
Docs: Auto-generate per-block API reference pages from block.jsonJSONJSON, 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.. (77612)
Docs: Fix stale, incorrect, or missing documentation. (78686)
Docs: Remove stale mobile references from tooling and primitives documentation. (79041)
Format Library: Migrate to recommendedย @wordpress/uiย components. (79059)
Framework: Remove invalidinvalidA resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. stale nested npm package references. (79014)
Makeย @wordpress/nuxย a no-op compatibility package. (77773)
Remove migrated dependencies from root package.json. (78813)
Tools: Migrate docs/tool into tools/docs workspace. (78870)
Block Library
Fix sprintf format specifiers in post-date and read-more blocks. (78933)
Fix: Escape URLs in block render functions usingย esc_url(). (78912)
Refactor workspace configuration for Babel dependencies. (78974)
Revert navigation morph & playlist commits pushed directly to trunktrunkA directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision.. (78857)
RichText: Remove dead native-only prop filtering. (79037)
Data Layer
Compose: Fully deprecate the โpureโ HoC. (78674)
Media: Move client-side media compat file to wordpress-7.1 directory. (78852)
Refactor: Remove jest/test deps from root package.json. (78801)
Remove React Native implementation, framework, and dependencies. (78747)
Post Editor
Editor: Refactor โPostPublishButtonโ into function component. (78737)
Editor: Remove dead native guard in block removal warnings. (79039)
Post RevisionsRevisionsThe WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision.: Upgradeย diffย from v4 to v8. (77992)
TypeScript: Migrate server-side-render package to TS. (71383)
Remove orphaned mobile bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. report issue template. (79038)
Update AGENTS.md to mention additional pitfalls. (78718)
Update CODEOWNERS for tooling directories. (78874)
Build Tooling
Build Scripts: Fix Windows path handling in dev script. (78939)
CI: Skip plugin repo release when SVNSVNSubversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase.tagtagA directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) already exists. (78476)
Lint dependency version consistency with Syncpack. (77950)
Release: Drop mobile-specific changelog omit rules. (79042)
Skip including inactive or experimental routes when building for WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. (76715)
feat: Migrate performance results to tools release. (78761)
The live meeting will focus on the discussion for upcoming releases, and have an open floor section.
The various curated agenda sections below refer to additional items. If you haveย ticketticketCreated for both bug reports and feature development on the bug tracker.ย requests for help, please continue to post details in the comments section at the end of this agenda or bring them up during the dev chat.
The discussion section of the agenda is for discussing important topics affecting the upcoming release or larger initiatives that impact the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Team. To nominate a topic for discussion, please leave a comment on this agenda with a summary of the topic, any relevant links that will help people get context for the discussion, and what kind of feedback you are looking for from others participating in the discussion.
Open floor ย ๐๏ธ
Any topic can be raised for discussion in the comments, as well as requests for assistance on tickets. Tickets in the milestone for the next major or maintenance release will be prioritized.
Please include details of tickets / PRs and the links in the comments, and indicate whether you intend to be available during the meeting for discussion or will be async.
You must be logged in to post a comment.