Dennis Snell 6:53 pm on June 17, 2026
Tags: build-test-tools ( 4 ), git ( 7 ), post-mortem ( 3 ), svn ( 8 )

Recap: Restoring removed version history.

Since the blockBlock Block 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 gutenberg GitHubGitHub GitHub 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 SVNSVN Subversion, 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 PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher files were removed from version controlversion control A 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 GutenbergGutenberg The 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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and what those updates were. Development in the Gutenberg pluginPlugin A 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 UIUI User 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 betaBeta A 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 candidate One 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 branchbranch A 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 SlackSlack Slack 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 after deployingDeploy Launching 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 deployDeploy Launching 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” server² 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 svn after 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 Standards The 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 hooksHooks In 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 filterFilter Filters 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:

@4thhubbard, @762e5e74, @adamsilverstein, @aidvu, @amykamala, @bernhard-reiter, @dd32, @desrosj, @dmsnell, @ellatrix, @gaisma22, @isabel_brison, @johnbillion, @jonsurrell, @jorbin, @jorgefilipecosta, @jsnajdr, @jtquip88, @mamaduka, @manhar, @manzoorwanijk, @mcsf, @mywp459, @ntsekouras, @peterwilsoncc, @sabernhardt, @SirLouen, @swissspidy, @tobiasbg, @tyxla, @westonruter, @wildworks, and @youknowriad.

Timeline

January 5 — The change was committed.
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.org The 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. ↩︎

#build-test-tools, #git, #post-mortem, #svn

Jeffrey Paul 3:03 pm on June 17, 2026
Tags: 7.1 ( 20 ), planning ( 36 )

Announcing the WordPress 7.1 Release Squad

This post is announcing the formation of the 7.1 release squad after a call for volunteers.

Exciting News: The WordPress 7.1 Release Squad is assembled!

Release LeadRelease Lead The community member ultimately responsible for the Release.: Anne McCarthy
Release Coordination: Benjamin Zekavica, Krupa Nanda
Tech Leads: Aki Hamano, Joe Dolson
Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Leads: Adrian Duffell, Sajjad Hossain Sagor, Sergey Biryukov
Test Leads: Huzaifa Al Mesbah, Nikunj Hatkar

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 Rep A 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, bugbug A 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!

Props to @tyxla, @annezazu, @jorbin for reviewing this post and @jorbin, @desrosj, @annezazu, @tyxla, and @4thhubbard for helping assemble the 7.1 release squad.

#7-1, #planning

ramonopoly 10:15 am on June 17, 2026
Tags: block-editor ( 137 ), core-editor ( 754 ), gutenberg ( 544 ), gutenberg-new ( 213 )

What’s new in Gutenberg 23.4? (June 17, 2026)

“What’s new in GutenbergGutenberg The 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.

What’s new in
Gutenberg 23.4?

Gutenberg 23.4 has been released and is available for download!

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.

Table of contents

Preparing WordPress for ReactReact React 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.

Registers React 19 as the bundled React version, replacing the default React 18 scripts.

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 pluginPlugin A 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 UIUI User 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 sidebarSidebar A 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 BlockBlock Block 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 widgetWidget A 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 APIAPI An 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).

Changelog

Features

Post Editor

Show media upload progress in a snackbar. (77249)

Client Side Media

Revert client-side media processing plugin-only gate. (76751)

Enhancements

Tooltip migrationMigration Moving 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)
Tooltip migration: Fields + media-editor + media-fields + global-styles-ui (4/5). (78691)
Migrate the browserlintrc file to packages/postcss-plugins-preset. (78764)

Components

Combobox: Add primitives. (78399)
Compose: Support React 19 ref callback cleanups in useMergeRefs. (78685)
DataViewsPicker: Add a new pickerActivity layout. (78941)
Storybook: Enhance Theme Provider example with admin-ui Page. (78814)
Theme package: Add element size design tokens. (76545)
Theme: Drop density support from @wordpress/theme. (78741)
Theme: Increase stroke1 contrast target to 2.9. (77599)
Tooltip: Use md border radius for portaled popups. (78983)
UI: Update CSSCSS Cascading Style Sheets. cascade layers to use nesting. (78959)
UI: Update @base-ui/react to 1.5.0. (78448)

