agulbra 7:46 pm on May 22, 2026
Tags: charset, ,   

Extending Unicode support in email addresses.

Eleven years ago, in Core-31992, someone proposed allowing non-US-ASCII email address support in WordPress. The software world has changed considerably since then: internationalized domain names and paths are uniformly handled in browsers, email systems support the wide range of Unicode characters as raw UTF-8, and UTF-8 is the only recommended text encoding for interchange between systems. This means that people are free to use their own names when communicating with others, whether they are Jake, Klรกra, เฆ†เฆฐเฆฟเฆฏเฆผเฆพ , เด…เดฎเตฝ, or any other name containing letters outside the A-Z range. Unfortuantely, WordPress has not kept up with these changes, and thatโ€™s what this post is all about.

This post is a request for comment on adding that support. There are a number of complications with potentially far-reaching implications.

TL;DR

  • WordPressโ€™ email sanitization is based on US-ASCII characters and needs to be relaxed to allow for valid UTF-8, but this introduces new risks, including but not limited to: confusable characters, equivalence through normalization, and non-visible characters.
  • Sites whose databases cannot store full UTF-8 may fail to save valid email addresses. This could be confusing to the site owner and to people attempting to sign up on the site unless properly communicated.
  • Any additional code that assumes emails are encoded as single-byte US-ASCII will need updating, specifically because it was always an invariant before that emails would not contain multi-byte Unicode characters. Filters may start seeing characters they believed were impossible to receive.

If you have experience with email issues, deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. email services, or know about certain critical aspects of this proposal, please share your thoughts here or in Core-31992.

Continue reading โ†’

#charset, #email, #unicode

Ashar Fuadi 10:58 am on July 13, 2026
Tags: , , ,   

Consistent navigation in WordPress 7.1 with persistent toolbar

WordPress 7.1 makes navigation more consistent across the whole adminadmin (and super admin) interface, including the editor, where the difference is most noticeable.

In the editor, the top-left โ€œWโ€ logo / site icon served as the back button, and clicking it took you out of the editor. But a โ€œWโ€ logo / site icon doesnโ€™t read as a back button, and using it for navigation was a frequent source of confusion. Three changes are implemented to fix this situation:

  • the toolbar now appears in the editor as it does everywhere else (except in the Distraction Free mode),
  • the โ€œWโ€ logo / site icon is replaced with a dedicated back button (a chevron), and
  • the site icon, when set, is shown in the toolbar.

The result is a navigation model where each icon means one thing everywhere: the โ€œWโ€ logo always opens the About page, the site icon (when set) always opens the site menu in the toolbar, and the chevron always goes back to the previous screen. The site title also stays visible throughout the editor, including on the editing canvas. See the following images:

BeforeAfter

or with site icon:

BeforeAfter

What it means for users

The toolbar will be shown in Post and Site Editors by default, as part of the persistent navigation layer. If youโ€™d rather work without it, turn on the Distraction Free mode, where the toolbar is hidden as it is today in that mode.

What it means for 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. developers

Before WordPress 7.1, the toolbar could already appear in the Post Editor when the fullscreen mode is turned off. The Site Editor has no such mode, so a persistent toolbar in the Site Editor is a new behavior. If your plugin adds a node in the toolbar, itโ€™s worth double-checking if it still works correctly in the Site Editor.

If youโ€™d prefer not to show your pluginโ€™s toolbar node in the editor at all, you can 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. it out on editor screens, e.g. by checking $screen->is_block_editor() as follows:

add_action(
    'admin_bar_menu',
    function ( WP_Admin_Bar $wp_admin_bar ) {
        $screen = function_exists( 'get_current_screen' ) ? get_current_screen() : null;

              // use this check to hide the node in the Site Editor
              if ( $screen && 'site-editor' === $screen->id ) {
                      return;
              }
              // ... or use this check to hide the node in any block editor
              if ( $screen && $screen->is_block_editor() ) {
                      return;
              }


        $wp_admin_bar->add_node( ... );
    },
    100
);

Additional resources

  • TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets: #65091, #65088
  • Iteration issue

Props to @tyxla, @mayanktripathi32, @joen, @lucasmdo, @mamaduka, and @annezazu for reviewing this post.

#7-1, #editor, #dev-notes, #dev-notes-7-1

Jonathan Desrosiers 3:24 am on June 30, 2026  

Guidelines for Syncing Code From Gutenberg Into WordPress Develop

