X-comment from +make.wordpress.org/hosting: Comment on Urgent: Testing request to Web hosts for collaborative editing by May 4th
The next WordPress Developers Chat will take place on Wednesday, April 29, 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 ticket 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.
Testing and feedback needed from web hosts
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.
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.
Props to @kirasong for proofreading and review
The Presence API is an experimental feature plugin that provides a system-wide awareness layer — who is logged in, what admin screens they are on, and which posts they are editing.
This idea of presence I think is really cool and seeing where people are… you log into your WordPress, I see oh Matias is moderating some comments, Lynn is on the dashboard maybe reading some news… that idea of like you log in and you can kind of see the neighborhood of like who else is also there.
Matt Mullenweg, WordPress 7.0 planning session
There is currently no way to see who else is logged into the WordPress admin at the same time.
Posts being actively edited by another user are only surfaced when a lock collision occurs, by which point work may already overlap.
The post list provides no indication of which posts have active editors until a user tries to open one.
Here’s what that looks like in practice:
Video
Try it yourself in WordPress Playground: 5-user blueprint. The blueprint creates 5 editor accounts with live presence spread across admin screens and posts, so the widgets, admin bar, and post list are populated the moment Playground boots — no second browser or incognito window needed.
See it at scale: 40-user blueprint. Same setup, 40 seeded editors — useful for seeing how the widgets, admin bar, and post list handle density.
Dashboard widgets: “Who’s Online” and “Active Posts”
Admin bar online indicator with avatar stack for on-screen presence
Post list “Editors” column
Users list “Online” filter
REST endpoints and WP-CLI commands
Post-lock bridge (coexists with existing _edit_lock behavior)
All features are gated on the edit_posts capability. Full technical details are in the GitHub repository.
During WordPress 7.0 development, discussion in #64696 identified that storing high-frequency ephemeral data in shared tables causes persistent cache invalidation site-wide. This feature plugin was built to test that workload independently using a dedicated ephemeral data table with a 60-second TTL. Data flows through the existing Heartbeat API. The plugin was presented at a core dev chat and subsequently transferred to the WordPress GitHub organization. It was submitted to the WordPress.org plugin directory on April 6, 2026.
This plugin is experimental. Feedback on the following is especially helpful:
Are the UI surfaces (widgets, admin bar, post list) useful as presented?
Are there admin screens or workflows where presence would be valuable?
Discussion and development: #feature-presence-api on WordPress Slack
Bug reports and discussion: GitHub Issues
Thank you to @jorbin and @desrosj for helping to stand up this feature plugin.
Props @peterwilsoncc, @mindctrl, @czarate, @davidbaumwald, @dd32, @maxschmeling, and @westonruter for the architectural discussion in #64696 that informed this work.
“What’s new in 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.0?
Gutenberg 23.0 has been released and is available for download!
This release introduces a revisions panel for templates, template parts, and patterns (experimental), and extends the Site Editor’s Design › Identity panel with Site Title and Site Tagline fields, completing the set alongside the previously added Site Logo and Icon. Real-time collaboration gains compatibility with legacy meta boxes and a range of reliability improvements, while the block editor receives several quality-of-life refinements.
A total of 174 PRs were merged in Gutenberg 23.0, with 8 first-time contributors.
Table of contents
Editing a template, template part, or pattern now surfaces the same Revisions panel previously available only for posts and pages. When any of these entities has revisions, a Revisions row appears in the sidebar with access to review and restore prior versions, matching the behavior already in place for regular post types.
This is part of the ongoing Editor Inspector: Use DataForm experiment, which is progressively rolling out a unified DataForm-based inspector across all post types. Enable the experiment from Gutenberg → Experiments to try it in the Site Editor or while editing a template from the Post Editor. (#77008)
The Design › Identity panel — introduced in 22.8 with Site Logo and Site Icon — now also includes Site Title and Site Tagline. All four identity settings sit in a single panel, editable directly from the Site Editor without a trip to Settings → General. Because the title and tagline fields write to the same root/site entity that the Site Title and Site Tagline blocks read from, edits show up live in the editor canvas as you type. The panel uses consistent field styling across text and media controls, so the four settings read as one unified form. (#76264)
Real-time Collaboration, legacy meta box compatibility. Plugin authors can now mark individual meta boxes as RTC-compatible using a new __rtc_compatible_meta_box flag, so the presence of a legacy meta box no longer unconditionally disables collaboration. Site administrators can also apply the flag to third-party meta boxes via the existing filter_block_editor_meta_boxes hook. (#76939)
Real-time Collaboration, reliability. Concurrent edits to array-type block attributes — such as table rows — are now preserved when the array is restructured (#77164). A single corrupted sync update no longer crashes the whole poll cycle and disconnects every room (#76968). Gutenberg’s activation hook now honors the Core WP_ALLOW_COLLABORATION constant, giving hosts a reliable kill switch (#77084).
Keyboard shortcuts for moving blocks surface in tooltips. The block toolbar’s move-up / move-down tooltips now display their keyboard shortcuts. (#76992)
Spacing side controls re-order when unlinked. When link mode is off, the four side inputs are arranged in a more predictable order. (#66317)
Separator block honors the --- shortcut’s default variation. Inserting a Separator via the Markdown-style --- shortcut now applies the block’s default style variation, matching the behavior of inserting it through the inserter. (#77135)
If you had the Guidelines experiment enabled in a previous release, 23.0 renames its internal identifiers from content-guidelines / content_guideline to guidelines / guideline. The rename covers the custom post type slug, REST base, meta keys, experiment flag, and Redux store. Because the experiment flag itself is renamed, it will appear disabled after updating — you’ll need to re-enable it from Gutenberg → Experiments and re-enter any previously saved guidelines. (#77147, #77223)
wordpress/ui: Add global CSS defense module. (76783)
Admin UI: Increase page header vertical padding. (77152)
Admin UI: Update Page background color to surface-neutral. (76869)
Autocomplete: Remove getAutoCompleterUI factory pattern. (77048)
DataForm: Add min/max date range support for date and datetime fields. (77201)
DataForm: Show tooltip in edit button in panel layout. (77024)
DataForm: Support disabled controls. (77090)
FormToggle: Update disabled styles. (77208)
Media Upload Modal: Persist view configuration. (77288)
Text: Remove UA margins. (76970)
UI Text: Mark as recommended. (77044)
UI/Dialog: Add explicit margin-inline-end rule to Title. (77334)
UI: Update @base-ui/react from 1.3.0 to 1.4.0. (77308)
UI: Use Text component for Badge typography. (77295)
Use --wpds-cursor-control design token for interactive controls. (76786), (77259)
@wordpress/ui: Add Popover. (76438)
ui/AlertDialog: Better async confirm APIs, fully use base ui’s AlertDialog. (76937)
ui/Dialog: Update Header layout, refactor Title to use Text. (77161)
ui: Expose container portal prop on all overlay Popup components. (77163)
Add context for next/previous enlarge image. (76967)
Image block: Validate attachment ID exists before treating image as local. (77178)
Search Block: Ensure color settings apply to input field when button is disabled. (77219)
Tab Menu Item: Simplify active tab menu item style. (77195)
Tabs: Remove sequential numbering from new tab labels. (77321)
Use entity link title for link control preview. (77155)
Guidelines CPT: Rename from “content guidelines” to “guidelines” (slug, classes, routes). (77147), (77223)
Guidelines: Make the CPT type-aware. (77491)
Improve guideline revision UX. (76560)
Registers wp_guideline_type taxonomy. (77156)
Update actions-section and import/export workflow. (76621)
DataViews: Simplify defaultLayouts prop. (77232)
RTC: Add filterable flag for meta box RTC compatibility. (76939)
RTC: Change SyncConnectionModal to isSyncConnectionErrorHandled filter and drop IS_GUTENBERG_PLUGIN check. (76853)
Display shortcuts for moving blocks via tooltips. (76992)
Re-order spacing side controls when unlinked. (66317)
date field in templates and template parts. (77134)Backport: Improve validation and permission checks for WP_HTTP_Polling_Sync_Server. (76987)
RTC: Add optional shouldSync function to entity sync configuration. (76947)
RTC: Respect WP_ALLOW_COLLABORATION in Gutenberg for activation hook. (77084)
Calendar: Fix disabled styles. (77138)
Card: Set default foreground color on root. (77013)
Checkbox: Fix disabled styles. (77132)
DataForm: Remove text-transform from panel field labels. (77196)
DataViews: Fix compact density clipping and remove top/bottom padding. (77054)
Fix autocomplete overlapping trigger matching. (77018)
FormTokenField: Fix disabled styles. (77137)
RTC: Fix inline inserter reset on update sync. (76980)
RadioControl: Add support for disabling radio group. (77127)
Remove sandbox allow-same-origin for core/html blocks. (77212)
TextArea: Add disabled styles. (77129)
UI: Normalize render prop and ref forwarding patterns. (77160)
Cover block: Fix embed video background Error 153 in editor. (76904)
Fix overflow of highlighted white-space in Code Block. (77085)
Image block: Hide drag handles while an upload is in progress. (77121)
Paragraph: Prevent onEnter splitting of parent block when insertion of that block type is not allowed. (77291)
Post Author Biography: Preserve occurrence of white spaces. (71133)
RTC: Core/cover block minor compatibility fixes. (76916)
Search block: Match behavior of global styling for border and color with local styling (inspector controls) to remove inconsistency. (77060)
Search block: Derive ‘isSearchFieldHidden’ value. (77082)
Separator Block: Apply default block variation when inserting via --- shortcut. (77135)
Upload external media: Ensure notice only fires once. (77218)
Fix SyntaxError in Autocompleter UI when pasting matching content. (76961)
LinkPicker: Decode HTML entities in link preview title. (77170)
Prevent Enter key from inserting paragraphs in contentOnly sections. (76989)
RTC: Fix “Edit as HTML” content reset during collaboration. (77043)
Writing Flow: Fix format toolbar not appearing when selecting text from block edge. (77136)
contentOnly template lock: Fix block insertion and removal rules. (77119)
Fix numeric value clearing in preset input controls. (77139)
Core Data: Fix ‘useEntityProp’ for raw attributes. (77120)
Core Data: Fix incorrect pagination for non-paginated entities. (76406)
RTC: Fix core/table cell merging. (76913)
RTC: Fix orphaned meta causing dirty editor state. (77529)
RTC: Improve array attribute stability when structural changes occur. (77164)
getMergedItemsIds: Receive full page bigger than perPage. (77262)
Account for mu-plugins when resolving plugin.file status. (76994)
Don’t clobber third-party custom render in registerDefaultConnectors. (77116)
Hide Akismet unless already installed. (76962)
Replace speak() with notice store for state changes. (77174)
Update help text from ‘reset’ to ‘manage’. (76963)
Fields: Fix postContentInfoField when there are edits. (76901)
Fix: Restore editor canvas padding in classic themes. (76864)
RTC: Fix button flickering on retry dialog. (77234)
RTC: Predefined retry schedules for disconnect dialog, make more lenient. (76966)
Revision: Fix ‘Show changes’ button reset state. (77122)
Fix failing ‘WP_HTTP_Polling_Sync_Server’ unit test. (77025)
RTC: Fix disconnect dialog due to uneditable entity. (77242)
RTC: Isolate sync update failures to prevent full disconnect. (76968)
Fix duotone filter not applying on style variation switch. (77229)
Global Styles Revisions: Fix footer overflow. (77103)
ValidatedRangeControl: Fix aria-label rendered as [object Object]. (77042)Add missing documentation in collaboration.php. (77173)
Autocomplete: Clarify ‘isDebounced’ setting limitation. (77062)
Docs: Add README for DatePicker and TimePicker Components. (70365)
Editor: Fix ‘selectedNote’ action JSDoc. (77080)
Eslint: Suggest alternative in no-setting-ds-tokens rule. (77154)
Fix: A sentence has no ending punctuation in README.md file. (77027)
HStack, VStack: Mark as not recommended for use. (77041)
Improve CSS setup instructions in package readmes. (76975)
Storybook: Enable theming toolbar for wp-components. (77038)
Storybook: Fix “Default” cursor option in theming toolbar. (77037)
UI/Tooltip: Add usage guidelines documentation. (77158)
UI: Use Link component in details story example. (76997)
iAPI Docs: Fix typos, code errors, and inaccuracies in the documentation. (76636)
ui/docs: Add additional global css setup instructions. (77228)
Add .scss files to CSS module linting. (77140)
Block Directory: Use --wpds-cursor-control design token. (77330)
Autocomplete: Refactor useAutocomplete to use useReducer. (77020)
BoxControl: Remove unused state for icon side. (77143)
Build Tools: Update TypeScript to 6.0.2. (77010)
Button: Remove obsolete Safari + VoiceOver workaround. (77107)
Button: Remove unused Storybook stylesheet. (77031)
Dataviews: Remove unneeded ref callbacks. (77179)
Extract the autocomplete matcher into a separate function. (76957)
FormTokenField: Remove unnecessary styles. (77263)
Textarea: Remove unnecessary styles. (77221)
Theme: Rename typography tokens to use “typography” prefix. (76912)
Update React function names for better ESLint detection. (77148)
i18n: Make sprintf return FormattedText for type-safe createInterpolateElement. (76974)
ui/Card: Remove redundant margin reset from Card.Title. (77187)
ui/VisuallyHidden: Standardize composition pattern. (77190)
Block Editor store: Refactor controlledInnerBlocks to Set. (77094)
Global Styles: Move pseudo-state slicing logic into useStyle hook. (77104)
BlockMover: Remove unused disabled button props. (76993)
Extract getElementCSSRules from useBlockProps. (77327)
updateBlockListSettings: Convert state to Map, do all updates in one action. (46392)
BlockStyleVariationOverridesWithConfig: Change name and fix lint errors. (77130)
ESLint plugin: Disable jsx-a11y/heading-has-content. (77073)
Edit Post: Fix warning in ‘useMetaBoxInitialization’ hook. (77311)
RTC: Store metaboxes RTC-compatible flag on location entries. (77361)
Revisions: Simplify fetching. (77086)
Tabs: Simplify anchor handling. (77189)
TypeScript: Migrate packages/list-reusable-blocks package to TypeScript. (70518)
TypeScript: Migrate viewport package. (71118)
Remove remaining esModuleInterop usage. (77095)
Blocks: Convert blocks package to TypeScript. (76312)
Autocomplete: Fix flaky end-to-end tests. (77322)
E2E Tests: Ensure artifacts generate correctly and remove unnecessary artifacts. (77093)
Fix page.waitForFunction call arguments in e2e tests. (77300)
Guidelines: Add end-to-end tests based on the Settings page testing instructions. (77192)
Remove ‘Home’ and ‘End’ key usage from Navigation tests. (77102)
Restore original template registration tests alongside activation variants. (77068)
Tests: Auto-fix some new ‘eslint-plugin-playwright’ warnings. (77314)
Tests: Fix workspace test scripts (wp-env not found, argument forwarding). (77055), (77083)
Add iteration issue template. (77113)
Build: Fix glob ignore patterns in dot-prefixed directories. (75114)
Convert directories in test/ to workspaces. (74684)
Env: Fix loopback requests when running on non-default ports. (77057)
Fix lint-staged API documentation path. (77203)
Resolve package-lock.json inconsistency for @babel/eslint-parser. (77256)
Storybook: Fix end-to-end subpath exports and add CI build smoke test. (77034)
Refactor: Migrate bin/api-docs to tools/api-docs as workspace @wordpress/api-docs-generator. (77019)
Upgrade ESLint to v10. (76654)
Fix pre-existing lint errors across the codebase. (77002)
Remove unused catch block variables across the codebase. (76969)
The following PRs were merged by first-time contributors:
@DarkMatter-999: Fix numeric value clearing in preset input controls. (77139)
@dkotter: Update the AI plugin settings page slug we link to after activation. (77336)
@dpmehta: Search block: Match behavior of global styling for border and color with local styling (inspector controls) to remove inconsistency. (77060)
@mehrazmorshed: Fix: A sentence has no ending punctuation in README.md file. (77027)
@prachigarg19: Fix duotone filter not applying on style variation switch. (77229)
@samvaidya: Image block: Validate attachment ID exists before treating image as local. (77178)
@sandipr942: Added missing documentation in collaboration.php. (77173)
@superdav42: Connectors: Don’t clobber third-party custom render in registerDefaultConnectors. (77116)
The following contributors merged PRs in this release:
@adamsilverstein @Adi-ty @aduth @alecgeatches @andrewserong @annezazu @aswasif007 @BugReportOnWeb @CGastrell @chriszarate @ciampo @coderGtm @DAreRodz @DarkMatter-999 @dinhtungdu @dkotter @dpmehta @ellatrix @gziolo @hbhalodia @iamchughmayank @Infinite-Null @ingeniumed @jameskoster @jeryj @jorgefilipecosta @jsnajdr @kushagra-goyal-14 @madhusudhand @MaggieCabrera @Mamaduka @manzoorwanijk @mehrazmorshed @mirka @nerrad @ntsekouras @oandregal @prachigarg19 @R1shabh-Gupta @ramonjd @samvaidya @sandipr942 @scruffian @shail-mehta @Shekhar0109 @shrivastavanolo @superdav42 @Swanand01 @t-hamano @talldan @tyxla @USERSATOSHI @yashjawale @yogeshbhutkar
Below you find a table that lists all core blocks available in the inserter marks in the grid the feature they support in the block editor. It’s a basic lookup table that helps developers to find the information quickly.
While this post is released as part of 6.8, the content summarizes changes between 6.1 and 7.0. This is an updated of the 6.8 edition and provides a cumulative list of design supports added with the last ten WordPress releases. The icon indicates new in 6.9 or 7.0.
The features covered are:
Align
Typography
Color
Dimension
Border
Layout
Gradient
Duotone
Shadow
Background image
The Verse block was renamed to Poetry block in WordPress 7.0
New Blocks added
Accordion with Accordion Heading, Accordion Item, Accordion Panel
Breadcrumbs
Icon
Math
Post Time to Read
Term Query with Term Template, Term Count, Term Name
In previous editions of this roster, the PO/BB column tracked a small, hardcoded set of core blocks where Pattern Overrides and Block Bindings were manually enabled — Button, Image, Paragraph, and Heading. That model no longer reflects how the feature works. WordPress 6.9 moved Block Bindings to a server-communicated list of supported attributes via the block_bindings_supported_attributes filter, and WordPress 7.0 extended that same mechanism to Pattern Overrides, so any block attribute that opts into Block Bindings now also supports Pattern Overrides — including custom blocks. Because support is opt-in per block, per attribute, and per site, a single check mark in a lookup table can no longer represent it accurately. The column has been removed in favor of a note pointing readers to the Pattern Overrides in WP 7.0 and Block Bindings improvements in 6.9 dev notes.
BlockAlignTypographyColorDimensionBorderLayoutGradientDuotoneShadowBackgr.Img****Accordion new new new new new new new new newAccordion Heading new new new new new newAccordion Item new new new new new new newAccordion Panel new new new new new new newArchives ––– Audio–––––Avatar––Breadcrumbs new new new new new newButton––Buttons–Calendar––––Categories––Code––Column–Columns–Comment Author Avatar–––Comment Author Name––Comment Content––Comment Date––Comment Edit Link––Comment Reply Link––Comment Template– new––Comments new–Comments Pagination–––Comments Pagination Next––––Comments Pagination Numbers new–––Comments Pagination Previous––––Comments Title––Cover new newDetails newEmbed––––File–––FootnotesGallery–Group–Heading––Home Link – Navigation–––––HTML––––––Icon new new new newImage––Latest Comments––Latest Posts––List–––List Item– new––Login/logout–––––––Math– new new new new– new–––Media & Text––More (Read More)–––––––Navigation new–––Navigation Link––––––Navigation Submenu– new–––––Next Page (Page Break)–––––––Page List–––Paragraph new––Poetry (formerly Verse)Post Author– newPost Author Biography––Post Author Name––Post Comments Count new––Post Comments Form–Post Comments Link new–Post Content Post Date––Post Excerpt––Post Featured Image––Post Navigation Link––––Post Template–Post Terms––Post Title––Preformatted no link––Pullquote––Query––––Query No Results––––Query Pagination–––Query Pagination Next––––Query Pagination Numbers––––Query Pagination Previous––––Query Title––Query TotalQuote–––Read More––RSS––––Search––Separator––––Site Logo––––Site Tagline––Site Title––Social Link––––––Social Links––Spacer–––––Table––Tag Cloud–––Template PartTerm Count new new new new– newTerm Description–––Term Name new new new new new– new–––Terms Query new–––– new––––Term Template new new new new new new new–––Time To Read– new new new new – new – – –Video – –––– –– – –
*Props to @awetz583, @westonruter, and @blackstar1991 for review. *
Good news, everyone! WordPress 7.0 has a new release date: May 20th, 2026!
Thank you all for your flexibility in these recent weeks while WordPress contributors around the world worked tirelessly on necessary architectural improvements for the 7.0 release. The team aims to ensure that this software version is the most stable and most performant it can be, while still delivering the much anticipated cornerstone features mapped out for WordPress 7.0.
Below is the new release schedule, with expected dates and times for each release party, and the release squad contributors involved in each party for the 7.0 milestone. It also includes the pre-release versions that have already been released, and a (pending) call for testing from web hosts meant to help ensure compatibility across hosting systems.
**Note: **While the most recent pre-release version was RC2, the RC3 release will be treated like a beta version in practice. That means that your continued testing and feedback, particularly on the part of web hosts, will be incredibly valuable in keeping the development process informed during the next phase of this release cycle. Thank you all for your continued testing!
As always, last-minute adjustments to this schedule are possible, and there could be additional timeline iterations based on the impact of host feedback to ensure that feedback is properly addressed. The release squad will do its best to communicate any changes promptly by posting in the #core Slack channel, publishing a post on the change, and updating this post as the canonical reference.
Date (UTC)MilestoneEmcee / Release LeadCommitterSecurity****Mission Control (Coordination)February 19, 2026 at 15:00 UTCBeta 1@amykamala@ellatrix@audrasjb@sergeybiryukovFebruary 26, 2026 at 15:00 UTCBeta 2@amykamala@ellatrix@audrasjb@sergeybiryukovMarch 5, 2026 at 14:00 UTC Beta 3@amykamala@audrasjb Committing from WordCamp Nice Contributor Day@sergeybiryukovMarch 10, 2026 at 23:30 UTC Unplanned beta following the 6.9.2-6.9.3 security releasesBeta 4@desrosj@sergeybiryukov@sergeybiryukov@sergeybiryukovMarch 12, 2026 at 15:00 UTCBeta 5@chaion07@ellatrix@audrasjb@sergeybiryukovMarch 24, 2026 at 15:00 UTCRC 1@amykamala@ellatrix@audrasjb@sergeybiryukovMarch 26, 2026 at 15:00 UTCRC 2@4thhubbard@ellatrix@audrasjb@sergeybiryukovApril 24, 2026Call for host testing@desrosjn/an/an/aMay 8, 2026 at 15:00 UTCRC 3 (in name, but test as a “new Beta 1”)@amykamala@ellatrix@audrasjb@sergeybiryukovMay 14, 2026 at 15:00 UTCRC 4 (in name, but acting as a “new RC1”)@4thhubbard@ellatrix@audrasjb@sergeybiryukovTuesday, May 19, 2026 at 15:00 UTC
Dry Run / 24-Hour Code FreezeTBDTBDTBDTBDWednesday, May 20, 2026
Time TBAGeneral ReleaseTBDTBDTBDTBD
All parties happen in the #core channel on Slack.
Everyone is welcome! First-timers, veteran contributors, and all those curious about the process are invited.
Here are detailed instructions on how to contribute to a release party.
Thank you to every contributor and community member that helps make 7.0 a success. See you at the parties!
*Props to @desrosj, @4thhubbard, @annezazu, @griffbrad,@peterwilsoncc, and @jeffpaul for helping devise the new schedule, and @desrosj, @jeffpaul, and @sumitsingh for reviewing this post. *
The full chat log is available beginning here on Slack.
@mukesh27 also noted that resolving the sizes issue for the Gallery block would put the feature in a good position to be proposed for WordPress Core.
Our next chat will be held on Tuesday, May 5, 2026 at 16:00 UTC in the #core-performance channel in Slack.
#core-performance, #hosting, #performance, #performance-chat, #summary
X-comment from +make.wordpress.org/docs: Comment on WordPress Documentation Team Closes 200+ Issues — and Needs Your Help
The next WordPress Developers Chat will take place on Wednesday, April 22, 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 ticket 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 Path Forward for WordPress 7.0. A new release schedule should be shared this week.
New Dev Notes:
Roster of design tools per block (WordPress 7.0 edition)
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.
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.
Start of the meeting in Slack, facilitated by @amykamala Agenda post.
Please take a look at this Twenty Twenty-Seven: Team Announcement highlighting an emphasis on mentorship and creating an entry point for new contributors.
@annezazu has published Defining expectations for Iteration issues announcing some adjustments to iteration issue handling in the Gutenberg repo.
From @amykamala: “Finding the most current PRs and discussions can be a bit of a wild goose chase because while PRs mention tickets in their content, the fields/relationships on the right that would link PRs to a ticket, project, status, etc are not actively being used. For 7.0 theres a kan ban board but nothing in it because tickets and PRs are not being tagged. So the only way to find this info is to scroll endlessly on tickets and click on all the links in the notifications. Some of you may remember a while back I asked devs in here to please start tagging their PRs in the fields on the right.”
#core-program channel may be a good place to iterate on this topic.Matt is requesting community reps and organizers increase emphasis on Elevating Individuals in the contributor space to to celebrate volunteers and folks who contribute in their own spare time.
From @miroku: “I can only report problems; can that be considered a contribution? I’m always struggling to figure out how to volunteer effectively”. @jorbin answered that testing and finding bugs is absolutely a contribution!
@westonruter wanted to draw attention to this issue with @wordpress/core-abilities which makes it difficult to use outside of a React context. A PR is available to fix the issue.
One of the most common complaints from Contributor Day facilitators is this: participants spend the entire session trying to set up their local environment and never get to actually contribute.
Before writing a single line of code, a first-time WordPress core contributor typically needs to install Git, Node.js, npm, Docker, configure everything correctly, and troubleshoot whatever breaks along the way. At in-person events, this alone can take hours — sometimes the full day.
The WordPress Core Dev Environment Toolkit aims to eliminate this friction entirely.
The WordPress Core Dev Environment Toolkit is a desktop application (available for macOS, Windows, and Linux) that sets up a full WordPress core development environment with zero prerequisites.
You install it, choose a directory for wordpress-develop, click a button, and you have:
A cloned wordpress-develop repository
A running WordPress dev server
The ability to make code changes and generate a patch
No Git, no Node.js, no npm, no Docker needed. Everything is bundled inside the application as JS/WASM, powered by WordPress Playground.
Once installed, the app lets you:
Clone wordpress-develop into a directory of your choice
Run npm install, npm run build, and npm run dev automatically
Start a WordPress dev server using Playground’s CLI
Make changes to core files directly
Generate a patch from your changes, ready to attach to a Trac ticket
The entire toolchain — npm, Node, Git — runs as JavaScript/WASM bundled with the app. There’s no terminal work required for the basic contributor workflow.
Here’s the full setup flow — from a fresh install to a running WordPress development environment:
Video
Once your environment is running, generating a patch to submit to Trac takes just a few clicks:
Video
Environment setup has historically been one of the biggest drop-off points during Contributor Days. When participants can’t get set up in time, the session is over before it starts — regardless of their interest or motivation.
This tool makes it realistic to go from attendee to first patch in a single afternoon. It’s designed specifically for the Contributor Day context: fast setup, no prerequisites, no troubleshooting.
If you’re organizing or facilitating a core table at a WordCamp:
Share the download link with participants ahead of the event so they can install it at home on good WiFi (the app is a larger download).
Walk through the setup at the start of the session: install, click to set up the environment, make a small change, generate a patch.
Point participants to the Core Contributor Handbook for guidance on what to contribute and how once they’re set up.
GitHub repository and releases: https://github.com/WordPress/experimental-wp-dev-env
The tool is experimental and under active development. Feedback is welcome via GitHub issues.
If you use this tool at a Contributor Day, please share how it went — either in the comments below or in the #core channel on Slack. Reports from the field help prioritize improvements.
Props to @greenshady @desrosj @audrasjb for review
+make.wordpress.org/playground/ +make.wordpress.org/test/ +make.wordpress.org/community/
The next WordPress Developers Chat will take place on Wednesday, April 15, 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 ticket 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 release schedule is currently still on hold, pending further validation of a new release candidate.
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.
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.
Posting here since it spans +make.wordpress.org/design/ , +make.wordpress.org/community/ +make.wordpress.org/marketing/ +make.wordpress.org/meta/ .
My request: Let’s go back to how we used to elevate individual identity and contribution. Learn how to celebrate sponsorship in ways that encourage and cheer equally or more volunteers and people contributing in their spare time, and remember that’s how almost all of us started and how beautiful and fun that was.
To expand a bit on what I tried to say in the Q&A, I was referring to this tweet:
Krupa, sorry to use you as an example, but the giant SELF EMPLOYED on your badge shocked me, and led me down a path of thinking of all the ways my push to get companies doing what Automattic and Yoast has created some issues in its success, and the unintended consequences it’s maybe led us to.
I’m not saying someone deliberately created this bad badge design on purpose or maliciously, but I do want to know what led to a result here that everyone involved thought Name and Company was just fine, and no one advocated for personal info you could have on a badge, and that we have before in previous designs. I would suggest WEBSITE since we’re software trying to help people make websites, and want to encourage and promote that, then WordPress.org username, for same reason, maybe hometown because that’s usually one of the first things people ask and it’s interesting. I’d put all those things over the company, because the company for people who want to show it off is usually obvious from their shirt or buttons before you can read the badge.
@desrosj and @peterwilsoncc, Very sorry today for only being able to express disagreement in such a brief and unnuanced way. I’d love to get a Zoom when I’m feeling better so we can discuss and understand each other’s positions better.
Be a good conversationalist
I know I get annoyed when the first question someone asks when you meet is “what do you do for work?” Here are fun openers that are better, and how can that inspire how we experiment with badges.
Individual Complaints
I was first made aware of this issue by hearing complaints from core WP devs who said they feel like we doing so much more to recognize the contribution of companies. I’ve heard several versions of “it’s a bigger deal for me to contribute without being paid for it!”
Where else is this showing up?
Very much on the plugin and theme directories.
In the business model of WordCamps.
In a lot of our language and goals.
In my presentations starting probably 6-7 years ago.
We’re measuring and celebrating inputs and contributions, not impact or results
I keep repeating this as the biggest thing we need to change in the WordPress culture and way of doing things. In hindsight, how silly is it to emphasize hours pledged in Five for the Future and not actual activity? And then check regularly if that activity is actually aligned with our goals, or perhaps working against them? (It has happened!)
When is more contribution a bad thing? How has our emphasis on participation, process, or inclusive consensus slowed us down, even as we add more people? Are we surprised, given The Mythical Man-Month figured that out in 1975! What have we lost, and who have we lost, as a result of the structure and processes we’ve created?
How am I so smart yet so dumb sometimes?!
Here’s a better version. The most powerful question from Jerry Collona: “How have I been complicit in creating the conditions I say I don’t want?” It works so well in all parts of life.
“What’s new in 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 22.9?
Gutenberg 22.9 has been released and is available for download!
This release introduces background gradients that work alongside background images in the Group block, and adds organized sections to the command palette for better action discovery (experimental). The wordpress/ui package gains a foundational component for consistent empty states, while real-time collaboration receives stability improvements for multi-user editing sessions.
A total of 131 PRs were merged in Gutenberg 22.9, with 5 first-time contributors!
Table of contents
The Group block now supports background gradients through a new background.gradient block support, allowing gradients and background images to work together without conflicts. You’ll find a gradient picker in the Background panel that works independently of the existing color gradient controls, making it possible to create gradient overlays on images or combine multiple background effects.
The new background.gradient block support is available to block authors. This also lays the groundwork for eventually migrating color.gradient to background.gradient across all blocks, providing a more consistent and capable background styling system, including clipping and text gradients. (75859)
The command palette (Cmd+K/Ctrl+K) now features organized sections that make it easier to find and reuse actions. Instead of showing just a search field and search results, users see sections for Recent commands and Suggestions based on current context. This change is experimental; to give it a try, first go to WP-Admin > Gutenberg > Experiments and enable “Workflow Palette”.
The wordpress/ui package adds a new EmptyState component for displaying placeholder content when sections have no data. This compound component provides flexible composition with sub-components for icons, titles, descriptions, and actions, laying groundwork for consistent empty state patterns across the interface (74719).
Real-time collaboration has received some fixes that improve the multi-user editing experience and stability. Block comments (notes) now properly sync between collaborative editors instead of requiring page refreshes to appear. In the post list, the action button correctly updates from “Join” back to “Edit” when collaboration locks expire. Behind the scenes, error recovery has been enhanced to prevent cascading failures that could previously cause memory issues during collaborative sessions. (76873, 76795, 76872, 76716)
The experimental Forms block now supports hidden input fields, filling an important gap for many applications. Hidden fields appear as selectable placeholder blocks in the editor, while remaining invisible on the frontend with values configurable through the Advanced panel. (74131)
Add EmptyState component to wordpress/ui. (74719)
Admin UI: Update Page background color. (76548)
Button: hide focus outline on :Active for click feedback in forced-colors mode. (76833)
Card: Use Text component for Title typography. (76642)
InputControl: Add to wordpress/ui. (76653)
Snackbar: Use surface-width design token for max-width. (76592)
Storybook: Make “introduction” top level. (76671)
Tabs: Add runtime validation for tab/panel mismatches. (75170)
Theme: Change default control cursor to pointer. (76762)
ThemeProvider: Add cursor prop. (76410)
UI/Dialog: Deprioritize close icon for initial focus. (76910)
UI/Dialog: Expose initialFocus and finalFocus on Dialog.Popup. (76860)
UI: Add AlertDialog primitive. (76847)
UI: Update @base-ui/react from 1.2.0 to 1.3.0. (76603)
Block Supports: Add background gradient support that can combine with background images. (75859)
Forms Block: Add hidden input field variation. (74131)
Image/Site Logo: Hide crop toolbar when editMediaEntity is unavailable. (76626)
Login/out block: Add button block class names to the submit button. (76746)
CollapsibleCard: Add HeaderDescription subcomponent. (76867)
Improvements to dataviews infinite scroll. (74378)
Site Editor > Pages: Move view configuration to the server. (76573)
Site Editor > Patterns & Parts: Generate sidebar from view configuration. (76823)
Site Editor > Patterns: Move configuration to the server. (76734)
Site Editor > Quick Edit: Add form configuration to endpoint. (76953)
Site Editor > Templates: Move configuration to the server. (76622)
Icon: Fix center alignment in the editor for classic themes. (76878)
Image block media placeholder: Remove duotone. (76721)
Latest Comments: Fix v1 block deprecation. (76877)
List Item: Disable edit as HTML support. (76897)
Navigation: Avoid List View changing position when navigation block saves. (76659)
Reduce specificity of nav link default padding so global styles apply. (76876)
Show fallback label in MediaControl when filename is empty. (76888)
Site Tagline: Fix block error when migrating deprecated textAlign attribute. (76821)
Boot: Fix black area below content when sidebar is taller than page content. (76764)
Add Akismet as a default connector. (76828)
Align client registration API with server. (76737)
Fix button size. (76582)
Replace plugin.slug with plugin.file. (76909)
Support non-AI provider types and add JS extensibility end-to-end test. (76722)
Block visibility badge: Use canvas iframe for viewport detection. (76889)
Cross Origin Isolation: Remove img from the list of elements that get mutated. (76618)
Fix locked content when switching to a different template without exiting ‘Edit pattern’. (76710)
Hide Additional CSS controls when block is inside contentOnly editing mode. (76512)
Reset blockEditingModes on RESET_BLOCKS. (76529)
Stop keeping stale controlled blocks after reset. (76591)
Admin UI: Fix Page Header not rendering with only actions and add stories. (76695)
Button: Restore specificity of high-contrast mode focus ring. (76719)
Card: Add overflow: Clip to root container. (76678)
Fix Color Picker Angle Reset on Gradient Type Change. (76595)
Storybook: Disable autodocs for Icon library. (76620)
compose/useDialog: Add stopPropagation() to Escape handler. (76861)
ui/CollapsibleCard: Do not animate focus ring. (76682)
Fix: Create custom template modal content width. (76713)
Reduce the added halo for selected block. (76619)
Revisions: Add Meta fields diff panel to document sidebar. (76341)
Revisions: Fix template revisions retrieval and sorting. (76760)
Style Book: Fix missing styles for classic themes in stylebook route. (76843)
RTC: Fix notes not syncing between collaborative editors. (76873)
RTC: Fix stuck “Join” link in post list when lock expires. (76795)
RTC: Restore on failed request with compaction update. (76872)
Build: Remove unused JXL WASM module from vips worker. (76639)
Gate client-side media processing as plugin-only. (76700)
vips: Ensure single instance. (76780)
ComboboxControl: Fix accessible association of help text. (76761)
RadioControl: Add role=”radiogroup” to fieldset. (76745)
ToggleGroupControl: Fix accessible association of help text. (76740)
ControlWithError: Connect validation messages to controls via aria-describedby. (76742)
Fields: Add excerpt field. (76829)
Fields: Add sticky field. (76922)
Fields: Tweak excerpt field. (76903)
Add revisions panel. (76735)
Add template panel to include the existing template actions. (76539)
Abilities: Improve JSDoc for public API. (76824)
DOM: Document class wildcard matcher for ‘cleanNodeList’. (76920)
Docs: Remove Puppeteer references and update to Playwright. (76766)
Docs: Update PHP_CodeSniffer repository link and schema URL. (76816)
Storybook: Add redirect for moved introduction page. (76701)
Storybook: Try changing to collapsed folders. (76361)
UI Tooltip: Improve documentation to cover intended accessibility practices. (76705)
Updating versions in WordPress ahead of 7.0. (76723)
admin-ui: Update package README to clarify purpose and distinguish from ui package. (76943)
docs(create-block-interactive-template): Document available variants in README. (76831)
iAPI Docs: Add client-side navigation compatibility guide. (76242)
Core Abilities: Fix sideEffects flag. (76763)
Admin UI: Add CSS files to sideEffects array. (76609)
admin-ui / Breadcrumbs: Stricter items[].to prop types. (76493)
Refactor: Use null coalescing operator for improved readability. (76777)
element: Make createInterpolateElement TS/type smart. (71513)
Core Data: Optimize getRawEntityRecord selector. (76632)
Core Data: Remove ‘isRawAttribute’ internal util. (76806)
Navigation: Add a shared helper for font sizes in Navigation Link and Navigation Submenu blocks. (74855)
Tab Block: Remove anchor from save function. (76511)
Add TypeScript parser tests for shouldSkipReference. (76611)
ESLint: Add no-unmerged-classname rule. (76458)
create-block-interactive-template: Enhance block registration by using blocks-manifest for improved performance. (76317)
wp-build: Hash transformed CSS for data-wp-hash dedupe key. (76743)
Build: Fix vips worker 404 when SCRIPT_DEBUG is true. (76657)
Build: Skip non-minified build for WASM-inlined workers. (76615)
Changelog: Add missing label-to-feature mappings. (76646)
React vendor script: Avoid warning on createRoot. (76825)
Set milestone on PRs after cherry-picking to release branch. (76652)
react-dom vendor script: Remove __esModule flag. (76925)
Fix: Flaky RichText format end-to-end test. (76958)
RTC: Add end-to-end block gauntlet. (76849)
e2e: Add end-to-end tests for template and template part revisions. (76923)
end-to-end Tests: Enable client-side media processing for site editor image test. (76648)
The following PRs were merged by first-time contributors:
@jigangz: Block Library: Show fallback label in MediaControl when filename is empty. (76888)
@meravi: Docs: Remove Puppeteer references and update to Playwright. (76766)
@rodrigoprimo: Docs: Update PHP_CodeSniffer repository link and schema URL. (76816)
@sandipmaurya2611: Boot: Fix black area below content when sidebar is taller than page content. (76764)
@Vedant-Gandhi: Fix Color Picker Angle Reset on Gradient Type Change. (76595)
The following contributors merged PRs in this release:
@aaronrobertshaw @adamsilverstein @aduth @alecgeatches @andrewserong @annezazu @aswasif007 @carolinan @CGastrell @chriszarate @ciampo@DAreRodz @dhasilva @dsas @ellatrix @epeicher @gziolo @im3dabasia @ingeniumed @jameskoster @jasmussen @jigangz @jorgefilipecosta @jsnajdr@juanmaguitar @Mamaduka @manzoorwanijk @maxschmeling @meravi @mirka @ntsekouras @oandregal @pento @ramonjd @retrofox @rodrigoprimo@sandipmaurya2611 @scruffian @senadir @sgomes @Shekhar0109 @shekharnwagh @shimotmk @SirLouen @Soean @t-hamano @talldan@tellthemachines @Vedant-Gandhi
Two years ago, efforts were made to provide more clarity in the Gutenberg GitHub repository to make it simpler to keep up to date with work underway at various levels. This post focuses on a piece of that effort: iteration issues and the growing role they can play to make it simpler to follow ongoing work in the Gutenberg repository at critical periods. Iteration issues should happen alongside dev notes and merge proposals.
As a reminder, these iteration issues are solely for following dedicated tracks of work in the Gutenberg repository, and their goal isn’t to replace the Trac tickets that we use for tracking tasks.
For each release, open a new iteration issue with the [Type] Iteration label and a name similar to “Feature Name for WordPress X.X”. Do not re-use an iteration issue from a prior release.
Before the beta cycle for the release, updates need to happen at a minimum of once per month.
1 week ahead of beta and during beta/RC periods, updates need to happen weekly. In particular, emphasis should be put on updates ahead of beta 1, RC1, and the final release.
When the work on a release is done, close the iteration issue and open a new one for the next release as needed.
The aim in doing this is to make it easy for folks to stay up to date on features being worked on for major WordPress releases. Currently, pulling together accurate and up-to-date information remains too fragmented, partially due to either the lack of timely updates to Iteration issues or due to the lack of an iteration issue, leading to too few people who have the time/effort/expertise to sort through it all. This has led to confusion in the lead-up to key moments in the release cycle and is a vulnerability in the process that needs to be rectified. By contributors dedicating themselves more deeply to curating Iteration issues and keeping them up to date, that information can remain a shared resource for all in a consistent way and help us lean towards automation over the reliance of individuals to collate.
Most, if not all, headline items in roadmap posts need iteration issues. When in doubt, create one.
To help more folks succeed in creating a good iteration issue, there is a new Iteration issue template when creating an issue that follows these best practices:
Assigned contributors planning to work on it. As needed, this includes assigning someone to handle updates.
A scope of work tailored to the release and the timeline, with necessary issues opened.
Any necessary design input or clear requests for design collaboration.
Any open questions or known decisions should be clearly stated, with discussions branching out into various individual issues.
Regular updates in the form of comments on the issue. Specifically, monthly in early stages of the release and weekly at later stages aka starting 1 week before beta 1.
The iteration issue does not need to start this way, but it needs to grow in this direction rapidly as the release process continues. In many cases, an initial iteration issue is opened with a smaller set of known key items to work on, and broader contributors help shape it as the release gets underway.
A good update is timely and clearly states completed work, upcoming planned work, any known blockers or decisions to be made, and a broader sense of how the work is progressing. For example, an update that simply lists a changelog of items doesn’t provide a sense of whether work is continuing at the right pace for the release and what is likely to make it or likely not to.
Ahead of key moments in a release, beta 1 and RC 1 in particular, updates need to happen weekly as noted above and should include clear summaries of what is landing in each. These can be used as foundations for any future dev notes, merge proposals, release announcement material, or even documentation.
Just like these issues, this is an iteration too. Please share feedback, whether you’re handling these iteration issues or using them to stay closer to the work.
Props to @tyxla @desrosj @4thhubbard @jeffpaul for reviewing
Thank you to everyone who responded to the original call for volunteers. The response was genuinely wonderful and made clear how much folks care about getting a great default theme out for 7.2. Joining lead designer @iamarinoh, I’m happy to share that @onemaggie and @poena will serve as co-lead developers. @juanfra will be taking on a new role as lead mentor and I want to share a bit about why that role exists.
Those who read through the comments may have noticed @juanfra mentioning his interest in mentoring and sharing his Twenty Twenty-Five experience with new leads. That interest sparked a larger conversation about how to bring a more explicit mentorship focus to this new default theme effort. With a head start on this theme compared to previous years, and with an increasing focus on Education programs in WordPress to help new contributors find meaningful entry points, there’s a real opportunity to do something more intentional here than before. Theme development is one of the more approachable and impactful areas to get involved in. As a result, the explicit mentorship angle is designed to bring more folks into the theme creation process in a structured, supported way rather than hoping people find their footing on their own. @juanfra will be taking point here but everyone working on the theme in a lead role will help make the mentorship approach a reality.
This goes beyond helping make Twenty Twenty-Seven a reality. It’s about expanding who feels equipped and welcome to contribute to theme work in WordPress more broadly.
If you expressed interest and are keen to contribute, stay tuned as the mentorship angle itself is forming alongside the theme design. More on how to get involved will be shared as the theme takes shape.
Thanks to @onemaggie @poena @juanfra @iamarinoh for reviewing this post and for stepping up to lead here.
Start of the meeting in Slack, facilitated by @audrasjb Agenda post.
trunk is closed to commits for the 7.1 release until further notice
Backporting to 7.0 still requires double committer sign off
Pre-releases are paused
The next release will be a RC
We’re currently in string freeze
New Dev Notes:
Building a custom sync provider for real-time collaboration
From @desrosj: contributors who have a list of notes for tickets to create are encouraged to create them before the WordCamp Asia Contributor Day. Especially if they are good-first-bugs!
@desrosj added: “If someone has some time, triaging the good-first-bug list could also be helpful. Sometimes that list is intimidating because it seems like everything is attended to. But often times the patches need to be refreshed or the approaches so far are not fully solving the issue at hand. If we could note that on the tickets, it may make them more easily actionable.”
@audrasjb noted that the 8 tickets in the i18n component for 7.0 are easy tickets that would be nice to address during the contributor day. They are also Polyglots, Core, and Core Editor cross-team tickets.
@desrosj will encourage our Polyglots contributors to open tickets for strings that need refinement and additional context as it is a great way to contribute to the upcoming release.
The next WordPress Developers Chat will take place on Wednesday, April 8, 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 ticket 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.
New Dev Notes:
Building a custom sync provider for real-time collaboration
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.
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.
Start of the meeting in Slack, facilitated by @audrasjb Agenda post.
Extending the 7.0 Cycle This item will of course have an impact on the release party initially scheduled to happen during WC Asia Contributor Day, which will probably more be focused on testing.
New Dev Notes:
Introducing the AI Client in WordPress 7.0
From Matt: Rethinking Left Navigation
@audrasjb: “Ordering plugins in a menu is a pretty sensible [but] it would be great if users could order them themselves”
@jorbin recommended to make it a Feature Plugin project
@joedolson wanted to note that maintaining consistent navigation order is an explicit accessibility requirement
From @joefusco: “Following the awareness/presence discussion in #64696, I built a feature plugin to test the workload independently from RTC feature.”
From @wildworks: “I am proposing to remove the ability to embed YouTube videos in the cover block. I would appreciate your thoughts on this. In my opinion, this violates the terms of service and also presents accessibility issues.” See this PR comment.
@jorbin pointed out that WordPress has shipped with header video support for almost a decade with no complaints, so removing this from the cover block should not be rushed.
@joedolson added that the accessibility issue is technically a content control issue; it doesn’t directly create an issue, but opens a door for significant issues that were previously easily prevented.
@wildworks shared this Slack thread, where comments are welcome about this topic.
It was announced earlier this week that the final 7.0 release has been delayed specifically to allow more time to address testing feedback about the implementation of real-time collaboration. While the broad reasons for the delay were shared, this post will clarify what the delay means in practice (“returning to beta” after entering the Release Candidate phase of a release is unprecedented), and how to handle some specific technical details. Having clear guidance helps to direct attention to the right areas and ensures that the delay is as minimal as necessary.
This post outlines the policies dictating what can move forward, and the processes that should be followed until further notice to best focus community efforts while promoting stability and the ability to remain nimble.
To help Core committers understand what types of commits are allowed during this pause, the following policies are now (or continue to be) in place:
For non-Committer contributors, this section may help explain why Core committers make certain decisions.
trunkTo avoid the potential for merge conflicts while backporting and other complexities, trunk** is closed to commits for the 7.1 release until further notice**.
Backporting commits** will continue to require double sign-off by two core committers.** The commit dev-feedback keywords should be used to request a second committer’s review, and dev-reviewed should be added to indicate a second committer has reviewed and approved performing the merge to the 7.0 branch.
The typical rules followed during the Release Candidate phase of the release cycle will remain in effect:
No new features or enhancements are allowed.
Only fixes for bugs introduced during the current release cycle are allowed.
Built/Test Tool and/or test coverage improvements are allowed at any time.
Features can be removed if they are deemed particularly risky, unstable, or new testing data surfaces previously undiscovered issues.
Note: These restrictions also apply to the wp/7.0 branch in the Gutenberg repository, which is used to merge changes targeted for the 7.0 release into wordpress-develop.
The primary exceptions to the rules above are any changes related to the stability of real-time collaboration (see #64696, #64904, #64890, #65008, #64622 and this board on GitHub), and any improvements necessary to refine the experience of the new Connectors admin screen (see #64960 and #64789).
To allow everyone a chance to regroup and properly identify the outstanding issues and discuss how best to address them, additional pre-release versions of WordPress 7.0 will be paused through April 17th.
Enough of the surrounding context about the work remaining will be better understood by then. The release squad and project leadership can then develop a new, well informed schedule for the 7.0 final stretch, which will be published no later than April 22nd.
Following standard procedures during a major version release cycle, the nightly releases are now being generated from the 7.0 branch. During this pause, **it is recommended that you perform testing using the **latest nighty build.
The easiest way to accomplish this is by installing and activating the WordPress Beta Tester plugin on a test site and selecting the “Bleeding edge” channel and “Nightlies” stream.
While the nature of the pause suggests that the release is returning to the beta phase, truly returning to beta releases from a version string perspective is challenging due to a number of technical limitations. Mainly, version_compare() will not recognize 7.0-beta7 as newer than 7.0-RC2.
After considering a number of ways to approach the situation and discussing with contributors, I’ve concluded that the best option seems to be continuing releases in the expected numerical order (RCX+1). This is a bit unorthodox because RC3 and likely RC4 will be represented as Release Candidates by version string despite being considered a beta release in practice. But it’s the most technically sound option to ensure minimal confusion around which version to test, and that sites continue to update as expected when future versions are published.
Each release post must clearly mention this nuance with clear testing instructions and guidance to avoid confusion.
Given that new releases are paused until April 17th, there is a bit more time to consider other options if new data or rationale is presented before then.
To avoid creating new work for Polyglots contributors, new strings should be avoided as much as possible. Exceptions can be made for critical strings (the About page or real-time collaboration, for example) provided they are properly tagged with the i18n-change keyword in Trac and the Polyglot team is made aware. Existing strings can be removed and/or duplicated as necessary.
If a specific and compelling scenario comes up that makes clear adjustments to the above policies are required, please note them in the comments below for discussion and consideration. This post will be updated as changes to these policies are deemed necessary with each change clearly noted at the top. Additionally, changes will be announced in #core on Slack and noted in each next Dev Chat agenda.
Props @peterwilsoncc, @matveb, @annezazu, and @jorbin for peer review.