Block Library

Add playlist track length setting. (78954)
Blocks: Allow the Loginout block as an inner block in the Navigation Submenu block. (75497)
Hide paragraph Drop Cap and Fit Text controls when a state is selected. (78672)
Icons: Rename timeToRead to time. (78804)
Playlist Block: Add visualization style selector. (76147)
Try allowing transforms to a variation of another block. (78713)

Media

Media Editor Modal: Reorder details fields so the editable regular layout fields appear at the top. (78792)
Media Editor: Add aspect ratio control to mobile toolbar. (78935)
Media Editor: Refactor modal layout. (78896)
Media Editor: Replace the zoom slider with +/- buttons. (78928)
Media editor: Tweak paddings and margins. (79009)

Dashboard

Move layout settings to customize toolbar. (78738)
Opinionated grid columns with container breakpoints. (78732)
Promote WidgetRender into widget-primitives. (78821)
Replace grid row height controls with size presets. (78735)
Use Howdy greeting for page title. (78740)

Post Editor

UI: Tooltip.Provider — forward upstream closeDelay and timeout props. (78642)
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 API The 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)

Collaboration

RTC: Prevent slower polling filters. (78811)
RTC: Return forbidden rooms together. (78748)

Site Editor

Apply the user’s admin color scheme. (78397)
Post list: Remove close button from Quick Edit drawer. (78730)

Block Editor

Changed labels to consistently use Patterns in favor of Block patterns. (56880)
List View: Remove redundant visibilityLabel compoutation. (78640)
Add React 19 as an experimental flag. (79077)

Icons

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 hooksHooks In 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)
ShortcodeShortcode A 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)
Media Editor: Small tweak to gutters. (79168)

Components

Button.Icon: Fix clipped icons. (78614)
Compose: Fix SSR crash in useMediaQuery and useViewportMatch. (78725)
ColorPalette: Don’t render when custom colors disabled and no colors passed. (72402)
ui/AlertDialog: Fix footer layout style override. (78953)

Global Styles

Elements: Align class name parsing with custom CSS implementation. (79023)
Elements: Guard against non-string className in render filterFilter Filters 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)

Block Editor

Inserter: Use forwardRef for refs. (79006)
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 avatarAvatar An 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 HTTPHTTP HTTP 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)

AccessibilityAccessibility Accessibility (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 htmlHTML HyperText 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)

Font Library

Fix focus issue when navigating. (78671)

Performance

Add Events widget. (78553)

Experiments

Dashboard

Add Events widget. (78553)
Event widget iteration. (78815)
Hello Dolly. (78648)
Show ghost widgets visually & allow easy removal. (78502)

Documentation

Added Missing Global Documentation. (78997)
Build: Update changelog. (78807)
DataViews: Add DataViews components to components manifest. (78960)
Docs: Auto-generate per-block API reference pages from block.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.. (77612)
Docs: Fix stale, incorrect, or missing documentation. (78686)
Docs: Remove stale mobile references from tooling and primitives documentation. (79041)
Fix wordpress/data README fragment links. (78866)
Remove orphaned README files for deleted native-only components. (79035)

Code Quality

Codemods: Remove one-shot Tooltip migration codemod. (78669)
Docs: Fix big_image_size_threshold xrefxref (php-xref, phpdoc, inline docs) typo. (76299)
Format Library: Migrate to recommended @wordpress/ui components. (79059)
Framework: Remove invalidinvalid A 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)
Scripts: Remove obsolete bin/setup-local-env.sh. (78871)
Storybook: Declare workspace dependencies for theme example story. (78979)
Tools: Ban classnames via Syncpack. (79061)
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 trunktrunk A 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)
Packages: Declare missing @types/react dependency. (78882)
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 RevisionsRevisions The 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)

Components