During the 7.0 release cycle, the way code maintained in the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses โ€˜blocksโ€™ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ repository is imported into the wordpress-develop repository changed from using published npm packages to downloading a zip file of built assets published to the GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the โ€˜pull requestโ€™ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ Container Registry by the build-plugin-zip.yml workflow file in Gutenberg (see #64393, Gutenberg-75844).

There were two bugs preventing wordpress-develop from being updated with the latest changes (Gutenberg-76715 and #65418). These have been fixed and after [62577-62578,62580-62584],ย  trunk is now in sync with the most recent gutenberg release (currently 23.4.0).

To set expectations and establish some consistency going forward, this post outlines the process for syncing the two repositories going forward, and how to perform the syncing process.

Syncing Practices

The following sections aim to define when and how to sync changes from the gutenberg repository into the wordpress-develop repository.

Cadence During Alpha Periods

For the 7.1 release cycle, syncing will happen one week after each general release of Gutenberg. This ensures that trunk is reasonably up to date with the latest changes, but still allows some time for any follow-up bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes that are required. The goal is to eventually sync weekly, or even daily.

Syncing During The Release Cycle 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./RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). Phase

Once the Beta 1 point is reached for a release, the SHA value pinned to gutenberg.sha in package.json for trunk will be updated to one belonging to the releaseโ€™s corresponding wp/X.Y branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". in the Gutenberg repository when the next syncing occurs. trunk will remain pinned to a wp/X.Y branch hash value until branching occurs. This prevents new feature work not intended for the upcoming WordPress release from leaking into the SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. code base.

Because individual changes targeted for an upcoming WordPress release are cherry-picked into each wp/X.Y branch, syncing can happen as often as necessary. However, the most recent changes must be synced prior to each beta and RC release.

Branching in WordPress SVN

After branching is performed in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. SVN, the new numbered branch in SVN will remain pinned to the corresponding wp/X.Y branch in the Gutenberg repository.

After branching, the trunk branch should be bumped to X.Y+1-alpha (example [62161]) and a second commit should be made changing the pinned SHA value back to the most recent Gutenberg pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. release in trunk, thus syncing all of the changes since Beta 1. Making two commits creates two distinct reference points: one for bumping the version, one for documenting all of the changes being synced into the code base from Gutenberg.

Note: Branching typically happens immediately after the RC1 release is published for an upcoming major version. But in some cases, branching can be delayed or moved up based on factors unique to the current release.

Post-Branching in WordPress SVN

After branching has occurred for an upcoming 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. and the numbered branch is pinned to the corresponding wp/X.Y branch, syncing should happen as often as necessary to ensure the latest changes targeted for that release are included in each Beta and RC release.

Committers should balance the frequency of updating with the net benefit after considering other factors, such as the severityseverity The seriousness of the ticket in the eyes of the reporter. Generally, severity is a judgment of how bad a bug is, while priority is its relationship to other bugs. of the fix being merged, the non-zero amount of noise each commit makes, contributors needing to pull updates/merge the latest into their pull requests, the volume of related reports being made, etc. Syncing solely to pull in a typo fix is probably unnecessary. But syncing to only pull in a bug fix for an 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. that was broken is worth considering.

This process will continue during maintenance releases.

trunk will return to being synced during the week opposite Gutenberg plugin releases.

Example Timeline

Using the upcoming 7.1 release as an example, here is a timeline of events:

  • Gutenberg: Version 23.6.0 of the plugin is released.
  • Gutenberg: The wp/7.1 branch is created in the gutenberg repository.
  • WP SVN: Prior to 7.1-beta1, trunk is updated to the most recent hash in the wp/7.1 branch of gutenberg.
  • WP SVN: trunk is synced with wp/7.1 before every beta or rc release (and as often as necessary in between).
  • WP SVN: After RC1 the 7.1 branch is created.
  • WP SVN: trunk is updated to 7.2-alpha.
  • WP SVN: trunk is updated to sync version 23.7.0 of Gutenberg.
  • WP SVN: The 7.1 branch continues to be synced prior to each RC and before final release.
  • WP SVN: trunk returns to being updated one week after each general release of Gutenberg.
  • WP SVN: WordPress 7.1 is released. The 7.1 branch is updated prior to beta/RC versions for minor releases, and whenever necessary going forward (remaining pinned to wp/7.1).

Minor Releases & Backporting In WordPress SVN

The process for merging commits into a numbered branch for a minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. will remain the same.

  1. Commit the change to trunk.
  2. Mark the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. for 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. consideration by moving to the minor release milestone with fixed-major, and commit dev-feedback for sign off from a second committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. to backport.
  3. Merge to the numbered branch after a second sign off is added with the commit dev-reviewed keywords.

However, there is one small change that will be required to this workflow. Because numbered branches now use SHA values from the corresponding wp/X.Y branches and trunk has the latest changes from trunk in Gutenberg, it is likely not possible to merge a single fix into trunk first.

Therefore, commits changing pinned SHA values to numbered branches will be allowed provided the double signoff process is followed.

Note: If any PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher changes are required that will not be included in the sync commit after bumping the pinned SHA value, they should be committed to trunk first and follow the backporting process.

Merging Changes

Creating A Sync Pull Request

To create a pull request for syncing the two repositories, find the full-length hash value for the version of Gutenberg being targeted for syncing and update the gutenberg.sha value in the package.json file.

Running build:dev locally will update every built file with the corresponding changes. However, there is a GitHub Actions workflow that pushes these changes back to a PRโ€™s HEAD branch automatically.

Reviewing A Sync Pull Request

When the value of gutenberg.sha is updated, one or more Gutenberg plugin releases are merged into wordpress-develop. As a result the number of modified/added/deleted files in the PR itself will be quite high and validating every single one is not possible. However, the files updated should only consist of those modified by the build script (mainly build:dev). Any changes to files managed manually must be made separately.

When reviewing a sync PR, the main things to verify are:

  • No new changes exist locally after running build:dev.
  • The changed files line up with the changes listed forย 
  • Does WordPress run as expected locally using the PR?

Who Is Responsible For Syncing?

Anyone can create the pull request to update the hash value pinned in wordpress-develop! The contributor with the best working knowledge of the changes included in a given Gutenberg plugin version is the contributor leading that release.

To start, creating a ticket on Trac for syncing and the initial pull request for the release will be added as items in the Gutenberg Plugin Releases page in the handbook.

There are opportunities to automate parts of this process, but more time is needed to get that working properly.

Allowed Hash Values In wordpress-develop Commits

There are several ways to pull in code from the gutenberg repository by specifying different values for gutenberg.sha:

  • Full-length commit SHA
  • Plugin release-specific tags such as release-23.4 (after the release/23.4 branch is created)
  • WordPress version-specific tags such as wp-7.1 (after the wp/7.1 branch is created)
  • Pull request-specific tags such as pr-123456
  • Bleeding edgebleeding edge The latest revision of the software, generally in development and often unstable. Also known as trunk. changes using trunk

Each reference type above is updated after each commit. The build script in wordpress-develop will always attempt to fetch the most recent version before building.

While these tags are helpful for local development, their mutable nature does not guarantee idempotency. Full-length commit hash values are the only immutable references. Given this, only full-length SHA values are allowed to be used as values for gutenberg.sha in the package.json file.

Trac Tickets And Merge Commits

Because these merges include many different features and bug fixes, it can quickly become difficult to track when certain specific changes are merged into wordpress-develop from gutenberg.

To improve clarity, Trac tickets should be created and utilized as follows:

  • All changes and updates to files not managed by the build script require individual tickets (current practice).
  • A new ticket should be created for every hash bump during the alpha period (new practice).
  • A single ticket can be used for all hash bumps between each beta and RC release (new practice).

Examples: A single โ€œGutenberg Syncs for Beta 2โ€ ticket can be used for all hash bumps between beta1 and beta2. A single โ€œGutenberg Syncs for RC2โ€ ticket can be used for all hash bumps between RC1 and RC2. But hash bump A and hash bump B during the alpha period must have separate tickets.


This helps to avoid Trac tickets with 100s of comments, and 10s of associated PRs, and 10s of commits and creates a single point of tracking for each merge point.

Commit Messages

The following commit message format should be used when committing a pinned SHA update:

Component: Bump the pinned hash from the Gutenberg repository.

(WITH versions aligning with tags)
This updates the pinned commit hash of the Gutenberg repository from `%%OLD_FULL_HASH%%` (version `v25.0.0`) to `%%NEW_FULL_HASH%%` (version `26.0.0`). (versions are required when the hashes correspond to one, but optional when not directly associated with a specific release tag)

(Without versions aligning with tags)
This updates the pinned commit hash of the Gutenberg repository from `%%OLD_FULL_HASH%%` to `%%NEW_FULL_HASH%%` and merges all of the changes that were cherry-picked to the `wp/7.0` branch between WordPress `7.0-beta1` and today (preparing for `7.0-beta2`).

A full list of changes included in this commit can be found on GitHub: %%LINK%%.

The following commits are included:
- Pattern Editing: The best pattern feature yet! (https://github.com/WordPress/gutenberg/pull/#####)
- Global Styles: Adding support for feature X within the block styles. (https://github.com/WordPress/gutenberg/pull/#####
- etc..

Follow-up to [27195], [41062]. (optional)

Reviewed by a-fellow-committer, maybe-multiple.
Merges [26851] to the x.x branch. (both of these are only required when backporting from `trunk`)

Props person, another.
Fixes #30000. See #20202, #105.

The following command can be used to generate the list of changes being included (the two dot comparison is intentional):
git log --reverse --format="- %s" OLDHASH..NEWHASH | sed 's|#\([0-9][0-9]*\)|https://github.com/WordPress/gutenberg/pull/\1|g; /github\.com\/WordPress\/gutenberg\/pull/!d' | pbcopy

Next Steps

  • Document the various ways to pull in changes from the gutenberg repository upstream (see Gutenberg-78211).
  • Update the Core Handbookโ€™s Best Practices for Commit Messages page to include the merge commit formatting.
  • Update the Branching Before Release section of the Releasing Major Versions page in the Core Handbook to include the new steps and adjustments detailed above.
  • Update other release checklists (both major and minor)
  • Submit a PR to add new steps to the Gutenberg Plugin Release page of 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 Handbook.

Summary

After considering different options and examining how all the moving pieces work, this process was chosen as a way to balance moving faster while also encouraging stability, and continues to follow long-established historical practices dictating how code is managed from release to release.

Any necessary adjustments can be made as needed and everyoneโ€™s feedback is welcome!

Props: @adamsilverstein, @aduth, @annezazu, @ellatrix, @jeffpaul, @jonsurrell, @jorbin, @mamaduka, @tyxla,ย @wildworks, @youknowriad for peer review and discussing aspects of this post before publishing.

Jorge Costa 5:47 pm on July 2, 2026  

Merge Proposal: Expanding WordPress Core Abilities

This proposal expands the WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Abilities 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. in WordPress 7.1 with three read-only abilities:

  • core/read-settings
  • core/read-content
  • core/read-users

The Abilities API shipped in WordPress 6.9 as a foundation for registering discrete, permission-checked actions with typed input and output schemas.

WordPress 6.9 included only a small initial set of Core abilities, including site, environment, and current-user information. Since then, we have been experimenting with PRs in the AI 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 WordPress Core. The next useful step is a small, read-only expansion that lets agents and workflows understand the key data already managed by a WordPress site: settings, content, and users.

Purpose and goals

The goals for this proposal are:

  • Ship a canonical baseline of read abilities for WordPressโ€™s Core entities, so the ecosystem builds on them instead of re-implementing them.
  • Make a standard WordPress install meaningfully agent-readable: an agent can retrieve and understand a siteโ€™s configuration, content, and users.
  • Give the AI Client (merged in 7.0) something real to call as โ€œtoolsโ€. For example, allow someone to execute this prompt: โ€œPropose a draft titled โ€œJune 2026 Summaryโ€ summarizing all the posts I wrote in June 2026 linking to the original posts.โ€
  • Have abilities that expose content so that, once WebMCP (or similar technology) is stabilized, we can allow agents to consume it by simply mapping abilities to tools.
  • Establish a repeatable pattern for future abilities covering comments, themes, plugins, taxonomies, media, and other Core entities.

Ability shape

The long-term direction is to organize Core abilities mostly in pairs:

  • A read ability, such as core/read-content, that retrieves a single item or a collection.
  • A manage ability, such as core/manage-content, that updates data or performs a user-intent action.

Settings and post types will use a show_in_abilities flag so that registering something in WordPress does not automatically make it available to ability consumers. In the future, that flag could be used for post 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. or user meta. Core will opt into a conservative default set of built-in settings and post types, similar in spirit to how show_in_rest made selected entities available to the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think โ€œphone appโ€ or โ€œwebsiteโ€) can communicate with the data store (think โ€œdatabaseโ€ or โ€œfile systemโ€) https://developer.wordpress.org/rest-api/.

Proposed 7.1 scope

core/read-settings

Returns settings that have explicitly opted in to abilities. It returns a flat name => value object and supports filtering by group or by specific setting names. It requires the manage_options capabilitycapability Aย capabilityย is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on theirย role. For example, users who have the Author role usually have permission to edit their own posts (the โ€œedit_postsโ€ capability), but not permission to edit other usersโ€™ posts (the โ€œedit_others_postsโ€ capability)..

This lets authorized tools answer questions such as โ€œwhat is the site title?โ€ or โ€œwhich permalink-related settings are exposed?โ€

Relevant work:

core/read-content

Retrieves content from post types exposed to abilities. It supports single-item lookup and collection queries. The default response is lean, while more expensive or sensitive fields are returned when explicitly requested.

Relevant work:

Advanced query support, such as meta_query, tax_query, and date_query, is intentionally left for a future version. Those shapes may be valuable for agents and workflows, where a slower targeted query can be better than retrieving everything and filtering client-side, but they need a focused review.

core/read-users

Retrieves users through single-user lookup or collection mode. It supports lookup by fields such as ID, email, login, or nicename, and collection filters such as roles, published-post status, etc.

Users should only see data they are already allowed to see; inaccessible fields are omitted per user.

Relevant work:

Why this belongs in Core

The WP AI Client and other agentic integrations like mcp-adapter need abilities as the tools they can pass to agents and prompts. Without Core read abilities, those integrations can call a model but cannot reliably answer basic questions such as what posts exist or which page is the front page.

The ecosystem is already experimenting with its own versions of these abilities. For example, right now there are multiple projects implementing the ability to retrieve a post. That is healthy exploration, but the common entities should converge on shared Core contracts. A Core-provided base reduces repeated work and gives the community one place to review exposure, capabilitiescapability Aย capabilityย is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on theirย role. For example, users who have the Author role usually have permission to edit their own posts (the โ€œedit_postsโ€ capability), but not permission to edit other usersโ€™ posts (the โ€œedit_others_postsโ€ capability)., schema shape, and edge cases.

Abilities can present a shape that is natural to humans and models. The planned core/manage-content, for instance, could have an action property (publish, move-to-trashTrash Trash in WordPress is like the Recycle Bin on your PC or Trash in your Macintosh computer. Users with the proper permission level (administrators and editors) have the ability to delete a post, page, and/or comments. When you delete the item, it is moved to the trash folder where it will remain for 30 days., โ€ฆ), so an agent asks for the same intent a human expresses by clicking a button, rather than having to know that โ€œpublishโ€ means mutating post_status.

Abilities operate under different constraints than REST. In terms of what is available, we may have information (e.g., secrets) exposed via REST that is not exposed under abilities. And because abilities are invoked by agents and workflows rather than from a latency-sensitive front end, they can reasonably afford operations REST avoids. We keep advanced querying (e.g., meta_query) out of REST because it can be slow, but for an agent, a server-side meta query is still far cheaper than fetching everything and filtering client-side. This different latency budget is part of why a separate, abilities-shaped surface is worthwhile.

As WebMCP-style tool discovery and browser-accessible tool surfaces continue to evolve, having carefully reviewed Core abilities gives WordPress a path to becoming agent-ready as soon as WebMCP stabilizes. The same Core ability contracts can be mapped to WebMCP tools, so we can easily make WordPress agent-ready and expose its content in the format WebMCP accepts.

Security and privacy

The proposed abilities are read-only and carry read-only annotations. They perform full permission checks before execution.

The security model is:

  • Settings and post types must opt in through show_in_abilities. This makes it possible to control what is visible to an agent. For example, a secret may be available over REST so the UIUI User interface can manipulate it, but it should never be shown to an agent.
  • Every ability includes a permission callback that checks the current userโ€™s existing roles and capabilities (e.g., manage_options, list_users, etc.) to determine whether the ability can be executed.
  • Sensitive fields are omitted unless the current user has the required capability.
  • Prompt-injection protection for ability results is out of scope. Abilities return stored data as-is. Agents and models that consume those results must treat them as tool output, not instructions to follow.

Goals for 7.2 and beyond

After the read abilities settle, the next layer is management abilities:

  • core/manage-settings
  • core/manage-content
  • core/manage-users

Future content work may also revisit advanced querying, including meta_query, tax_query, and date_query, building on the earlier exploration in wordpress-develop#10665.

We also plan to support more entities, specifically comments, taxonomies, media, themes, and plugins, following the same read/manage + opt-in pattern, with extra guardrails for higher-risk operations.

Feedback

Feedback is welcome in the comments on this proposal, on the linked AI PRs, and in the #core-ai channel on 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/. If you maintain or are building abilities for these entities, we would especially like you to test the implementations and tell us if the shape, defaults, or permissions fit your use case. The goal is one baseline the whole ecosystem can build on.

Andrew Duthie 3:31 pm on July 7, 2026
Tags: ,   

Merge Proposal: Design System Theming

As part of design systems work supporting the admin design project, the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses โ€˜blocksโ€™ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ Components Team has been working on a foundational layer of themeability and design tokens that support consistent, accessible UIUI User interface components across the adminadmin (and super admin) experience. On behalf of this group, I would like to propose the initial theming capabilitiescapability Aย capabilityย is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on theirย role. For example, users who have the Author role usually have permission to edit their own posts (the โ€œedit_postsโ€ capability), but not permission to edit other usersโ€™ posts (the โ€œedit_others_postsโ€ capability). for merge: a comprehensive set of design tokens and themeability enabled through the ThemeProvider ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org component.

Purpose and Goals

The broader design systems effort is aimed at improving consistency and 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) of components in the WordPress admin experience. Theming and design tokens are the foundational set of styles that support this work. In practice, the net result is a set of CSS custom properties that can be used within components to apply color, typography, border, elevation, or other styling aspects.

Using design token properties instead of hard-coded values helps ensure consistency across components, while still supporting customization like user color scheme. This builds upon established shared styles like those in the @wordpress/base-styles NPM package by providing a basis that can apply to many other types of UI surfaces and controls. With this comprehensive theming approach, those established CSSCSS Cascading Style Sheets. colors will become aliases to tokens within the broader set of design tokens.

One particularly ambitious outcome of this project is a tool for generating color ramps from a pair of accent and background โ€œseedโ€ colors. This tool can create a color scale thatโ€™s configurable, visually harmonious, and provides accessible contrast between color values that are used together.

This configurability is an important aspect of theming, and itโ€™s crucial to unlocking a number of use-cases that should be supported:

  • For users, this enables more personalization over how the interface looks. WordPress can continue to provide smart defaults and support the existing set of admin color palettes, but a user could also have the option to choose whichever color combination they prefer. This can be extended later with more themeable aspects, like roundness or density.
  • For 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. developers, they can express their own brand identity while still feeling authentic and consistent with the rest of the WordPress experience. Opting into WordPress theming means they benefit from future improvements automatically, without an ongoing maintenance cost. Design tokens aim to reduce confusion for developers and AI agents in choosing the best styling for a UI element by providing a comprehensive set of tokens aligned to semantic purpose.
  • For WordPress development, it provides an easier pathway to extend the user color scheme consistently to more parts of the admin interface. It also unlocks the ability to more easily implement features like a true โ€œdark modeโ€ feature, since admin surfaces are controlled by the background seed color.

Background

The design system effort has evolved over the last several years, guided by a baseline expectation of accessibility and consistency, and a need for a strong foundation for admin innovation:

While WordPress has had shared styles and shared componentry in many forms over the years, it has required significant ongoing effort to try to maintain consistency. WordPress 7.0โ€™s visual refresh is one example of this (in particular, the reskin effort in #64308). A comprehensive theming system based on CSS properties should reduce this ongoing maintenance cost, in both React-based and non-React-based admin interfaces.

This also tracks with where the software industry is moving. The W3C Design Tokens Community Group published the first stable version of the Design Tokens (DTCG) specification late last year, and the WordPress theme design tokens follow this specification. This specification is seeing adoption in industry tools like Figma, which has added support for importing design tokens as variables. As the discrete foundational unit for styling UI components, a set of documented, semantic design tokens are well-understood by AI agents, which helps maintain a high standard of quality as developers adopt this technology.

Whatโ€™s Proposed for Merge

For developers, the initial set of theming APIs proposed for merge are:

  • A coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. registered stylesheet wp-theme, including a set of prebuilt CSS properties for the default WordPress theme.
  • A core registered JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a userโ€™s browser. https://www.javascript.com wp-theme, including a single React ThemeProvider component for extending the default theme in an area of the adminโ€™s user interface.

The default theme stylesheet is compiled from a set of design tokens that follow the design token specification. Developers and designers may find these tokens useful, as they can be imported directly into design tools like Figma for use in designs.ย 

For users, the current expected impact should be minimal, aside from more UI component consistency throughout the admin interface. The default theme was intentionally designed to be largely aligned with existing styles, and not radically change the appearance of existing screens.ย 

That being said, a noteworthy feature coming in WordPress 7.1 is the application of the user color scheme to the Site Editor, which is powered by the theming implementation.

Whatโ€™s Next

While not targeted for inclusion in WordPress 7.1, the following features are being considered for future iterations:

  • Better default availability of design tokens: While the new wp-theme stylesheet will be registered, it will only be enqueued by default on specific WordPress screens that use the new theming feature. As theming extends to more parts of the interface, itโ€™s expected that the tokens would be available more universally throughout the admin interface. In the meantime, developers can enqueue the stylesheet themselves.
  • Adoption and support across all screens: Since the design tokens are built on web standard technology (CSS properties) and a goal of the design system is to ensure consistency across all WordPress screens, itโ€™s expected that these design tokens would be adopted across all admin screens, not just React-based screens such as 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. and site editor. This builds on the work in #64308 in a way that is more sustainable and comprehensive.
  • Enhanced user customization through theming, enabling features like โ€œdark modeโ€: While this initial iteration provides a strong foundation for internal consistency, the true power of theming in providing more user expressiveness and capabilities for a โ€œdark modeโ€-like experience will be explored in future releases. The theming system already supports the capabilitycapability Aย capabilityย is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on theirย role. For example, users who have the Author role usually have permission to edit their own posts (the โ€œedit_postsโ€ capability), but not permission to edit other usersโ€™ posts (the โ€œedit_others_postsโ€ capability). for this today.

Call for Feedback

Your feedback to this merge proposal is welcomed in the comments below. As this work is focused on the long-term sustainability of UI component development,ย thereโ€™s particular interest in any risks or conflicts to consider in the proposed implementation.

Props to @mciampini, @annezazu, and @0mirka00 for reviewing this post.

+make.wordpress.org/design/

#7-1, #merge-proposals

Greg Ziรณล‚kowski 7:46 am on June 22, 2026
Tags: , guidelines, Knowledge,   

Merge Proposal: Guidelines built on Knowledge

We propose merging Knowledge, a new wp_knowledge 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., into WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for the 7.1 release, with Guidelines as the first feature built on it.

Knowledge is a general primitive for storing author-facing and agent-facing site knowledge as standard WordPress content: a post type with a type 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., the existing roles and capabilitiescapability Aย capabilityย is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on theirย role. For example, users who have the Author role usually have permission to edit their own posts (the โ€œedit_postsโ€ capability), but not permission to edit other usersโ€™ posts (the โ€œedit_others_postsโ€ capability)., native 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., and REST access. Guidelines uses it to give site owners a first-class place to capture the standards that shape how content is written and edited, such as voice, tone, image preferences, and per-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. rules.

The implementation is operational in the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses โ€˜blocksโ€™ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 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 has been exercised by production integrations. It builds on the Guidelines experiment, proposed in February and landed in Gutenberg 22.7 in March, then shaped through community feedback into a consolidated design and stabilized for core.

Purpose & goals

Most sites already have content standards, but they live outside WordPress in documents, wikis, and institutional knowledge. Guidelines gives them a canonical home inside WordPress, available where they matter: during writing and editing.

A single store of standards serves everyone who works on a site: writers and editors applying them by hand, plugins reading them, and AI assistants drawing on them too. Each of these needs the same thing, persistent and structured knowledge about the site, and today there is no shared place to keep it. Without a common primitive, every plugin ships its own storage, its own permissions model, and its own REST surface. That is exactly the kind of fragmentation WordPress core has historically prevented, the same way wp_template, wp_block, and nav_menu_item prevented parallel solutions in their domains. Core owns the primitive. The community decides what to build on it.

The name follows that intent. โ€œGuidelineโ€ describes prescriptive records well but fits memories and working notes much less naturally, while โ€œKnowledgeโ€ covers both procedural content (how work should be done) and declarative content (what is known). Knowledge names the namespace. Individual records are referred to by their concrete type, a guideline, a memory, a note. The user-facing feature in WP Adminadmin (and super admin) remains Guidelines, the same way the attachment post type surfaces as Media at /wp/v2/media.

The goals, concretely:

  • Provide a canonical storage primitive for author-facing and agent-facing site knowledge
  • Ship Guidelines as the first feature built on it, demonstrating the primitive in core
  • Replace fragmented plugin-specific storage, capabilitycapability Aย capabilityย is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on theirย role. For example, users who have the Author role usually have permission to edit their own posts (the โ€œedit_postsโ€ capability), but not permission to edit other usersโ€™ posts (the โ€œedit_others_postsโ€ capability)., and REST models with one shared foundation

Non-goals

This merge ships storage and access, not intelligence: no AI provider, no model, no retrieval algorithm, and no autonomous memory system. The specifics below are intentionally out of scope. They remain open topics, just not blockers:

  • No decay, consolidation, or retrieval mechanism in core. Consuming tools accommodate staleness above the primitive.
  • Further built-in types are deferred and can be registered by plugins in the meantime:
    • skill โ€“ a procedure that can load and apply a guideline, is planned for 7.2 pending settled loading and discovery semantics (ai#430)
    • plan โ€“ task-scoped working state for a multi-step task, pending a side-effect and lifecycle model
    • artifact โ€“ a reference to a versioned work product distinct from the freeform text covered by note, explored separately
  • Load applicability of scopes (when a scopeโ€™s guidance applies beyond the universal site scope) is left for its own discussion.
  • Session state and cross-site user preferences live above the primitive.
  • Encryption at rest is orthogonal hardening that can land later without changing the data model.

What we propose to merge in 7.1

  • The wp_knowledge custom post type with native revision support
  • The wp_knowledge_type taxonomy and the wp_knowledge_types registration 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.
  • The built-in types guideline, memory, and note (defined below)
  • The *_knowledge_item capability namespace and the access model described below
  • The generic /wp/v2/knowledge REST routes for working with knowledge records like other post types
  • The Guidelines Settings page: per-scope guideline records, a filterable scope registry as the source of truth for the UIUI User interface, and a read-only registry route at /wp/v2/knowledge/guideline-scopes

The knowledge management ability, registered through the Abilities 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., is expected to follow in a later release.

Built-in types

Each type is defined by what the record represents and how it is applied:

  • guideline โ€“ a standard, pure text that is the source of truth, such as voice, tone, image guidance, or per-block rules. A guideline does nothing on its own. It is there to be applied, either directly by an ability that pulls the text in or through a skill that loads it. The site-wide standards managed on the Settings page carry this type.
  • memory โ€“ durable context explicitly saved or approved for future use, such as user preferences, stable facts, and profile context. Records are private and author-owned. The explicit save-or-approve rule is deliberate: core ships a storage primitive, not a memory architecture. Decay, consolidation, and retrieval remain things to build on top.
  • note โ€“ private freeform working text, such as sticky notes, drafts, and notes synced from external tools. A record saved without a type falls back to note.

Plugins register their own types through the same filter. A plugin might add a glossary type to keep domain terminology consistent across writers, editors, and any agent that reads it:

function my_plugin_register_knowledge_types( array $types ): array {
	$types['glossary'] = array(
		'title' => __( 'Glossary', 'my-plugin' ),
	);

	return $types;
}
add_filter( 'wp_knowledge_types', 'my_plugin_register_knowledge_types' );

Core relies only on the semantics of the built-in slugs it ships. Plugin types are free to define their own behavior.

Guideline scopes

Guideline scopes define the sections shown in Settings โ†’ Guidelines and the reserved slugs used to address the corresponding guideline records. Core ships scopes such as Site, Copy, Images, and Blocks, each one a guideline record at a reserved slug like guideline-copy. Plugins register additional scopes through a filter, and the Settings page reads the registry through a read-only REST route at /wp/v2/knowledge/guideline-scopes.

Scopes are not knowledge types. The wp_knowledge_type taxonomy answers what kind of record this is (guideline, memory, note). The scope registry answers where a guideline applies in the Guidelines UI. A scope is addressed by its reserved slug, not a taxonomy term, since a term per scope would attach to exactly one record and duplicate identity into a second system.

Privacy, security, and access model

Knowledge records are not exposed as a public index. The post type is registered as an internal storage primitive, not a front-end content type: it is not publicly queryable, and management flows through the Guidelines UI, REST, and registered programmatic surfaces rather than a native public post-type UI. Collection reads require authentication, per-item reads are capability-checked through read_post, and non-publishers can only create private records. New records default to private on creation.

ActorSite-wide guideline recordsOwn private recordsOthersโ€™ private recordsPublish / manage global records
SubscriberNoNoNoNo
ContributorRead where capabilities allowCreate, read, edit, deleteNoNo
Author / EditorRead where capabilities allowCreate, read, edit, deleteNoNo
AdministratorManageYesYesYes

This matrix reflects the access policy from gutenberg#78296 and will be aligned exactly with the final core 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.. The built-in type set is defined in code through a filter, while the underlying taxonomy terms are created lazily when a record is first saved with a given type, so authoring a record can create its term. Revisions are retained, and autosave is disabled, since knowledge records have no editor session.

Testing

Enable the Guidelines experiment in Gutenberg and verify:

  • Settings โ†’ Guidelines renders its sections from the scope registry, and each scope can be edited, revised, and restored through the REST APIREST 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/
  • The scope registry route returns core scopes and plugin-registered scopes
  • A Contributor can create and read only their own private records, and a Subscriber cannot access the post type through REST
  • REST collection reads require authentication, and non-publishers cannot create published records
  • No knowledge records are exposed through front-end public queries

Automated coverage for the controller, capability mapping, and type registry ships with the implementation and will be part of the core patch.

FAQ

Is this an AI-only feature? No. The storage primitive is already used for plain note-taking and draft syncing with no AI involved, and the Guidelines experience serves any multi-author site that wants consistent standards. AI tools are one consumer among several.

Does WordPress now have a โ€œmemory systemโ€? No. Core ships storage with a clear access policy. A memory record is a durable context a user explicitly saved, comparable to a private post. Anything resembling a memory architecture, including relevance ranking, decay, or consolidation, is left to plugins and integration layers by design.

What about existing plugins that store AI context their own way? Nothing breaks. Plugins can keep their own storage or adopt the shared primitive to gain interoperability, revisions, and the capability model for free.

Why core instead of a plugin?ย Because the main value is interoperability. A plugin can store its own knowledge records, but it cannot establish a shared convention for how other plugins, editorial tools, and AI integrations store, protect, revise, and expose that knowledge. Without a core primitive, every integration defines its own architecture and the records cannot reliably interoperate. The footprint stays intentionally small: a post type, taxonomy, capabilities, and REST routes that sit unused until something writes to them, with no public queries, no frontend behavior, and no AI processing by default.

Timeline

The core patch is open for review as wordpress-develop#12201, tracked in Trac #65476. It is backed by the Gutenberg work the feature grew from: the rename to the wp_knowledge namespace and the follow-up that migrates Guidelines to use the improved structure.

The naming and scope model are settled, so this proposal moves forward on that basis unless a blockerblocker A bug which is so severe that it blocks a release. surfaces. The open question is narrower: is the API ready to stabilize for core? The names freeze at WordPress 7.1 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. 1 on July 15, when the post type, taxonomy, REST routes, capabilities, and type slugs become long-term compatibility commitments. Feedback that would block stabilizing for core is most useful in the next three weeks, while there is still room to act on it.

Call for feedback

The questions below are where input matters most before these decisions become core commitments:

  • Is wp_knowledge the right long-term name for the primitive, and are guideline, memory, and note the right built-in type slugs?
  • Are the capability boundaries in the access model correct?
  • Is anything missing that should be settled before these names become core compatibility commitments?

The best places to respond are the comments below, the tracking issue, and the #core-ai channel in 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/.

Props to @aagam94, @artpi, @jason_the_adams, and @jorgefilipecosta for review and feedback on this merge proposal.

#7-1, #guidelines, #knowledge, #merge-proposals

Marin Atanasov 6:22 am on July 7, 2026
Tags: , ,   

The Classic block stays in the inserter for WordPress 7.1

In an earlier post, I announced that the Classic 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. (core/freeform) would be hidden from the inserter by default starting in WordPress 7.1, accompanied by a new 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. and a companion 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..

Iโ€™ve decided to revert this change. The Classic block will continue to appear in the inserter in WordPress 7.1, exactly as it does today. There is no change in behavior for users or developers, and no migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. is required.

What this means

  • The Classic block remains available in the inserter by default. You can insert new Classic blocks through the inserter, block library, and slash commands as before.
  • The wp_classic_block_supports_inserter filter has been removed. Because this change never shipped in a stable WordPress release, the filter has no backward-compatibility footprint; there is nothing to migrate away from.
  • The block-level deprecation/migration notice has been removed. The Classic block editing experience returns to what it was previously, including the โ€œConvert to blocksโ€ toolbar action.
  • The Enable Classic Block plugin will be closed. With the default behavior restored, the plugin no longer serves a purpose. If you installed it, you can safely deactivate and remove it; no action is otherwise needed.

Why it is being reverted

After discussing this with a number of people and gathering feedback from different places, it became clear that this approach had things largely backward. Itโ€™s one step that makes the experience worse with no direct gain, and it doesnโ€™t really get us any closer to transparently not loading TinyMCE. One of the takeaways is that the Classic block should become obsolete by choice, not by force. I believe time will be better spent to make the alternative genuinely better, while also smoothly, losslessly migrating content, so that users move off Classic block because they want to, not because the door has been removed.

Where the effort goes next

Much of the groundwork from this effort remains valuable, and the intention is to keep pursuing it from a user-first angle:

  • Understanding more in-depth why users still rely on Classic and bridging those gaps
  • Make โ€œConvert to Blocksโ€ flawless โ€“ it still has a bunch of flaws and inconsistencies
  • Work on better and more intuitive conversion/migration mechanisms, including mass migration
  • Improve TinyMCE asset registration and allow it to be disabled under various circumstances.
  • Build a mechanism for declaring proper explicit dependency on TinyMCE and work with plugins to utilize it.
  • Continue exploring ways to load TinyMCE on demand / asynchronously, among other performance improvements
  • Not loading TinyMCE on the block editor if the Classic Block is disabled from the block manager

Thank you to everyone who shared feedback and helped course-correct here. This work continues, pointed more squarely at whatโ€™s best for users.

Props to @mamaduka for reviewing this post.

#7-1, #dev-notes, #dev-notes-7-1

Marin Atanasov 8:34 am on June 23, 2026
Tags: , ,   

Hiding the Classic block from the inserter in WordPress 7.1

Note: this decision was reverted. You can read more about it in the new dev note.

Weโ€™ve just merged a change that will be part of WordPress 7.1 that hides the Classic 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. from the block inserter by default. The Classic block stays registered, every existing Classic block keeps working and remains editable, and a new 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. lets anyone bring it back into the inserter. This post explains what changes, why, and how to opt back in if needed.

Whatโ€™s changing

Starting in WordPress 7.1, the Classic block (core/freeform) no longer appears in the block inserter (#11712, Trac #65166, originally #77911 in 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/). In practice, this means you canโ€™t add a new Classic block from the inserter, the block library, or slash commands.

Nothing else about the block changes:

  • The Classic block remains registered.
  • All existing Classic blocks (including any <!-- wp:freeform --> content) continue to render and stay fully editable, exactly as before.
  • The Classic editor and the underlying TinyMCE experience are untouched. If a post type doesnโ€™t use the block editor, nothing here applies to it.

This is purely about steering new content away from the legacy Classic block, not about removing anything you already have.

To be clear: the Classic editor is not affected at all by this change. This is strictly about the Classic block inside the block editor. If you use the Classic editor (for example, via the Classic Editor pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. or on post types that donโ€™t use the block editor), your experience stays exactly the same.

Why weโ€™re doing this

The Classic block has been the bridge from the pre-block era into the block editor, and it has served that role well. But itโ€™s also the one block in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. that doesnโ€™t behave like a block:

  • Architectural consistency. Every other Core block is a node in the block tree. The Classic block is the lone exception, opaque HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. rendered through a separate editor embedded inside the block editor. Keeping it as a default inserter option works against the block-first model on which the editor is built.
  • Reducing the inflow. The migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. path away from Classic content (Convert to Blocks) has existed for years, and Classic usage keeps shrinking. Hiding the block from the inserter stops new Classic content from being created, so that set keeps getting smaller rather than growing.
  • Maintenance leverage. Many block-library improvements have to special-case the Classic block. Each special handling may be small on its own, but cumulatively, this may slow down work that benefits every other block.

The broader, longer-term goal, which will be covered separately as it matures, is to make the Classic block fully opt-in and eventually to lay the groundwork for loading TinyMCE only when itโ€™s actually needed. WordPress 7.1 is just the first user-facing step on that path. None of the later steps are happening in 7.1, and each will get its own discussion and dev notedev 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..

Opting back in

If you (or your users) still want the Classic block available in the inserter, thereโ€™s a dedicated filter: wp_classic_block_supports_inserter.

Return true to show it everywhere:

add_filter( 'wp_classic_block_supports_inserter', '__return_true' );

The filter also receives the post being edited, so you can make the decision conditional, for example, per post type:

add_filter(
	'wp_classic_block_supports_inserter',
	function ( $supports_inserter, $post ) {
		return 'page' === $post->post_type ? true : $supports_inserter;
	},
	10,
	2
);

If youโ€™d rather not write code, thereโ€™s a small plugin that does exactly this, Enable Classic Block, which flips the filter on for you. The plugin has already been submitted for approval to the WordPress Plugin Directory.

Backward compatibility

This change is opt-out by design and doesnโ€™t break anything:

  • No content is modified or migrated. Existing Classic blocks are left exactly as they are.
  • The block, its edit behavior, and the Convert to Blocks action all continue to work.
  • The core/freeform block remains registered, so any code that relies on it being present keeps functioning.
  • Restoring the previous behavior is a one-line filter (or one tiny plugin) away.

Whatโ€™s next

Alongside this change, weโ€™re investing in the surrounding experience so that moving away from the Classic block is smoother for everyone:

  • A deprecation/migration notice (experimental). Thereโ€™s an experiment in Gutenberg that surfaces a notice inside existing Classic blocks, with one-click actions to convert the content to blocks or to a Custom HTML block. Weโ€™re exploring this as a gentle way to highlight that the Classic block is being phased out and to make the migration path more discoverable. Itโ€™s behind an experiment flag for now while we refine it for a WordPress release.
  • Improving everything around it. In parallel, weโ€™re improving and fixing the pieces that live by the Classic block: the Custom HTML block, the Convert to Blocks path, freeform handling and conversion, and related compatibility layers. The goal is that by the time Classic content needs to move, the tools to move it are solid.

These, alongside other planned next steps, can be tracked in the dedicated tracking issue.

Weโ€™d love your feedback

This is an early step in a longer effort, and we want to get it right. If you maintain plugins or custom integrations, run large sites, or have workflows that depend on the Classic block, weโ€™d really like to hear from you, especially around migration and bulk-conversion needs.

Props to @desrosj, @mamaduka, @mukesh27, @westonruter, @wildworks, and @yuliyan for the contributions, feedback, and code reviews.

Props to @mamaduka and @yuliyan for reviewing this post.

#7-1, #dev-notes, #dev-notes-7-1

Jeffrey Paul 5:04 pm on May 21, 2026
Tags:   

WordPress 7.1 Call for Volunteers

Planning is underway for WordPress 7.1!ย  This post outlines the proposed schedule along with a call for volunteers to support the release process.

Following the typical cadence, the proposed final release date for 7.1 is Wednesday, August 19, 2026.ย  This proposed timeline remains flexible for the resulting Release Squad and adjustments can be made if necessary as they determine what timeline works best for their schedule.

Proposed Schedule

MilestoneDate
Alpha BeginsImmediately (7.1-alpha began in trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. on March 27th with [62161], closed then re-opened)
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. 1Wednesday, July 15
Beta 2Wednesday, July 22
Beta 3Wednesday, July 29
Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1Wednesday, August 5
Release Candidate 2Wednesday, August 12
Dry RunTuesday, August 18
Final ReleaseWednesday, August 19

As always, all dates are subject to change based on development progress.

Call for Volunteers

Each WordPress release depends on contributors from across the project coming together to make it a success.ย 

As with the 6.7, 6.8, 6.9, and 7.0 release cycles, WordPress 7.1 will continue the approach of forming a smaller, focused Release Squad based on feedback received.ย  This streamlined structure places more emphasis on collaboration with the various Make Team Reps, who are encouraged to help coordinate efforts from within their respective teams.ย  The goals are to reduce the overhead on the Release Squad while still ensuring each teamโ€™s contributions and priorities are represented throughout the cycle, and to reduce overlap between a Make Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. and that teamโ€™s Release Squad Leads.ย  Noteworthy Contributors will be captured from Team Reps towards the end of the release cycle.

While the end goal is to publish the final release of WordPress 7.1 at WordCamp US, traveling to or attending 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. US is not a requirement to serve on the release squad.ย  All communication related to the release process will continue to take place 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.

If you are interested in helping lead WordPress 7.1 in one of the following roles, please comment below or reach out in the #7-1-release-leads Slack channel:

  • Release LeadRelease Lead The community member ultimately responsible for the Release. โ€“ sets overall goals, makes final decisions on merging, gives final reviews where needed
  • Release Coordination โ€“ helps manage timelines, cross-team collaboration, and status updates
  • Tech Leads โ€“ oversees coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development (including 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/), triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors., and critical issues
  • Triage Lead โ€“ help monitor issues, shepherd patches, and guide contributors
  • Test Lead โ€“ coordinates testing efforts across the community and test reports

Whether you have led a release before or are looking to get involved for the first time, there are many ways to contribute.ย  Volunteers of all backgrounds and experience levels are welcome!

If you are interested in volunteering, please leave a comment below noting your preferred area(s) by Friday, June 5th.ย  @4thhubbard (or a designee), will review the nominations shortly after to confirm and announce the release squad as soon as possible.

Together we can make WordPress 7.1 the best one yet!

Props to @jorbin @4thhubbard for reviewing this post.

#7-1

Benjamin Zekavica 8:03 am on July 3, 2026
Tags: ,   

WordPress 7.1 Release Party Schedule

WordPress 7.1 is scheduled for release on August 19, 2026! Below is the proposed calendar with expected start times for each release party, and the release squad contributors involved in release parties for the upcoming 7.1 milestone.

This release party schedule will stay in effect during the Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). phase and the final release of WordPress 7.1. This enables contributors to attend and assist with release testing during the final weeks of the release cycle.

As always, there may be last-minute adjustments. The release squad will do its best to communicate any changes promptly by publishing a post on the change, and updating this post as the canonical reference.

Join us for the 7.1 release parties in the #core channel on the Making WordPress Slack!

Release Schedule

Date (UTC)MilestoneEmcee / Release LeadRelease Lead The community member ultimately responsible for the Release.Committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component.SecurityMission Control (Coordination)
July 15, 2026 at 15:00 UTCBetaBeta 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. 1@krupajnanda@wildworks@joedolson@sergeybiryukov
July 22, 2026 at 15:00 UTCBeta 2@krupajnanda@wildworks@joedolson@sergeybiryukov
July 29, 2026 at 15:00 UTCBeta 3@benjamin_zekavica@wildworks@joedolson@sergeybiryukov
August 5, 2026 at 15:00 UTCRCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1@benjamin_zekavica@wildworks@joedolson@sergeybiryukov
August 12, 2026 at 15:00 UTCRC 2@krupajnanda@wildworks@joedolson@sergeybiryukov
August 18, 2026 at 15:00 UTCDry Run / 24-Hour Code Freeze@benjamin_zekavica @krupajnanda@wildworks@joedolson@sergeybiryukov
August 19, 2026 TBDGeneral Release@benjamin_zekavica @krupajnanda@wildworks@joedolson@sergeybiryukov

How to Join the Party

  • 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.
  • The final General Release will happen during 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. US 2026.
  • Everyone is encouraged to attend WordCamp US, but traveling and attending the event is not required to participate in the General Release Party. The release party will still happen in the #core channel on Slack.

Here are detailed instructions on how to contribute to a release party.

Thank you to every contributor and community member that helps make 7.1 a success. See you at the parties!

Props to @krupajnanda and @amykamala for collaboration and peer review.

#7-1, #release