What’s new in Gutenberg 22.7? (11 March)

“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.

Image

Gutenberg 22.7 has been released and is available for download!

Table of contents

New Connectors Screen and 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.

We have added a new “Connectors” adminadmin (and super admin) page under Settings > Connectors, which allows users to see and manage their connectors. We using an OpenAI connector demonstration as the first example, and we’ve also provided extension 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. for plugins to add their own connectors. These screens are still in an experimental state. (75833, 75948, 76014)

Image

Previews for style variation transforms

Style variation transforms now display a preview in the editor. This makes it easier to see the impact of transformations before committing to the change.

Image

Style variations are now also available for patterns in contentOnly mode. (75889, 75761)

Improved Visualizer responsiveness in Grid 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.

The Grid block Visualizer is now synchronized quickly and accurately with the selected number of columns:

Image

This makes it easier and quicker to build grid based layouts. (75820)

Playlist block now has a visualizer

We added WaveForm Player as a visualizer to the Playlist block. This gives users a visual representation of the audio file they are listening to, and opens the door to more designs for the block:

Image

Please note that this block is still in an experimental state. (75203).

Other Notable Highlights

  • Content Guidelines: We added a new experimental 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/. and custom post typeCustom Post Type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept., to allow WordPress site owners to define and manage site-wide content rules (75164, 76187, 75420, 76155)
  • wp-env: We added phpMyAdmin support to the wp-env Playground runtime and introduced a new phpmyadmin boolean configuration option for cleaner enable/disable control. (75532)
  • Components: We added word-break: break-word to buttons to fix buttons with very long text (76071)
  • Custom CSSCSS Cascading Style Sheets.: We now allow defining custom selector for CSS selectors in 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., which means that Global Styles can be applied to elements within the block. (75799)
  • Media Library: Optimise image loading for the media thumbnail field for better performance (75811)
  • Real Time Collaboration: Real Time Collaboration is now enabledf by default (75739)

Changelog

Enhancements

  • Add phpMyAdmin support to wp-env Playground runtime. (75532)
  • Dialog: Add legacy z-index compatibility. (75874)
  • Env: Improve help screen. (75783)
  • InputLayout: Replace slot context with data attributes. (76011)
  • Theme: Add design token fallback generation. (75586)
  • Theme: Add design token for interactive non-link elements. (75697)
  • UIUI User interface: Add Notice component. (75981)
  • Views: Add support for more overrides (all developer-defined config). (75971)

Block Library

  • Button: Migrate to width block support. (74242)
  • Make inspector style transform previews consistent with toolbar transforms. (75989)
  • Playlist Block: Add WaveformPlayer visualization. (75203)
  • Post Navigation Link : Migrate to Text-Align Block Support. (75557)
  • Post Title : Migrate to Text-Align Block Support. (75629)
  • Post Title: Add placeholder attribute. (76016)
  • Query Title: Migrate to Text-Align Block Support. (75802)
  • Site Tagline : Migrate to Text-Align Block Support. (75690)
  • Site Title : Migrate to Text-Align Block Support. (75551)
  • Tabs: Remove custom state styling. (75731)
  • Unify block settings dropdown menu items across list views. (75979)

Connectors

  • Add: Connectors screen and API. (75833)
  • Connectors: Add _ai_ prefix to connector setting names. (75948)
  • Connectors: Dynamically register providers from WP AI Client registry. (76014)
  • Sync connector PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher behavior with CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. changes. (75968)

Content Guidelines

  • Content Guidelines: Add block guidelines management (76187)
  • Content Guidelines: Add UXUX User experience for site, copy, image, and additional guidelines (75420)
  • Guidelines: Add actions for Import, Export and 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. of guidelines (76155)

DataViews

  • Adjust column spacing in table layout when no titleField is provided. (75410)
  • Improve UI in list layout when we render only title and/or media fields. (76042)
  • MediaEdit: Auto-fill columns based on minimum item width. (75509)
  • DataViews: Remove menu divider again. (75893)
  • DataViews: Minimize padding for primary action buttons. (75721)

Post Editor

  • Center navigation preview content in preview pane. (75741)
  • RTC: Add session activity notifications. (76065)

Block Editor

  • Add previews for style variation transforms. (75889)
  • Try enabling style variation transforms for blocks in contentOnly mode. (75761)

Site Editor

  • QuickEdit: Rename status label and remove extra labels in popup. (75824)

Components

  • Refactor ColorPicker to preserve hue/saturation at achromatic colors. (75493)
  • ToggleGroupControl: Make unselected item color consistent across all variants. (75737)

Global Styles

  • Block Supports: Define CSS vars for blocks based on feature selectors. (75226)

Bug Fixes

  • Block editor: Force LTR direction in block HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. editing mode. (75904)
  • Connectors: Avoid manual string concatenation. (75997)
  • Connectors: Unhook Core callbacks in Gutenberg coexistence. (75935)
  • DataViews: Fix search input losing characters during debounce when externally synced. (75810)
  • Fix DataForm card summary vertical alignment. (75864)
  • Fix: Set quality and strip metadata in client-side image resize. (76029)
  • Fix: Suppress spinner output when using –json flag in wp-env. (75743)
  • IconButton: Hide tooltip when truly disabled. (75754)
  • Prevent non-reproducible Sass/CSS builds. (76098)
  • Remove Core’s full-page render interceptors for boot-based pages. (76036)
  • Theme: Add build plugins to inject design token fallbacks. (75589)
  • Theme: Remove global design tokens stylesheet. (75879)
  • wp-build: Deregister script modules before re-registering. (75909)
  • CI: Don’t build release notes during 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. build workflow for WP Core sync (76398)