wordpress/theme: Deduplicate addFallbackToVar helper. (78666)
Navigable Container: Hoist getFocusableContext out of the component. (79029)
Remove dead native code branches from Platform usages. (79031)
refactor: Move React dependencies to workspace configuration and upda…. (78981)

Dashboard

Rename WidgetChrome to DashboardWidgetChrome. (78751)
Rename widget-types to widget-primitives and consolidate the widget contract. (78749)
Replace surface with host in widget contract documentation. (78778)

Block Editor

Refactor Inserter to a function component. (78766)
Rich text: Use subscribeDelegatedListener for element event listeners. (79047)

Site Editor

theme/ThemeProvider: Rename color.bg prop to color.background. (79007)

Tools

Add copilot-instructions.md file. (78584)
Remove orphaned mobile bugbug A 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: Remove Validate Gradle Wrapper workflow. (79030)
CI: Skip plugin repo release when SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. tagtag A 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)
Remove platform-docs Docusaurus site. (79034)
Skip including inactive or experimental routes when building for WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. (76715)
feat: Migrate performance results to tools release. (78761)
Add more React internals polyfills. (79142)

Testing

Abilities: Add validation tests pinning behavior for WP-specific schema keywords. (78783)
CI: Suppress lint:Js warnings on static checks. (79025)
Try omit-unchanged for compressed-size-action. (78976)
e2e-test-utils-playwright: Start transpiling again, but faster. (79026)

Data Layer

@apermo: Docs: Fix big_image_size_threshold xref typo. (76299)

First-time contributors

A call out and big welcome to first-time contributors, who merged the following PRs:

@apermo: Docs: Fix big_image_size_threshold xref typo. (76299)
@colinduwe: Changed labels to consistently use Patterns in favor of Block patterns. (56880)
@ekamran: Fix wordpress/data README fragment links. (78866)
@i-am-chitti: Tools: Migrate docs/tool into tools/docs workspace. (78870)
@Kgupta62: Common CSS: Avoid false-positive border-style on custom properties. (77476)
@macayu17: Button.Icon: Fix clipped icons. (78614)
@n8finch: ColorPalette: Don’t render when custom colors disabled and no colors passed. (72402)
@simondud: Fix: Block auto-complete for AI API Keys in Connectors. (78946)

Contributors

Gutenberg 23.4 was brought to you by the following contributors:

@aaronrobertshaw @adamsilverstein @aduth @alecgeatches @amitraj2203 @andrewserong @apermo @ciampo @colinduwe @desrosj @ekamran @elazzabi @ellatrix @fushar @gziolo @hbhalodia @hi0001234d @himanshupathak95 @i-am-chitti @im3dabasia @Infinite-Null @itzmekhokan @jameskoster @jasmussen @jsnajdr @juanfra @juanmaguitar @Kgupta62 @kushagra-goyal-14 @macayu17 @Mamaduka @manzoorwanijk @mikachan @mirka @Mustafabharmal @n8finch @ntsekouras @oandregal @paulopmt1 @ramonjd @retrofox @sarthaknagoshe2002 @scruffian @shail-mehta @shekharnwagh @simison @simondud @sirreal @t-hamano @talldan @tellthemachines @torounit @tyxla @USERSATOSHI @westonruter @xavier-lc @yogeshbhutkar

#block-editor #core-editor #gutenberg #gutenberg-new

Amy Kamala 2:51 am on June 17, 2026
Tags: 7.1 ( 20 ), agenda ( 1,136 ), core ( 737 ), dev chat ( 914 )

Dev Chat Agenda – June 17, 2026

The next WordPress Developers Chat will take place on Wednesday, June 17, 2026, at 15:00 UTC in the core channel on Make WordPress Slack.

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 ticketticket Created 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.

Announcements 📢

Discussions 💬

The discussion section of the agenda is for discussing important topics affecting the upcoming release or larger initiatives that impact the CoreCore Core 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.

#7-1, #agenda, #core, #dev-chat

Aditya Dhade 5:10 pm on June 16, 2026
Tags: core-performance ( 145 ), hosting ( 50 ), performance ( 411 ), performance-chat ( 338 ), summary ( 972 )

Performance Chat Summary: 16 June 2026

The full chat log is available beginning here on Slack.

WordPress Performance TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets

@westonruter shared the current performance-focused Trac report and highlighted #65215.
- @westonruter noted that the ticketticket Created for both bug reports and feature development on the bug tracker. is likely close to being merged and just needs another review.
@mukesh27 asked whether there are any high-priority tickets the team should focus on for WordPress 7.1.
- @westonruter identified View Transitions on the frontend and Enhanced Responsive Images as two areas that stand out for 7.1. and noted that both already have feature plugins and need further iteration before they are ready for a CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. merge proposal.
@nickchomey shared plans to open a Core Trac ticket proposing a libvips-based image editor for WordPress Core. @nickchomey argued that libvips offers significant CPU and memory advantages over Imagick and could be particularly valuable alongside the planned client-side vips-based image processing work expected for 7.1.
- @westonruter agreed that Core support would likely be necessary before hosting providers prioritize adoption, though adoption would likely be gradual. @mukesh27 suggested creating a Core Trac ticket so discussion and feedback could be tracked in a central location. @nickchomey confirmed that a ticket was about to be published.

Performance Lab PluginPlugin A 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 other performance plugins)

@mukesh27 shared that work has started on Gallery blockBlock Block 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. support for Enhanced Responsive Images Plugin in PR #2534, with additional PRs planned on a case-by-case basis.
- @westonruter confirmed that @mukesh27 is working on tests for Enhanced Responsive Images.
@westonruter also mentioned Optimization Detective as another important area to continue moving forward.
@westonruter noted that a new release of the Performance plugins is needed.
- @westonruter shared that most recent work has focused on infrastructure maintenance with environments, testing, and minimum version bumps, so there is not a whole lot ready to release.
- @westonruter noted that Performance Lab and View Transitions currently appear to have merged PRs ready to go.
- @b1ink0 noted that there are many PRs currently in review across the project milestones.
- @westonruter suggested getting more PRs reviewed and merged and proposed planning for a Thursday release with whatever changes are merged by then.
@nickchomey shared that work is nearly complete on a PR for CSSCSS Cascading Style Sheets. Gradient-only Placeholder Images related to issue #2519 and asked whether it might get some eyes on it soon or if priorities are elsewhere for the near future. @westonruter replied that the team should be able to take a look.
@b1ink0 shared that the “Add support for chronological and pagination transitions” PR #2336 has been pending for a long time and added a comment regarding how the project should proceed with the implementation of the user-facing options.

Our next chat will be held on Tuesday, June 30, 2026 at 16:00 UTC in the #core-performance channel in Slack.

#core-performance, #hosting, #performance, #performance-chat, #summary

Jonathan Desrosiers 1:54 pm on June 15, 2026
Tags: core-committer-meetings ( 8 ), core-committers ( 9 )

Core Committers Meeting – WordCamp Europe 2026

On June 5, 2026, CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committers in attendance (including emeritus) at WordCamp Europe in Kraków, Poland gathered for a brief informal meeting.

The WordPress Core Committers posing on stage at WordCamp Europe 2026 after meeting.

There was no formal agenda, but a few goals for the meeting were mentioned at the beginning:

Allow newer committers to meet more senior ones.
Allow anyone to raise questions, concerns, or suggestions that have been on their minds.
Just spend some time together chatting and getting to know each other.
Discuss short and medium term challenges.

Below are some brief notes from discussions that happened following Chatham House Rule.

Reducing Friction Between Code Bases

The meeting started by discussing the recent changes to the build scripts in both wordpress-develop and gutenberg aimed at making it easier to sync the changes from gutenberg on GitHubGitHub GitHub 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/ into wordpress-develop in SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase..