Collaboration

  • Fix change-detection and new-post end-to-end tests after RTC enabled by default. (75751)
  • RTC: Back off when the window loses focus. (75843)
  • RTC: Bugfix: Fix casing of getPersistedCRDTDoc. (75922)
  • RTC: Fix fallthrough for sync update switch statement. (76060)
  • RTC: Fix stale CRDT document persisted on save. (75975)
  • RTC: Fix syncing of emoji / surrogate pairs. (76049)
  • RTC: Fix undefined array_first() call in sync storage. (75869)
  • RTC: Prevent duplicate poll cycles. (76059)
  • Real-time collaboration: Fix disconnect dialog on navigate. (75886)
  • Real-time collaboration: Improve collaboration within the same rich text. (75703)
  • Real-time collaboration: Remove ghost awareness state explicitly when refreshing. (75883)
  • [Real-time Collaboration] Fix sync issue on refresh. (76017)
  • Real-time collaboration: Improve disconnect dialog. (75970)
  • RTC: Enable RTC by default (75739)

Block Library

  • Block Support: Fix custom CSS not saved when style schema is not defined. (75797)
  • Fix: Page List block: Editor-only div inside page links causes misalignment in Firefox. (75890)
  • Fixes keyboard focus escaping the lightbox overlay when navigating a gallery with Tab/Shift+Tab. (75852)
  • Image block: Fix lightbox srcset size. (76092)
  • Image: Hide ‘Set as featured imageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts.’ for in-editor revisions. (76123)
  • Navigation Link: Compare internal links by host instead of origin. (76015)
  • Navigation Overlay Close: Set Close as default text, rather than using a placeholder. (75692)
  • Navigation editing: Simplify edit/view buttons. (75819)
  • Search block: Double-encodes apostrophes in the input value. (76023)
  • Show transform dropdown previews on focus as well as hover. (75940)
  • Use homeUrl instead of siteUrl for link badge evaluations. (75978)
  • Navigation overlay: Prevent duplicate area registration. (75906)

Block Editor

  • Avoid block removal when calling ‘moveBlockToPosition’. (75728)
  • Block toolbar and context menu: Hide pattern actions in Revisions UI. (76066)
  • Block toolbar: Hide styles dropdown for content only blocks inside unsynced patterns in Revisions UI. (76119)
  • BlockListBlock: Fix crash when selectedProps are null. (75826)
  • Grid block: Improve Visualizer responsiveness. (75820)
  • 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. block selected style. (75796)
  • PHP-only Blocks: Reflect bound attribute values in inspector controls. (76040)
  • Pattern Editing: Fix sibling blocks to edited pattern not being disabled. (75994)
  • RichText: useAnchor: Fix TypeError in virtual element. (75900)

DataViews

  • DataForm: Fix focus loss and refactor Card layout. (75689)
  • DataForm: Fix label colors. (75730)
  • DataForm: Fix text overflow for long unhyphenated text in panel layout. (76073)
  • Fix 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. toggle flickering when there are locked or primary filters. (75913)
  • Fix focus transfer while searching in list layout. (75999)
  • Fix spacing for title in patterns page. (75693)

Post Editor

  • Admin UI: Fix type mismatch between Page title and NavigableRegion ariaLabel. (75899)
  • Editor: Remove View dropdown and pinned items from revisions headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.. (75951)
  • Fix: Template revisions infinite spinner. (75953)
  • Preserve note selection on browser tab switch. (75955)
  • Real-time collaboration: Fix style mounting in RTC overlay. (75700)

Components

  • DateTimePicker: Fix day text wrapping. (76084)
  • Specify line-height to avoid inheriting default values. (75880)
  • Button: Add word-break: Break-word. (76071)

Site Editor

  • DataForm: Fix field label for panel (should not be uppercase). (75944)
  • DataViews: Avoid flickering while refreshing. (74572)
  • DataViews: Right-align integer and number fields. (75917)

Media

  • Media Notices: Bump global snackbar z-index, re-use global notices for media modal. (76063)

Global Styles

  • Custom CSS: Allow defining custom selector for this global styles feature. (75799)
  • Custom CSS: Prevent duplicate custom css styles. (75892)

Client Side Media

  • Fix: Skip scaled image sideload for images below big image threshold. (75990)
  • Client-side media processing: Try plumbing invalidation to the block-editor’s mediaUpload onSuccess callback (76173)
  • Client-side media processing: only use media upload provider when not in preview mode (76124)

Font Library

  • Fix: Use the same context for font library tabs translations. (75930)

Interactivity API

  • Interactivity Router: Fix back and forward navigation after refresh. (75927)
  • Interactivity: Fix crypto.randomUUID crash in non-secure contexts (76151)

Patterns

  • Unsynced patterns: Rename ‘Disconnect pattern’ to ‘Detach pattern’ in context menu. (75807)

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)

Block Editor

  • Fix writing flow navigation for annotation style, or any other block with border radius. (76072)

DataViews

  • DataForm: Fix card layout’s toggle button screen reader text. (76039)

Block Library

  • Accordion: Remove Down Arrow, Up Arrow, Home, End navigation. (75891)

Performance

Block Library

  • Navigation: Remove internal ‘useNavigationEntities’ hook. (75943)