It was painful at first, but the most disruptive initial issues have been addressed.
The svn:ignore properties are still out of sync with the changes made to .gitignore.
#64971 is open to address this.
This is very easy to miss due to differences between SVN and GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/.
This process should be a reoccurring task.
The process is very manual in nature (every change needs human review and confirmation).
There could possibly be some form of automation to detect when they fall out of sync.
The new concepts behind the build script changes (pages and routes) are quite novel. This took some time to adjust and learn for most to understand and get right.
New edge cases are still being discovered, so everyone needs to be attentive and responsive to reports. Example: discontinuing the practice of pinning @wordpress npm dependencies to each release has made the package-update --dist-tag=7.0 no longer works (see the related conversation in Slack).
While working on build tooling-related tasks is not always enjoyable, more eyes are needed to refine the changes.
Overall, this brought the two code bases closer together and clears the way for more frequent syncing. But the speed at which each operates is still quite different.

Improving Communication

Maintainers need to put more of an emphasis on consistency and err on the side of over communicating. Announcing in progress explorations or planned changes earlier has many benefits:

Avoids breaking contributor workflows
Sets consistent and clear expectations (no surprises)
Limits unconsidered edge cases
Increases the chances for feedback
Higher quality feedback overall
Ensures the full context, motivations, background, and goals behind a given change are known and understood.
Smaller gap between perceptions and realities.

The form of communication was not clear and would likely vary at different phases. It could involve RFCs (requests for change), TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. updates, weekly Dev Chat discussions, and more.

A Canary-style Approach to WordPress

A proposal was made to consider approaching WordPress development in a similar way to Chrome (using a Canary-style version with feature flags). The idea is to have the ability to work on more features at once, faster, being more proactive about requesting feedback, collect more crash telemetry, etc.
There was a healthy discussion that ultimately led to agreement that this would represent a significant shift from how Core is built and maintained today. Everything from how code is committed to how Trac/GitHub/tickets are utilized to how the project communicates what’s being worked on and what changes are upcoming would need to change. Some talking points that were discussed at length without a resolution:

What would the difference between Core + GutenbergGutenberg The 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/ pluginPlugin A 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. be from these Canary-style builds?
How would someone decide between builds?
How would the location be chosen for a feature (stable in wordpress-develop, experimental in gutenberg, etc.)?
There’s currently no concept of experimental features within wordpress-develop, but there is in Gutenberg.
When someone builds a feature on a Canary-style build and dependent code is removed or changed, that breaks.
Should there still be a Gutenberg plugin? What if PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher was not allowed in Gutenberg and had to be committed to wordpress-develop instead?

Currently, wordpress.org seems to be the canary along with anyone else running the nightly builds. WordPress.com runs the Gutenberg plugin, which has made it much easier to update once reaching the betaBeta A 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. release phase of a release. However, w.com is an outlier and many of the problems that are found do not typically affect more managed hosts.

More Testing More Often

It was mentioned that the problem that was being targeted is that it’s not easy to test one specific feature and the project can often receive late or inadequate levels of testing. There also can be a hesitance to merge certain features because it’s not clear what the desired level of testing is, or if that has actually been achieved.

Most of the discussion so far was acknowledged to be a technical solution to a communications problem. Canary-styled releases have also become a marketing solution for Chrome, not necessarily a “more testing” one. It could also become even more confusing for users very quickly. The conversation shifted to discussing the feedback problem.

Far too few sites test the beta/RCrelease candidate One 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 for each release.
It’s unknown how many sites turn on the experiments in the Gutenberg plugin. Or how many actually interact with those experiments.
The Beta Tester plugin currently only has ~3,000 active installs, and those installs may not be configured to use non-stable releases.

Beta Testing Natively In Core

One option mentioned was to consider merging the Beta Tester plugin into Core. There was broad agreement to at least explore this idea.

People click on things when they see them in an interface when they sound good.
There would need to be a way to revert to a stable release in case. Though this doesn’t currently exist and is not supported. Database migrations do not work in reverse.
Would this shoot the project in the foot by making it easier to opt-in to these development releases?
Cleaning up old files that never actually made it into a release could be a problem.
The risk of breaking live sites increases. This needs to be properly communicated and the project needs to be prepared to deal with these scenarios.
Allowing someone to opt-in to beta and RC releases is a low risk good first step.
It could be gated behind a constant in a way similar to multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site with WP_ALLOW_MULTISITE. At that point, would it be any different than testing features in Gutenberg or a feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins?

Other Shared Thoughts

The project as a whole needs to be more clear about what type of feedback is desired (user feedback, technical feedback, etc.).
The path for turning on experimental features has gotten pretty complex in some cases. For example, the content policies experiment in Gutenberg requires the AI plugin as well as a connector to be installed and active. Sometimes experiments also require a specific patchpatch A 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. or pull request.
There could possibly be a way to opt-in to all experiments that ship in the Gutenberg plugin, including any added in the future.
It would be great to have a way to know how many sites are using each experiment.

Thoughts on Real-time Collaboration

An open floor was set for feedback about removing real-time collaboration from the WordPress 7.0 release.

The overwhelming majority of attendees agreed with the move to revert the feature for the 7.0 release.
There needs to be a clear list of criteria to be met before reconsidering. The reasons for removal were reasonable and real, but it’s not yet clear how to address each of those.
Some felt that the ball was dropped telling the story behind the feature. What would it actually mean in practice to users, especially those with a single user?
RTC could possibly enable a level of agentic AI functionality, but that is more likely to be made possible with the Notes feature.
There needs to be a final architectural decision that the project is comfortable standing behind and supporting long term.
Some expressed that they felt it had to go in and would no matter what because experienced names were called in to help address the shortcomings of the feature at the last minute.
It has been unclear at times how the feature fits into the overall goals of the project.
What does the delay of shipping RTC mean for the 4 phases of Gutenberg and the project’s current priorities?

Does The Feature Belong In Core?

A strong opinion, loosely held, was expressed and discussed: The full RTC feature set should not be in core, but the underlying architecture should be.

There is a lot of overhead being added with very little apparent gain at the moment.
Some of the YJS pieces and integrations must be in Core to actually work.
What if core only shipped with the WebSockets transport, with the HTTPHTTP HTTP 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. polling transport being the optional plugin given the scaling issues?
The feature could be added in two parts, similar to the REST APIREST API The 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/.
Who would maintain the parts that are merged into Core?
This approach could result in a new flavor of WordPress hosting with support for RTC. This could be frustrating for users if they change hosts and find the feature no longer works.

Recent Changes to Committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. GitHub Capabilitiescapability A 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).

One attendee mentioned that they no longer have the ability to bypass the required checks on pull requests in the Gutenberg repository (something that was previously possible). They were curious if their access had been adjusted or capabilities were adjusted. It was mentioned that there are a handful of other Committers who have reported differences in what actions they are able perform on GitHub (restarting Action workflow runs, etc.).

To the knowledge of everyone in attendance, there have been no intentional changes made to the WordPress Core team under the WordPress organization (which includes all Core Committers). It’s possible that something has changed on the GitHub side.

@desrosj and @johnbillion will investigate this and follow up in #core-committers.

Process Reminder for Assigning Commit-level Access

The group was reminded that since the bulk adjustment was made to sync the two groups in 2024, being a Core SVN committer is a requirement for being included in the Gutenberg Core team on GitHub. While this team is a subset of Core Committers, this must be followed for consistency in committer-level access across the two code bases and reinforcing the fact that “Core = Gutenberg, Gutenberg = Core”.

The team’s description on GitHub will be updated to reference this policy to make it harder to forget. The Core Handbook and documentation within the Gutenberg repository will be updated as well.

Summary

Attendees shared at the end that the meeting was very helpful for everyone to get on the same page. It was suggested that more frequent meetings (a mix of both virtual and in-person) for the group would be very beneficial.

Action Items

Address differences between svn:ignore properties and .gitignore rules through #64971.
Continue testing and iterating on the new build processes introduced during 7.0 and consider ways to improve these scripts further.
Be more communicative about any work being done/changes being considered, why they’re important, and the honest state of the efforts.
Think of ways to increase testing of every upcoming WordPress release. Follow up with proposals for suggested changes publicly.
Think of new ways to create and strengthen feedback loops to increase confidence in specific changes.
Seek clarity on the next steps and new acceptance criteria for Real-time Collaboration.
Investigate recent changes to the committer-level access on GitHub.
Consider ways for Core Committers to sync more frequently.