Media

  • Media Thumbnail Field: Optimise image loading. (75811)

Experiments

Post Editor

  • RTC: Disable multiple collaborators if metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes are present. (75939)

Content Guidelines

  • Add experimental REST API and custom post type. (75164)

Documentation

  • Add core/icon block to theme.json schema. (75813)
  • Add documentation for contentRole and listView block supports. (75903)
  • Docs: Correct parameter name $content for query title render function. (75945)
  • Docs: Fix broken link to autoRegister block-supports. (75956)
  • Docs: Fix incorrect echo of wp_interactivity_state() in getServerState() example. (75857)
  • Icon: Improve parameter documentation. (75768)
  • Update README for DataViews, DataForm, Field API. (75881)
  • iAPI Docs: Add client-side navigation guide under “Core Concepts”. (75263)
  • iAPI Docs: Introduce reactive vs non-reactive distinction early in the state/context guide. (75357)
  • ui guidelines: Add custom properties and disabled state guidance. (75912)

Code Quality

  • Add wp_ prefix to real time collaberation option. (75837)
  • Backport Changelog: Move changelog for #75226 to WP 7.1 folder. (76102)
  • Core Data: Simplify actions dispatched by ‘canUser’ resolver. (75974)
  • ESLint: Add no-ds-tokens rule. (75872)
  • ESLint: Broaden no-unknown-ds-tokens to all strings and catch dynamic construction. (75905)
  • Field, Fieldset: Add tests for the Details component. (75696)
  • Interactivity: Fix incomplete Window.scheduler type causing TS2430 in downstream projects. (76070)
  • UI: Update @base-ui/react from 1.0.0 to 1.2.0. (75698)

Collaboration

  • RTC: Add debug logging to SyncManager. (75924)
  • RTC: Merge document meta map into state map. (75830)
  • RTC: Move WordPress meta key from sync package to core-data. (75846)
  • RTC: Updates from backport PR. (75711)

Components

  • Convert focus on mount hook to TypeScript. (75442)
  • NumberControl: Merge two state reducers into one. (75822)
  • ToolsPanel: Remove unnecessary label prop from dropdownMenuProps type. (76027)

Block Library

  • Cover: Replace strpos() with str_contains() for improved readability. (75907)
  • Navigation: Extract NavigationLinkUI and NavigationListViewHeader into separate files. (75865)
  • Post featured image: Simplify background class assignment. (75745)

Block Editor

  • Extract inserter-toggle mixin from duplicated button styles. (76087)
  • RichText: useAnchor: Enable type checking, fix errors. (75910)

DataViews

  • Remove unused deps: WordPress/dom, wordpress/theme, wordpress/url. (76075)

Post Editor

  • Fix flaky template-revert end-to-end tests. (75894)

Patterns

  • Add end-to-end test for sorting patterns. (75823)

Tools

  • Project Management: Add components team as codeowners for components package. (75641)

Testing

  • Automated Testing: Merge reports into HTML artifact. (75633)
  • Cover block: Add end-to-end test coverage for bugfixes. (75483)
  • Fix flaky Quick Edit end-to-end test. (75714)
  • Re-enable Font Library end-to-end tests. (75712)
  • Real-time collaboration: Expand mergeCrdtBlocks() automated testing. (75923)
  • Skip cross origin isolation end-to-end tests. (75764)
  • Try fix failing patterns end-to-end test. (75759)
  • Workflows: Use pull_request_target for cherry-pick workflow. (75775)
  • wp-env: Enable pretty permalinks by default in Docker runtime. (75688)

Build Tooling

  • Build: Clean top-level build/ directory during clean:Packages. (75961)
  • ESLint: Add no-i18ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.-in-save rule. (75617)
  • Prevent CSS modules in build from breaking Jest tests. (75792)
  • Sort registry files by handle/ID. (75755)
  • wp-build: Do not remove Core’s default script modules registration. (75705)

First-time contributors

The following PRs were merged by first-time contributors:

  • @aagam-shah: Content Guidelines: Add experimental REST API and custom post type. (75164)
  • @dlind1: Fix: Use the same context for font library tabs translations. (75930)
  • @namankhare: Fixes keyboard focus escaping the lightbox overlay when navigating a gallery with Tab/Shift+Tab. (75852)

Contributors

The following contributors merged PRs in this release:

@aagam-shah @aaronrobertshaw @adamsilverstein @aduth @alecgeatches @andrewserong @aswasif007 @chriszarate @ciampo @DAreRodz @desrosj @dhasilva @dlind1 @ellatrix @fushar @gziolo @iamchughmayank @im3dabasia @ingeniumed @jasmussen @jeherve @jeryj @jorgefilipecosta @JosVelasco @jsnajdr @luisherranz @Mamaduka @manzoorwanijk @maxschmeling @Mayank-Tripathi32 @mcsf @mikachan @mikejolley @mirka @Mustafabharmal @namankhare @ntsekouras @oandregal @ockham @peterwilsoncc @prasadkarmalkar @ramonjd @scruffian @sgomes @shail-mehta @shekharnwagh @Soean @stokesman @t-hamano @talldan @tellthemachines @xristos3490 @youknowriad

Dev Chat Agenda – March 11, 2026

The next WordPress Developers Chat will take place on Wednesday, March 11, 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 📢

WordPress 7.0 Updates

  • 7.0 Beta 3
  • 6.9.3 and silent Beta 4 release
  • 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. 5 scheduled for Thursday, March 12th, at 15:00 UTC
  • New Dev Notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.:

General

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.

Props to @chaion07 and @mosescursor for proofreading and review.

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

Performance Chat Summary: 10 March 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 ticketticket Created for both bug reports and feature development on the bug tracker. #64823, which was filed as a companion to various 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/ issues related to fetchpriority=high being added incorrectly to IMG tags hidden in blocks. A coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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. is needed to both backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. the changes from Gutenberg and make additional refinements to the wp_get_loading_optimization_attributes() and wp_maybe_add_fetchpriority_high_attr() functions to handle the new core use of fetchpriority=auto and fetchpriority=low.
    • PR #11196 is ready for review. @mukesh27 has started reviewing it, and @westonruter shared that it would benefit from additional Performance team review.

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)

  • @westonruter shared that there hasn’t been any feedback from users on the proposal to sunset Web Worker Offloading, even though there were apparently 6000+ updates to the version that includes the inline warning notice about the intended sunset. @westonruter speculated that it could be because users haven’t seen it yet or they don’t care.

    Open Floor

    • @westonruter shared about traveling for the next two weeks, so joining the next two meetings will not be possible.

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

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

      Real-Time Collaboration in the Block Editor

      Real-time collaboration (RTC) in 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 allows multiple users to edit content simultaneously by utilizing Yjs.

      This dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. covers three important aspects of the collaboration system that 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 theme developers should be aware of:

      • How metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes affect collaboration mode
      • The sync.providers 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. for customized sync transport
      • Common issues when building plugins that can run in a collaborative environment

      Collaboration is disabled when meta boxes are present

      The Problem

      Classic WordPress meta boxes are not synced by the real-time collaboration system. To avoid data loss, collaboration is disabled when meta boxes are detected on a post.

      Locked post modal when someone takes over a post
      Locked post modal when trying to take over a post

      What developers need to know

      To allow collaboration, consider migrating meta box functionality to registered post meta with show_in_rest set to true, and use 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. plugins or block-based alternatives that read from WordPress data stores.

      For example:

      register_post_meta( 'post', 'example_subtitle', [
      	'show_in_rest' => true, // Required for syncing.  
      	'single' => true,  
      	'type' => 'string',
      	'revisions_enabled' => true, // Recommended to track via revision history.
      ] );
      

      For more details on migrating from meta boxes, see the Meta Boxes guide in the Block Editor Handbook.


      The sync.providers filter: Customizing the sync transport layer

      Overview

      The @wordpress/sync package uses a provider-based architecture for syncing collaborative editing data. By default, WordPress ships with an 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 provider. The sync.providers filter allows plugins to replace or extend the transport layer. For example, a plugin could switch from HTTP polling to WebSockets for lower-latency collaboration.


      How it works

      The filter is applied during provider initialization:

      const filteredProviderCreators = applyFilters(
      'sync.providers',
      getDefaultProviderCreators() // array of provider creators
      );
      

      A provider creator is a function that accepts a ProviderCreatorOptions object (containing the Yjs ydoc, awareness, objectType, and objectId) and returns a ProviderCreatorResult with destroy and on methods. The destroy method is called when the provider is no longer needed, and the on method allows the editor to listen for connection status events (connecting, connected, disconnected).


      Example: WebSocket provider

      The following example replaces the default HTTP polling provider with a WebSocket-based transport using the y-websocket library:

      import { addFilter } from '@wordpress/hooks';
      import { WebsocketProvider } from 'y-websocket';
      
      /**
       * Create a WebSocket provider that connects a Yjs document
       * to a WebSocket server for real-time syncing.
       */
      function createWebSocketProvider( { awareness, objectType, objectId, ydoc } ) {
      	const roomName = `${ objectType }-${ objectId ?? 'collection' }`;
      	const serverUrl = 'wss://example.com/';
      
      	const provider = new WebsocketProvider(
      		serverUrl,
      		roomName,
      		ydoc,
      		{ awareness }
      	);
      
      	return {
      		destroy: () => {
      			provider.destroy();
      		},
      		on: ( eventName, callback ) => {
      			provider.on( eventName, callback );
      		},
      	};
      }
      
      addFilter( 'sync.providers', 'my-plugin/websocket-provider', () => {
      	return [ createWebSocketProvider ];
      } );
      


      What developers need to know

      • The sync.providers filter is only applied when real-time collaboration is enabled.
      • Return an empty array to disable collaboration entirely.
      • Return a custom array to replace the default HTTP polling provider with your own transport (e.g., WebSockets, WebRTC).

      Common issues when building plugins compatible with real-time collaboration

      When real-time collaboration is active, all connected editors share the same underlying data state via Yjs. Plugins that interact with post data, especially custom post meta, need to follow certain patterns to avoid sync issues

      Syncing custom post meta values

      In addition to being registered, custom meta field UIUI User interface must be consumed from the WordPress data store and passed to controlled input components.
      Always derive the input value directly from the WordPress data store via useSelect. In addition, use value instead of defaultValue on input components so the input always reflects the current data store state.

      const metaValue = useSelect(
      	select => select( 'core/editor' ).getEditedPostAttribute( 'meta' )?.example_subtitle,
      	[]
      );
      
      <input
      	value={ metaValue || '' }
      	onChange={ event => {
      		editPost( { meta: { example_subtitle: event.target.value } } );
      	} }
      />
      

      Avoiding local component state for shared data

      When building a plugin UI that reads from the WordPress data store, avoid copying that data into local ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. state with useState. This applies to any shared data, such as post meta or block attributes. Doing so disconnects your component from the shared collaborative state: updates from other clients will update the store, but your component won’t reflect them after the initial render, leading to stale or conflicting data.

      Blocks with side effects on insertion

      Custom blocks that trigger side effects on insertion will trigger that side effect for all connected collaborators, since block content syncs immediately upon insertion.

      For example, instead of auto-opening a modal when a block is inserted, show a placeholder with a button that opens the modal on click. This ensures side effects are intentional and local to the user taking the action.


      Credits

      Props @czarate, @alecgeatches, @maxschmeling, @paulkevan, and @shekharwagh for building real-time collaboration in the block editor alongside @ingeniumed, and for technical review and proofreading of this dev note.

      Parts of this work are derived from contributions made by @dmonad in this PR, and utilizes his Yjs library.

      Props to @wildworks and @tyxla for proofreading this dev note.

      #dev-notes, #dev-notes-7-0, #7-0

      Call For Feedback: Increasing Value of Release Party Testing Phase

      Every WordPress release party includes a phase dedicated to community testing. Contributors from around the world come together synchronously, run through a set of testing scenarios, and report the results in the #core 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/. channel. It’s a great tradition and one of the most accessible ways to contribute to a WordPress release.

      But as the process has evolved and the project has scaled over the years, some repeating pain points have become clear that are worth addressing. With WordPress 7.0 set to be released during Contributor Day at WordCamp Asia on April 9th, there’s a valuable opportunity to experiment with a large group of contributors in the same room. This feels like the right moment to ask the community for ideas.

      This post is a call for feedback aimed at improving how release party testing works, both for those participating synchronously on release day and for contributors who want to keep testing after the party concludes.

      What Makes Release Party Testing Great

      Before getting into the areas to improve, it’s worth acknowledging why this part of the release process matters and what it gets right.

      Release party testing is one of the easiest ways to get involved as a contributor. You only need to know how to update a WordPress site and run through a few basic scenarios that are outlined in the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Handbook. There’s no deep technical knowledge required. That low barrier to entry is not something to be sacrificed in pursuit of more structured or rigorous testing. Lowering barriers to contribution is one of the most important things an open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project can do, and any changes made here should make the process more approachable, not more intimidating.

      With that in mind, here are some of the areas where there’s room to improve.

      Current Pain Points

      The channel can become difficult to follow

      During the testing phase, the #core channel fills up quickly. For contributors whose first language isn’t English, a fast-moving channel can be especially overwhelming. And when off-topic messages or late test reports get mixed in, it becomes that much harder for everyone to keep up with what matters.

      Testing scenarios lack release-specific context

      A list of common scenarios to test is always shared. While these are frequently improved and are helpful as a starting point, they tend to be fairly generic (“test creating a new post”), without any guidance on what specifically changed in this release that a tester should be looking for or confirming. Without that context, it’s harder for testers to know where to focus their attention or what a successful test actually looks like for a given release.

      It’s not always clear what was tested or how

      Testing reports typically include details like installation type, method of updating, version of WP being updated from, PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher version, which is all useful. But there’s often less clarity about how specific things were tested. What steps did the tester follow? What browser were they using? Were they testing as an adminadmin (and super admin), an editor, or a subscriber? That level of detail can matter a lot when trying to triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. or reproduce a reported issue.

      It’s hard to gauge the overall coverage of testing

      When it’s unclear how many contributors are actively running through scenarios versus following along, it’s difficult to know how thoroughly the release has been tested. Without that visibility, it’s hard to identify gaps in coverage or know which environments and workflows still need attention.

      Testing reports continue after the testing phase ends

      The emcee running the release process announces when the testing portion has concluded and asks that only failures be reported going forward. Despite this, testing reports continue to come in, which disrupts the coordination work that follows. This is a process and communication challenge as much as anything, but it’s worth addressing directly.

      There’s no clear path forward after the party ends

      This is probably the most significant gap for contributors. Once the release party concludes, all of the testing feedback that was shared becomes another message buried within the Slack archives. There’s no clean summary of what was tested, what was found, and what still needs attention. And there’s no obvious next step for contributors who want to keep testing the release after it ships.

      Testing shouldn’t stop at the release party. Every new major version of WordPress deserves continued testing across a broader range of environments, configurations, and workflows than any single party can cover.

      Goals

      With all of that in mind, here’s what improvements to this process should aim to accomplish:

      • Make better use of everyone’s valuable time. Contributors are generous in showing up for release parties. The process should respect that.
      • Test more scenarios that are relevant to a given release. Testers should know what changed and what to look for, not just what to click.
      • Keep the release process on track. When off-topic messages or late test reports flood the channel, critical information can get lost at exactly the wrong moment.
      • Make it more clear exactly what was tested and how. Structured reporting, even in a lightweight form, leads to more actionable results.
      • Provide contributors with a clear path to continue contributing. The release party should be a starting point, not the end of the road.
      • Connect release party testing to the broader testing cycle. Pre-release calls for testing cover a lot of ground, and the party should build on that work rather than exist in isolation from it.
      • Leverage tools that contributors already know and use. Building on existing and familiar tools, such as Playground and the Test Reports plugin, reduces friction, helps standardize the process, and creates a more consistent experience.

      None of these goals should come at the cost of making testing harder to participate in as that’s not a compromise worth making.

      An Opportunity at WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Asia

      WordPress 7.0 is planned to be released during Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. at WordCamp Asia on April 9th. Having a large group of contributors physically present in the same room is a genuinely rare opportunity. Experiments that are difficult to run when 100% of participants are distributed become a lot more practical when a meaningful portion of the group is co-located. That makes the 7.0 release party an ideal time to create a plan and try out something new.

      Summary

      This post is an open call for any ideas. There’s no one perfect answer or solution, and it may take several releases to find what works best. What adjustments should be made to the testing phase of a release party? Are there practices from other open source projects or testing communities worth borrowing from?

      Conversation Starters

      Here are a few rough ideas to get the conversation started:

      • A “How to Test During a Release Party” course on Learn WordPress: A short course or guide on Learn WordPress that walks first-time participants through what to expect, how to run through a scenario, and what makes a useful test report. Helps contributors show up prepared rather than figuring it out on the fly.
      • Pair newer contributors with more experienced ones during the testing phase: The experienced contributor can help guide the approach, model what a useful report looks like, and answer questions in real time. This should result in higher quality results while naturally supporting onboarding at the same time.
      • End each release party with a clear “what’s next”: Close out the testing phase with a specific, actionable next step for contributors who want to keep going.
      • A designated release party testing board: A shared, visible checklist of the specific scenarios that need to be covered during the party. This is updated in real time as contributors claim and complete each one. Rather than everyone independently deciding what to test, the board makes it clear what’s been covered and what still needs attention, helping the group collectively ensure nothing important gets missed.

      Please leave your thoughts and ideas in the comments!

      Props to @annezazu, @jeffpaul, and @karmatosed for reviewing this post.


      Claude (Sonnet 4.6) was used to create an initial draft from a detailed list of pain points, pros, cons, and surrounding context, and also to perform proofreading.

      #feedback

      Pseudo-element support for blocks and their variations in theme.json

      WordPress 7.0 adds support for pseudo-class selectors (:hover, :focus, :focus-visible, and :active) directly on blocks and their style variations in theme.json. Previously, this was only possible for HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. elements like button and link under the styles.elements key. 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.-level interactive states could only be achieved through custom CSSCSS Cascading Style Sheets..

      Variation-level pseudo-selectors

      Block style variations can also define interactive states. This is particularly useful for variations like “Outline” that have distinct visual styles requiring different hover behaviors:

      {
          "styles": {
              "blocks": {
                  "core/button": {
                      "variations": {
                          "outline": {
                              "color": {
                                  "background": "transparent",
                                  "text": "currentColor"
                              },
                              ":hover": {
                                  "color": {
                                      "background": "currentColor",
                                      "text": "white"
                                  }
                              }
                          }
                      }
                  }
              }
          }
      }

      • This is a theme.json-only 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.. There is no new UIUI User interface in Global Styles for these states in 7.0. Work on this is happening at #38277 and will be added in a future release.
      • The supported pseudo-selectors for core/button are: :hover, :focus, :focus-visible, and :active. Any others will be ignored.
      • Pseudo-selectors defined at the block level and at the variation level are independent — you can define both without conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved..

      See #64263 for more details

      Props to @scruffian, @onemaggie for the implementation

      Props to @mikachan, @scruffian for technical review and proofreading.

      #7-0, #dev-notes, #dev-notes-7-0

      Announcing the Featured Plugins Experiment

      I pitched this to Matt directly and have been given the go ahead to pave the way here. This post begins that process and documents the Featured Plugins experiment currently underway on 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/. The goal is to surface newer plugins in the directory that meet a defined quality bar but have limited visibility. Eight plugins are selected every two weeks.

      Eligibility
      To be considered, 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. must meet all of the following baseline requirements:

      Active installs: fewer than 10,000
      Age: listed in the directory for 12 months or less
      No open security vulnerabilities
      Compatible with the current 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. of WordPress
      Updated within the last 6 months

      Selection Criteria
      Plugins that pass the eligibility requirements are evaluated against three categories of criteria.

      Technical standards
      Code is human-readable and follows 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.
      Proper use of escaping, sanitization, and nonces
      No unnecessary bundling of libraries or WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. functionality
      Plugin readme accurately describes what the plugin does

      Ecosystem fit
      Addresses a problem not already well-served by existing plugins
      Provides functionality with genuine utility to WordPress users

      Developer engagement
      Developer is responsive in the support forums
      UXUX User experience reflects care and intentionality in the implementation

      How Decisions Are Made
      Plugin selection is currently handled by Nick Hamze. The process and governance around selections will be reassessed as the experiment develops.

      How Plugins Are Considered
      All plugins that meet the eligibility requirements are automatically included in the pool for consideration. No submission is required.

      Plugin authors who want to provide additional context about their plugin — or make a case for its inclusion — can do so in the #featuredplugins channel on the Make WordPress 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/..

      Tracking Progress
      This experiment is tracked openly. Feedback on the criteria, the process, or specific selections can be shared in the #featuredplugins Slack channel. The process and governance around selections will be reassessed as the experiment develops. Right now, the aim is to experiment first with a small scope to ensure it’s meaningful for end users, plugin authors, and contributors. As the work evolves, more documentation and any necessary process can be added so future contributors can join.

      Breadcrumb block filters

      WordPress 7.0 introduces a new Breadcrumbs 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. that can be placed once — such as in a theme’s headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. — and automatically reflects the site’s navigation hierarchy.

      Image
      Breadcrumbs block in a header template part using Twenty Twenty-Five theme, here showing the trail for a child page

      Two filters provide developers with control over the breadcrumb trail output.

      block_core_breadcrumbs_items

      This 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. allows developers to modify, add, or remove items from the final breadcrumb trail just before rendering. Each item is an array with three properties:

      1. label (string) — the breadcrumb text.
      2. an optional url (string) — the breadcrumb link URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org.
      3. an optional allow_html (bool) — whether to allow HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. in the label. When true, the label will be sanitized with wp_kses_post(), allowing only safe HTML tags. When false or omitted, all HTML will be escaped with esc_html().

      Example: Prepend a custom breadcrumb item

        add_filter( 'block_core_breadcrumbs_items', function ( $breadcrumb_items ) {
              array_unshift( $breadcrumb_items, array(
                      'label' => __( 'Shop', 'myplugin' ),
                      'url'   => home_url( '/shop/' ),
              ) );
      
              return $breadcrumb_items;
        } );

      block_core_breadcrumbs_post_type_settings

      When a post type has multiple taxonomies or when a post is assigned to multiple terms within a taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies., there could be numerous ways to construct the breadcrumbs trail. For example in a post that has both categories and tags a user might want to show in the breadcrumbs trail the categories (default), the tags and/or select a specific 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.).

      This filter controls which taxonomy and terms appear in the Breadcrumbs block trail for posts that use taxonomy-based breadcrumbs. It applies to non-hierarchical post types (e.g., posts, products) or hierarchical post types when the block’s “Prefer taxonomy terms” setting is enabled (under advanced settings). It does not affect hierarchical ancestor-based trails (e.g., parent/child pages).

      The filter receives three parameters:

      • $settings (array) — an empty array by default. Callbacks should populate the array and return it with the following optional keys:
        • taxonomy (string) — taxonomy slug to use for breadcrumbs.
        • term (string) — term slug to prefer when the post has multiple terms in the selected taxonomy.
      • $post_type (string) — the post type slug.
      • $post_id (int) — the post ID, enabling per-post customization.

      Fallback behavior

      • If the preferred taxonomy doesn’t exist or has no terms assigned, fall back to the first available taxonomy with terms assigned.
      • If the preferred term doesn’t exist or isn’t assigned to the post, fall back to the first term
      • If the post has only one term, that term is used regardless of setting

      Example 1: Set a preferred taxonomy and term per post type

      add_filter( 'block_core_breadcrumbs_post_type_settings', function( $settings, $post_type ) {
      	if ( $post_type === 'post' ) {
      		$settings['taxonomy'] = 'category';
      		$settings['term'] = 'news';
      	}
      	if ( $post_type === 'product' ) {
      		$settings['taxonomy'] = 'product_tag';
      	}
      	return $settings;
      }, 10, 2 );

      Example 2: Choose a specific term per post

      add_filter( 'block_core_breadcrumbs_post_type_settings', function ( $settings, $post_type, $post_id ) {
      	if ( $post_type !== 'post' ) {
      		return $settings;
      	}
      	
      	$terms = get_the_terms( $post_id, 'category' );
      
      	if ( $terms ) {
      		$settings['taxonomy'] = 'category';
      		$settings['term']     = end( $terms )->slug;
      	}
      
      	return $settings;
      }, 10, 3 );

      See 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/ pull requests: 74169, 73283, 74170.

      Props to @karolmanijak, @ntsekouras for the implementation.

      Props to @karolmanijak for technical review.

      Props to @mcsf for copy review.

      #dev-notes, #7-0

      Customisable Navigation Overlays in WordPress 7.0

      WordPress 7.0 introduces Customisable Navigation Overlays, giving site owners full control over their mobile navigation menus using 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.

      Previously, when a visitor tapped a hamburger menu icon on a mobile device, WordPress displayed a fixed default overlay with no support for customisation. The design, layout, and content were locked.

      Customisable Navigation Overlays remove this restriction entirely — any overlay can now be built from blocks and patterns in the Site Editor. This includes a dedicated Navigation Overlay Close block for placing and styling a close button anywhere within the overlay.

      How overlays work

      Navigation overlays are implemented as template parts using a new navigation-overlay template part area, managed principally through the Navigation block’s overlay controls in the Site Editor. Because they are template parts, they can also be found and edited via the Patterns section in 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.. Each overlay is assigned to a Navigation block — while the same overlay can be referenced by more than one, a one-to-one relationship is the most common pattern.

      What goes inside an overlay is entirely up to the author. As a standard block canvas, it can contain any block — navigation, social icons, a search field, a site logo, calls to action…or any combination! A Navigation block is the typical inclusion but is not a requirement. Because overlays only function correctly when rendered by a Navigation block, overlay template parts are intentionally excluded from the general block inserter — this prevents them from being inserted accidentally into other parts of a template.

      The feature is opt-in: by default, the Navigation block continues to use the standard overlay behaviour from previous versions of WordPress. A custom overlay can be activated in three ways:

      • Creating a new overlay — via the Overlays section in the Navigation block’s sidebar controls in the Site Editor
      • Selecting an existing overlay — from the same controls, choosing from any overlays already created or bundled with the active theme
      • Theme pre-assignment — a theme can reference a bundled overlay directly in the Navigation block markup (covered in the developer section below)

      For theme developers: bundling overlays with your theme

      Themes can ship pre-built navigation overlays so they are available as soon as the theme is activated. The recommended approach is to provide both a default overlay template part and a set of overlay patterns.

      Template parts vs patterns

      Understanding the distinction helps decide how to structure an overlay offering:

      • template part is the overlay itself — the component that gets rendered when a Navigation block uses an overlay. Shipping a template part means a ready-to-use overlay is available from the moment the theme is activated.
      • Patterns are design options that appear in the Design tab when editing a navigation overlay in the Site Editor. Selecting a pattern replaces the current overlay content with the pattern’s block markup, letting users switch between distinct designs.

      A patterns-only approach is also valid — useful when a theme wants to offer design options without pre-applying an overlay automatically. In this case, users create a new overlay via the Navigation block’s controls and pick from the theme’s patterns as a starting point.

      Updating your Theme

      1. Register the template part in theme.json

      Registering the template part in theme.json is required. Without it, the template part is assigned the uncategorized area and will not be recognised by the Navigation block as an overlay.

      Add an entry to the templateParts array, setting area to navigation-overlay:

      {
          "templateParts": [
              {
                  "area": "navigation-overlay",
                  "name": "my-custom-overlay",
                  "title": "My Custom Overlay"
              }
          ]
      }
      
      

      2. Create the template part file

      Create the corresponding HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. file in the theme’s parts/ directory. The filename should match the name value from theme.json.

      It is strongly recommended to include the Navigation Overlay Close block within the overlay. If it is omitted, WordPress will automatically insert a fallback close button on the frontend for 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) and usability reasons — but that button may not match the overlay’s design or be positioned as expected. Including it explicitly gives full control over its appearance and placement.

      <!-- parts/my-custom-overlay.html -->
      <!-- wp:group {"layout":{"type":"flex","orientation":"vertical"}} -->
      <div class="wp-block-group">
          <!-- wp:navigation-overlay-close /-->
          <!-- wp:navigation {"layout":{"type":"flex","orientation":"vertical"}} /-->
      </div>
      <!-- /wp:group -->
      

      3. Register overlay patterns

      Overlay patterns are registered using register_block_pattern(). Setting blockTypes to core/template-part/navigation-overlay scopes the pattern so it only appears when editing a navigation overlay template part — not in the general inserter.

      register_block_pattern(
          'my-theme/navigation-overlay-default',
          array(
              'title'      => __( 'Default Overlay', 'my-theme' ),
              'categories' => array( 'navigation' ),
              'blockTypes' => array( 'core/template-part/navigation-overlay' ),
              'content'    => '<!-- wp:group {"layout":{"type":"flex","orientation":"vertical"}} -->
      <div class="wp-block-group">
          <!-- wp:navigation-overlay-close /-->
          <!-- wp:navigation {"layout":{"type":"flex","orientation":"vertical"}} /-->
      </div>
      <!-- /wp:group -->',
          )
      );
      
      

      4. Pre-configuring the Navigation block (optional)

      A theme can optionally pre-configure a Navigation block to reference a specific overlay by setting the overlay attribute in the block markup. The value should be the template part slug only — without a theme prefix:

      <!-- wp:navigation {"overlay":"my-custom-overlay"} /-->
      
      

      Using the slug only — without a theme prefix — is important for future compatibility: WordPress plans to allow template parts to persist across theme switches, and a theme-prefixed identifier would break that. This follows the same convention as header and footer template parts.

      The overlay attribute is entirely optional — users can select or change the overlay at any time using the Navigation block’s sidebar controls.

      Known limitations

      Template parts and theme switching

      Navigation overlay template parts are currently tied to the active theme. Custom overlays will not be preserved if the active theme is switched. This is a known limitation tracked in gutenberg#72452.

      Overlays are full-screen only

      In this initial release, navigation overlays are always rendered full-screen. Non-full-screen overlay styles (such as a sidebar drawer) are not yet supported. This requires implementing overlays as a true <dialog> element — including support for clicking outside to close — which is planned for a future release.

      Not a generic popup or dialog

      Navigation Overlays are intentionally scoped to the Navigation block and are not designed as a general-purpose popup or dialog implementation. For broader use cases — such as modal dialogs triggered by arbitrary content — a dedicated Dialog block is in development and tracked in gutenberg#61297.

      Questions and feedback

      Until now, the mobile navigation overlay has been one of the few remaining areas of a block theme that couldn’t be designed in the Site Editor. Navigation Overlays change that. An overlay can contain anything blocks can express — a simple menu with a styled close button, a full-screen layout with the site logo and a call to action, or a content-rich experience that turns the mobile menu into a destination in its own right.

      There is a lot of creative space here, and seeing what the community builds with it will be exciting.

      Questions are welcome in the comments below.

      Further reading


      Props @onemaggie for implementation contributions and technical review, @mikachan, @jeryj @scruffian for proofreading, and @mmcalister, whose Ollie Menu Designer 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. helped validate community demand for this functionality.

      #7-0, #dev-notes, #navigation

      DataViews, DataForm, et al. in WordPress 7.0

      Previous cycle: WordPress 6.9.

      This is a summary of the changes introduced in the “dataviews space” during the WordPress 7.0 cycle from the 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. perspective. They have been posted in the corresponding iteration issue as well. To follow what’s next, subscribe to the iteration issue for WordPress 7.1.

      The changes listed here include 166 contributions by 35 unique authors across the community during the past 4.5 months (since October 17th, 2025).

      Continue reading

      #7-0, #dev-notes, #dev-notes-7-0