Props @dmsnell, @westonruter, @johnbillion for pre-publish review.

#core-committer-meetings, #core-committers

Dennis Snell 5:17 pm on June 10, 2026
Tags: call for testing ( 7 ), email ( 5 ), unicode ( 2 )

Call for Testing: Unicode email addresses.

Last month a call for input was sent concerning the introduction of Unicode email addresses for WordPress accounts (#31992). Initial support was merged in [62482]. Here is what you need to know in order to test this change on your sites and in your plugins and themes.

is_email() and sanitize_email() accept non-ASCII email addresses like grå@grå.org if the site database’s charset is utf8mb4.
Support is added as an enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. which can be disabled by removing the is_email and sanitize_email filters for wp_is_unicode_email and wp_sanitize_unicode_email, respectively.
A new class — WP_Email_Address — provides a structural view into email addresses so your code doesn’t have to guess. It provides the local part, the domain part, and decodes Punycode translations in the domain part.

It should be possible, therefore, to create WordPress accounts with email addresses not previously allowed. In addition, email validation is updated to match the WHATWG email specification so that WordPress and an <input type=email> element will agree on what is and what isn’t allowable.

The term “Unicode email address” may be a bit ambiguous because there are two ways emails can be considered Unicode:

Unicode domain support has been supported for many years through Punycode encoding of the domain. This is an ASCII-encoded version of Unicode domains where the domain parts start with xn--, like xn--uist2j67d64zv30b.xn--ses554g as a stand-in for 慕田峪长城.网址. Because the encoding is all ASCII, WordPress has implicitly supported Unicode domains without recognizing them. The change in [62482] decodes the domain parts so that WordPress and its plugins and themes can access either the ASCII representation (for circumstances like HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. attributes where software will read their value) or the Unicode representation (for circumstances like text nodes where human will read their value).
Unicode local part (mailbox) support has largely been absent from specifications and software until recently when most major email hosts started routing mail with UTF-8 mailboxes. WordPress previously rejected all addresses containing non-ASCII characters. It now accepts valid UTF-8 local parts. There has never been an ASCII-encoding of this part of the email address.

If your extension code expects email addresses to only contain ASCII bytes, they will need updating for WordPress’ new Unicode email support. The easiest way to account for this is to use the new WP_Email_Address::from_string() and then access its getter methods.

// Generate an author link.

$email = WP_Email_Address::from_string( $provided_email );
if ( null === $email ) {
    return '';
}

$processor = new WP_HTML_Tag_Processor( '<a> </a>' );
$processor->next_tag();
$processor->set_attribute( 'href', "mailto:{$email->get_ascii_address()}" );
$processor->next_token();
$processor->set_modifiable_text( $email->get_unicode_address() );
return $processor->get_updated_html();

If your pluginPlugin A 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. connects with a third party service using email addresses from WordPress, now is a good time to ensure that third party also properly supports Unicode email addresses. If not, you can disable Unicode email support with the following snippet.

// Disable Unicode email support until third-party integration supports them.

remove_filter( 'is_email', 'wp_is_unicode_email', 10 );
remove_filter( 'sanitize_email', 'wp_sanitize_unicode_email', 10 );
add_filter( 'is_email', 'wp_is_ascii_email', 10, 3 );
add_filter( 'sanitize_email', 'wp_sanitize_ascii_email', 10, 3 );

Thank you!

This change updates existing email validation and sanitization code and introduces new behaviors for an unbounded set of potential email addresses. It’s likely that unanticipated cases will arise, and with your feedback in these cases, this feature can be a successful part of WordPress 7.1.

Props

Thanks to @amykamala and @jorbin for reviewing this post!

#call-for-testing, #email, #unicode

Amy Kamala 3:56 am on June 10, 2026
Tags: 7.1 ( 20 ), agenda ( 1,136 ), core ( 737 ), dev chat ( 914 )

Dev Chat Agenda – June 10, 2026

The next WordPress Developers Chat will take place on Wednesday, June 10, 2026, at 15:00 UTC in the core channel on Make WordPress Slack.

The live meeting will focus on the discussion for upcoming releases, and have an open floor section.

Announcements 📢

CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.

General

Discussions 💬

The discussion section of the agenda is for discussing important topics affecting the upcoming release or larger initiatives that impact the Core 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 🎙️

#7-1, #agenda, #core, #dev-chat

Aaron Jorbin 3:35 pm on June 8, 2026
Tags: 7.0 ( 76 ), 7.0.1 ( 5 ), 7.0.x ( 2 ), maintenance ( 13 )

Call for WordPress 7.0.x Release Managers

WordPress 7.0.0 was released May 20, 2026. While the work of a major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. team includes people filling many different positions, maintenance release teams generally are considerably smaller, often 1–3 people. Minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. managers are responsible for:

Triaging bugs in coordination with committers and component maintainers.
Drafting announcements for the release.
Preparing for and running release day activities.
Updating the documentation on minor releases so that it gets better each time.

Members of the 7.0 release cohort are encouraged to stay on as release managers for maintenance releases, but it is not required to have been on a major release squad in order to be on a minor release team.

WordPress 7.0.1 is tentatively targeted for release later in June 2026.

If you are interested in volunteering to be a release manager for the 7.0.x maintenance releases, please comment on this post or message me directly.

Props to @annezazu, @audrasjb, @wildworks for reviewing this post before publication.

#7-0, #7-0-1, #7-0-x, #maintenance

Jarda Snajdr 12:04 pm on June 5, 2026

React 19 upgrade temporarily reverted in Gutenberg

Few days ago we announced that WordPress and GutenbergGutenberg The 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/ are upgrading to ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org 19. But soon after publishing a Gutenberg version with the upgrade (23.3.0) we discovered that many plugins that were built for the previous version of WordPress, with React 18, are incompatible with the new version and crash often.

While there are virtually no APIAPI An 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. changes between React 18 and 19, the runtimes turned out to be incompatible in unexpected ways. For example, many plugins bundle their own version of the react/jsx-runtime helper used to process JSX syntax, but the shape of the generated objects (elements) is different, and React 19 actively checks and rejects elements generated by the React 18 runtime.

We’ll have to devise a better, less naive and more incremental upgrade strategy. With ability to switch between React 18 and 19 with an experimental feature flag, and with a compat layer for already released plugins. In the meantime, we decided to revert back to React 18, and released the revert in Gutenberg 23.3.2. This gives us time and breathing room to think the new strategy through and test it thorougly. We continue to be committed to doing the upgrade in WordPress 7.1.

Welcome!

Communication

What went wrong?

What was resolved?

What was the process for the resolution?

What is important to understand about this merge?

What still remains to be done?

Thanks you!

Timeline

Preparing WordPress for ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org 19

The Site Editor follows your admin color scheme

Media

Columns and Gallery blocks can transform into grid layouts

Other notable highlights

Changelog

Features

Post Editor

Client Side Media

Enhancements

Components

Block Library

Media

Dashboard

Post Editor

Data Layer

Collaboration

Site Editor

Block Editor

Icons

Font Library

Client Side Media

New APIs

Extensibility

Bug Fixes

Block Library

Media

Components

Global Styles

Block Editor

Client Side Media

Plugin

Data Layer

Post Editor

Connectors screen

Icons

Dashboard

Block API

Block Editor

Block Library

Patterns

Font Library

Performance

Experiments

Dashboard

Documentation

Code Quality

Block Library

Data Layer

Post Editor

Components

Dashboard

Block Editor

Site Editor

Tools

Build Tooling

Testing

Data Layer

First-time contributors

Contributors

Announcements 📢

Discussions 💬

Open floor 🎙️

WordPress Performance TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets

Reducing Friction Between Code Bases

Improving Communication

A Canary-style Approach to WordPress

More Testing More Often

Beta Testing Natively In Core

Other Shared Thoughts

Thoughts on Real-time Collaboration