Call for 6.8.x Release Managers

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

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

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

Since 6.9 is not currently scheduled until 2026, we are not asking folks to lead minor releases for 9+ months. Rather, we are looking for folks who could help lead for shorter periods of time, like 3 months. If folks are able to lead for a longer period of time, that’s wonderful, but we expect to rotate folks in and out every 3 months so that no single person has to shoulder the work through to the next major release.

If you are interested in volunteering to be a release manager for the 6.8 maintenance releases, please comment on this post.

Thanks to @jeffpaul, @jorbin, @joedolson for reviewing this post before publication.

WordPress 6.8 will use bcrypt for password hashing

Note: This article has been updated with additional technical information about the structure of password hashes that may be relevant to developers of plugins that directly handle them.

The underlying algorithm that’s used to hash and store user passwords in the database will be changed in WordPress 6.8 from phpass portable hashing to bcrypt. The adoption of bcrypt hardens password security in WordPress by significantly increasing the computational cost of cracking a password hash.

In addition, application passwords, user password reset keys, personal data request keys, and the recovery mode key will switch from using phpass to the cryptographically secure but fast BLAKE2b hashing algorithm via Sodium.

No action needs to be taken by site owners or users as a result of these changes. Passwords and security keys that were saved in prior versions of WordPress will continue to work after updating to 6.8. Users don’t need to change or reset their passwords, logged in users will remain logged in, and their sessions will remain valid.

When a user first subsequently logs in after the update – or when they next change their password – their password will automatically get rehashed with bcrypt and resaved in the database. Application passwords and security keys will not get automatically rehashed, but an existing hash will remain valid if it was generated prior to WordPress 6.8 and used before it expires.

Note that post passwords will continue to use phpass portable hashing for now. This may change in the future after further investigation has been done on how best to improve the hashing and checking mechanism of post passwords.

Portability

Hashes that are generated by the phpass portable hashing algorithm are portable between different sites, environments, and servers. This portability doesn’t change with this switch to bcrypt and BLAKE2b, so you can move your database from one server to another and update to newer versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher and WordPress and the password hashes will continue to function as expected.

Updates to password handling functions

The wp_hash_password() and wp_check_password() functions have been updated to use the PHP native password_hash() and password_verify() functions with the bcrypt algorithm and SHA-384 pre-hashing. Both functions retain support for the $wp_hasher global object in case that’s being used to implement an alternative hashing mechanism.

The wp_check_password() function retains support for passwords that were hashed using phpass, which means existing password hashes won’t be invalidated.

A new wp_password_needs_rehash() function has been introduced as a wrapper for password_needs_rehash(). If 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 needs to adjust its logic then the password_needs_rehash 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. can be used. The function is also pluggable, so it can be overridden if absolutely necessary.

Pre-hashing with SHA-384 is implemented in order to avoid the 72 byte length limit imposed on passwords by bcrypt. Password hashes are therefore stored with a $wp prefix to distinguish them from vanilla bcrypt hashes which may be in use via a plugin. By default this means the full prefix will be $wp$2y$.

New fast hashing functions

The following functions have been introduced as wrappers for the cryptographically secure but fast BLAKE2b algorithm via Sodium:

  • wp_fast_hash()
    Used to hash a string that is randomly generated using sufficiently high entropy, preferably over 128 bits for values that don’t have a corresponding expiry mechanism.
  • wp_verify_fast_hash()
    Used to verify a hash generated via wp_fast_hash(), with fallback support for phpass portable hashes.

Do developers need to do anything?

Code that calls wp_hash_password() and wp_check_password() will continue to work as expected and does not need to change.

Code that directly handles phpass hashes may need to be updated, for example:

  • Code that assumes the existence of the $P$ prefix on hashes. The code will need to be updated so it either doesn’t need to inspect the prefix of the hash at all, or updated to handle both the new prefixes and hashing algorithms and legacy hashes:
    • The $wp$2y$ prefix will be the new default for user passwords in WordPress and represents a SHA-384 pre-hashed bcrypt hash.
    • The plain $2y$ prefix may be used by existing plugins that use bcrypt hashes without pre-hashing.
    • The $generic$ prefix for a BLAKE2b hash used for application passwords and security keys.
    • A hash starting with $argon2 if a site opts in to using an Argon2 algorithm (see below). Note that any non-bcrypt algorithm won’t use pre-hashing and therefore won’t include $wp at the start of the prefix.
    • The old $P$ prefix for a phpass portable hash which will remain in wide use.
    • A legacy plain MD5 hash, which is a 32 character hexadecimal string.
  • Code that otherwise directly interacts with the hashed value of a user password. If such hashes are validated directly, this should be done via wp_check_password().
  • Code that otherwise directly interacts with the hashed value of an application password, password reset key, personal data request key, or the recovery mode key. If such hashes are validated directly, this should be done via the new wp_verify_fast_hash() function.
  • Any plugin that overwrites the pluggable wp_hash_password() and wp_check_password() functions. Unless these functions specifically implement another hashing algorithm, they can be removed in order to allow the bcrypt implementation in 6.8 to take effect.

Alternative authentication mechanisms such as single sign-on (SSO), social login, or one-time login are unlikely to be affected by this change, however you should still verify whether your specific implementation includes any handling of password hashes or security keys. Multi-factor (MFA and 2FA) implementations are also unlikely to be affected by this change.

What about Argon2?

Servers that support Argon2 can enable its usage with this single line of code in WordPress 6.8 and later:

add_filter( 'wp_hash_password_algorithm', fn() => PASSWORD_ARGON2ID );

If necessary, the password_algos() function should be used to first check for argon2id support. Unfortunately it’s not possible to rely on Argon2 being available on all servers because it requires both libargon2 to be available on the server and for PHP to be built with Argon2 support enabled. The sodium_compat library does not provide an implementation of Argon2.

Acknowledgements

We can’t pretend that switching to bcrypt for user-generated passwords is a recent proposal. Ideally the switch would have been made back when the increase to the minimum supported version of PHP facilitated this change. However, this change has now been made and it helps future-proof further improvements to password hashing, including increases to the bcrypt cost in newer versions of PHP.

Many thanks go to the Roots team for maintaining their bcrypt password hashing package for WordPress as well as the many contributors on the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets and 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 be the repository owner. https://github.com/ pull requests.

Further technical information

Further technical information, technical FAQs, and implementation details can be seen on the GitHub pull request for this change and in the discussion on the Trac ticket.

In case you need to know:

  • User passwords are stored as a hash in the wp_users.user_pass field in the database.
  • Application passwords are stored as a hash in a 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. serialized object in the wp_usermeta table using the _application_passwords key.
  • User password reset keys are stored as a hash in the wp_users.user_activation_key field in the database.
  • Personal data request keys are stored as a hash in the wp_posts.post_password field in the database against the post that represents the personal data request.
  • The recovery mode key is stored as a hash in the recovery_keys option in the wp_options database table.

Thanks to @desrosj and @joehoyle for helping review this post.

#6-8, #dev-notes, #dev-notes-6-8

Miscellaneous developer changes in WordPress 6.8

WordPress 6.8 delivers a broad set of developer-focused enhancements that improve extensibility, consistency, and modern standards across the platform. These updates include changes to shortcodes and media handling, expanded theme and blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. support, improved adminadmin (and super admin) validation and hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same., and fine-tuned control over post type registration and scheduling APIs. While these updates may not individually warrant their own developer note, they collectively represent important refinements 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, theme, and site developers working with WordPress under the hood. This post rounds up the miscellaneous changes worth knowing as you prepare your code for WordPress 6.8.


Table of contents


Removed option to disable the Visual Editor from user profile settings

The option to disable the visual editor was used to enforce the usage of the text interface in the classic editor. This setting was removed in #34681. The setting is removed conditionally; if you have it enabled, it will remain enabled and editable until it is disabled for a user.

The text editor will continue to be an option for all users. $user->rich_editing continues to be a valid user profile field, and the visual editor can be disabled by toggling that value to false.

Example code:

update_user_option( $user_id, 'rich_editing', 'false' );


Changed WP_Image_Editor::generate_filename( $suffix ) to allow empty string as a suffix

The previous  implementation of the WP_Image_Editor::generate_filename() method automatically appended a dimension suffix (e.g., -600×800) to the file name when no $suffix is provided, or when it is any “falsey” value (e.g., null or false). 

With the addition of image format switching like the switch from .heic to .jpg added in #62359, it became more apparent that there was a need to create copies of files without changing their file names.

In #62385, the behavior of this method was changed to accept an empty string as an intentional value for $suffix. The method will treat false or null as empty values where a dimension suffix should be generated; but will treat an empty string as the desired value for the suffix.

The default function value remains null

For extenders, if you are passing a value into the generate_filename() that could be an empty string, you should ensure that the variable type is null or bool to keep your method behavior unchanged.


In #60969, validation was added to the classic menu administration when adding custom links. This validation matches the existing validation used in the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. when adding custom links. It is a partial validation, checking for the following structures:

 * – http://example.com/

 * – //example.com

 * – /directory/

 * – ?query-param

 * – #target

 * – mailto:foo@example.com

If your use case requires content in a custom link’s href attribute that is not a generally valid URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org pattern, it may no longer be accepted.


New action hook in Import administration screen

A new action hook, import_filters, has been introduced to the Import administration screen (/wp-admin/import.php). This enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. allows developers to execute custom functions at the end of the importers page, aligning its extensibility with other administration screens like Tools. The hook is implemented as follows:

/**
 
* Fires at the end of the importers Administration screen.
 
 */
 
do_action( 'import_filters' );

This addition provides a standardized method for extending the importers page, facilitating the integration of custom functionalities. For more details, refer to #54419.


Update to wp_video_shortcode() HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. attributes

The wp_video_shortcode() function has been updated to generate valid HTML by properly handling boolean attributes. Previously, attributes like loop, autoplay, and muted were assigned a value of "1", leading to HTML validation errors. Now, these attributes are rendered without values, aligning with HTML specifications for boolean attributes. For instance, the loop attribute will now appear as loop instead of loop="1". This change ensures that video elements produced by the shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. are semantically correct and pass HTML validation. For more details, refer to #60178.


Update to wp_audio_shortcode() HTML Attributes

The wp_audio_shortcode() function has been updated to generate valid HTML by properly handling boolean attributes. Previously, attributes like loop, autoplay, and muted were assigned a value of "1", leading to HTML validation errors. Now, these attributes are rendered without values, aligning with HTML specifications for boolean attributes. For instance, the loop attribute will now appear as loop instead of loop="1". This change ensures that audio elements produced by the shortcode are semantically correct and pass HTML validation. For more details, refer to #61515.


New embeddable argument for register_post_type()

A new embeddable argument has been introduced to the register_post_type() function, allowing developers to control the embeddability of custom post types. By default, this parameter inherits its value from the public argument, ensuring that publicly accessible post types remain embeddable unless explicitly specified otherwise. This enhancement provides greater flexibility in managing content embedding, enabling developers to restrict embedding for specific post types as needed. For more details, refer to #35567.


Updates to body_class classes

Some new classes were introduced to the <body> 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.).

The classes wp-theme-<name> and wp-child-theme-<name (when the current theme is a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/.) were added, where <name> represents the sanitized name of the active theme. Please note that these classes are added on both front-end and in the administration. For more information, refer to #19736.

The wp-singular class was added to the list of body classes when viewing a single post object. This class includes a wp- prefix to avoid conflicts with existing classes in themes or plugins. For more information, refer to #35164.


readme.html file is now noindex,nofollow

Because site owners likely don’t intend for the content of the readme.html file to be indexed, as it’s unrelated to the site content. A noindex,nofollow 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. tag was added to this file, to prevent it from being indexed. Polyglot teams that are translating this file manually are encouraged to update their version. For more information, refer to #63069.


Style Book availability for classic themes

The Style Book feature has been extended to support classic themes. This enhancement allows developers and users to preview and understand site colors, typography, and block styles within the context of their classic themes. To utilize the Style Book in a classic theme, ensure that the theme either:

  • Supports editor styles: Implement this by adding add_theme_support( 'editor-styles' ); in the theme’s functions.php file.
  • Includes a theme.json file: Incorporate a theme.json configuration file to define global styles and settings.

By adopting either of these methods, classic themes can leverage the Style Book’s capabilities, providing a more consistent and customizable editing experience.

For detailed guidance on integrating theme.json into classic themes, refer to the Global Settings & Styles (theme.json) – Block Editor Handbook. Additionally, the tutorial “Using theme.json with classic themes” offers practical insights and examples. These resources provide comprehensive information on enhancing classic themes with modern styling capabilities. For more information, refer to #62509.


Enabling Block Hooks for post content

The Block Hooks mechanism has been extended to apply to post content, in addition to its existing support for templates, template parts, patterns, and navigation menus. This enhancement allows developers to insert hooked blocks directly into posts and pages, offering greater flexibility in content customization.

Key considerations:

  • User expectations: Aligns block insertion capabilities with user expectations across various site components.
  • Content management: Introduces the ability to manage hooked blocks within individual posts and pages, enhancing content control.

This update provides developers with expanded tools for dynamic content placement, improving the customization capabilities. For more information, refer to #61074.


Block Hooks enabled for Synced Patterns

The Block Hooks feature has been extended to support synced patterns (i.e., core/block blocks). Previously, Block Hooks were applied to templates, template parts, patterns, navigation menus, and post content. This enhancement ensures consistent behavior across all these entities, allowing developers to insert hooked blocks into synced patterns seamlessly. This update provides greater flexibility and control over content customization within the WordPress ecosystem. For more information, refer to #62704.


Standardized behavior for render_block_context 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 behavior of the render_block_context filter has been standardized to ensure consistent application across all block levels. Previously, this filter applied differently to top-level blocks compared to inner blocks, leading to inconsistencies in context propagation. Specifically, context provided via render_block_context was available to inner blocks when applied to top-level blocks, but not when applied to inner blocks.

This discrepancy has been addressed, ensuring that context supplied through the filter is uniformly available to all nested inner blocks, regardless of their position within the block hierarchy. For more information, refer to #62046.


Cron 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.: Introduce a new filter of the same name to wp_next_scheduled()

The wp_next_scheduled hook allows plugin developers to modify the timestamp of the next scheduled event for a given wp-cron job. The full event object, hook name and arguments are provided as additional arguments for this filter. Fore more information, refer to #52655.


HDR Image support for Imagick: new filter to control maximum bit depth of resized images

WordPress 6.8 introduces a new filter, image_max_bit_depth, that developers can use to control the maximum bit depth for resized images. The filter is also passed the original bit depth of the uploaded image. Note that this filter only works when the site’s hosting supports Imagick and coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is using the Imagick editor because the GD image editor does not support reading or controlling bit depth (#62285).

By default, the maximum depth matches the bit depth of the original uploaded image. Previously, the maximum bit depth was reduced to 8 for images with higher bit depths, so HDR images were always output with reduced bit depth. Starting in 6.8 HDR images will be output with the bit depth they are uploaded with (for example 12 bits). To enforce the previous behavior, developers can use the following code:

{{{
add_filter( ‘image_max_bit_depth’, function( $max_depth, $original_depth ) { 
	return ( 8 &lt; $original_depth ) ? 8 : $original_depth;
} ); 
}}}

Media: enable setting image output quality by image size

A new $size parameter was added to the wp_editor_set_quality filter. $size is an array with ‘width’ and ‘height’ keys. Developers can use this information to set image quality based on the image size, for example using a lower quality setting for small images (#54648).


Media: control uploading of unsupported media types

In 6.8, a new filter wp_prevent_unsupported_mime_type_uploads controls the behavior of the editor and media library when users upload an image type that the server does not support. By default, users will see an error message that “This image cannot be processed by the web server. Convert it to JPEG or PNG before uploading”. Developers can return false from the filter to enable uploading of these images; however, sub-sized images will not be created (#61167).


UPDATE (14 April 2025): Updated is_embeddable to embeddable for 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. on #35567. Props @mat-lipe.

UPDATE (14 April 2025): Updated after_importers to import_filters for dev note on #54419. Props @afercia.


Props to @joedolson @audrasjb @webcommsat @joemcgill @benjamin_zekavica @peterwilsoncc @adamsilverstein @azaozz for input and review.

#6-8, #dev-notes, #dev-notes-6-8

Dev Chat Agenda – April 17, 2025

The next WordPress Developers Chat will take place on Wednesday April 16, 2025 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.

Additional items will be referred to in the various curated agenda sections below. 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.

Announcements 📢

WordPress 6.8 “Cecil” is now available! 🐣

WordPress 6.8 was released as scheduled and it was named after the legendary jazz pianist Cecil Taylor.

For now, 6.8 is identified as the last major release of the year.

Forthcoming releases 🚀

WordPress 6.8.1

@jorbin proposed to lead the next 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. and to host a first 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. scrub right after the devchat.

WordPress 6.9

No ETA at the moment.

Highlighted posts ✨

Discussions 💬

The discussion section of the agenda is to provide a place to discuss 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.

  • WordPress 6.8.1:
    • Is there any 6.8 release leadRelease Lead The community member ultimately responsible for the Release. who want to help releasing 6.8.1? Any new person who want to be onboarded on this first post-6.8 release?
  • WordPress 6.8.x:
    • @audrasjb suggests a discussion about how to handle tickets currently located in milestone 6.9 and how to dispatch them (when needed) in the next 6.8.x minor releases: should bug gardeners and component maintainers move them to minor releases related milestones? Should we have dedicated bug scrubs? Should we open 6.8.2 and 6.8.3 milestones right now?
    • Given the 6.8.x cycle is going to be quite long, should we publish a call for release leads for the next coming months?
  • Handbook improvements:
  • Minor topic: Time permitting, @audrasjb would like to start a discussion about how contributions are taken into account.

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.

PHP 8 support clarification

tl;dr: Use of the “compatible with exceptions” label for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 8 support has been retired and has been retroactively removed from all versions. WordPress 6.3 and later is now documented as fully supporting PHP 8.0 and 8.1, and WordPress 6.6 and later is now documented as fully supporting PHP 8.2. Support for PHP 8.3 and 8.4 remains in 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. as of WordPress 6.7 and the upcoming 6.8.

WordPress has supported PHP 8 since version 5.6 back in 2020, but due to the acknowledgement that WordPress is rarely used in isolation (without any theme or plugins) this support has been labelled as “beta support”, and later as “compatible with exceptions” following the guidelines that were adopted as a result of the proposal for criteria for removing the “beta support” label from each PHP 8+ version.

In order to provide clarity and confidence to users and to encourage web hosts and users to continue updating to the latest versions of PHP, use of the “compatible with exceptions” label has now been retired. Documented support for any given version of PHP will now go straight from “beta support” to fully supported once the agreed criteria for removing that label have been met. The label has been removed retroactively from all versions.

PHP compatibility of all WordPress versions is documented here in the handbook and has been updated to reflect this change.

What prompted this change?

The criteria for removing the “beta support” label were adopted in 2023 just prior to the release of WordPress version 6.3. In that version a significant amount of work was done to resolve remaining PHP compatibility issues and to switch to using the “compatible with exceptions” label for PHP 8.0 and 8.1. The same was done in WordPress 6.6 for PHP 8.2, and the number and significance of these documented compatibility exceptions is now very low.

Since then it’s become apparent that some end users and web hosts remain reluctant to update to PHP 8 when the documented support in WordPress is still labelled as “compatible with exceptions”, despite the actual support being complete as far as most sites are concerned (over 60% of WordPress sites run PHP 8+). The label has served its purpose over the last 18 months but now risks being detrimental to the continued adoption of newer versions of PHP.

Removing this label — while still documenting the exceptions where necessary — will help continue the adoption of newer and fully supported versions of PHP and provide confidence to the remaining 40% of sites to update.

What are the criteria for removing the “beta support” label?

These criteria have not changed. The criteria are:

  • Enough sites: At least 10% of all WordPress sites running on a specific or newer PHP version for at least 3 months.
  • Issues:
    • All reported and known compatibility issues are resolved.
    • All accepted incompatibilities are documented as exceptions from full compatibility.
  • BC: Full backward compatibility is maintained for all older PHP versions WordPress supports, demonstrated with automated tests for each compatibility change.

Usage of PHP 8.3 and higher is at 8.9% of all WordPress sites as of April 2025. Once this surpasses 10% and assuming no further compatibility issues are reported then it’s expected that the beta label for PHP 8.3 support will be removed in the subsequent 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.

What’s the minimum supported version?

The minimum supported version of PHP remains unchanged at 7.2.24+.

Props to @desrosj @joemcgill @garyj for input on this change.

#php, #php-8-0, #php-compatibility

More efficient block type registration in 6.8

WordPress 6.8 introduces a new function wp_register_block_types_from_metadata_collection(), which allows plugins to register multiple 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. types with a single function call.

This function expands on the foundational capabilities of the wp_register_block_metadata_collection() function, which was introduced in WordPress 6.7 to improve performance.

Context

To recap the relevant functionality added in WordPress 6.7:

Plugins can now optionally register a PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher “manifest” file, which includes all the metadata for their block types. For any block type that is being registered, WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. will now check whether such a manifest file is present covering the block type, and if so, it will use the data from the manifest file instead of reading and parsing the block type’s 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. file directly.

Since the blocks manifest file includes all the block type names, a logical next step after adding support for such a file is to make the requirement for individual block type registration calls obsolete. This is what the new  wp_register_block_types_from_metadata_collection() function implements.

Benefits

By using the new function, you no longer need to add individual register_block_type() calls for every block type that you include in your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. This improves developer experience, especially when using the latest block development best practices where the block.json file is used as the sole entrypoint for both PHP (server-side) and 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/. (client-side). Adding a new block type to an existing plugin is now possible by creating the block’s directory and working exclusively within that directory. You no longer need to remember to register the block type somewhere else in the PHP codebase of the surrounding plugin.

Example

Let’s say you have a plugin with 5 custom block types: “accordion”, “carousel”, “carousel-slide”, “dialog”, and “icon-button”. At the present, this means your plugin’s PHP code may look like this:

$block_types = array( 'accordion', 'carousel', 'carousel-slide', 'dialog', 'icon-button' );
foreach ( $block_types as $block_type ) {
	register_block_type( __DIR__ . "/build/{$block_type}" );
}

With WordPress 6.8, you can now use the wp_register_block_types_from_metadata_collection() function to eliminate the need for the list of block types in the PHP code so that all block types are recognized and registered automatically.

To do that, you need to generate a manifest file for your block types. You can use the build-blocks-manifest command or the --blocks-manifest argument of the build command from the @wordpress/scripts NPM package, which was also explained in the relevant WordPress 6.7 dev note. It can be easily integrated into your build process by changing the scripts in your package.json file as follows:

  • Change the “build” script from wp-scripts build to wp-scripts build --blocks-manifest.
  • Change the “start” script from wp-scripts start to wp-scripts start --blocks-manifest.

With the generated manifest in place, the PHP code above can be simplified to no longer require a hard-coded list of block types:

wp_register_block_types_from_metadata_collection(
	__DIR__ . '/build',
	__DIR__ . '/build/blocks-manifest.php'
);

Backward compatibility with older WordPress versions

As the wp_register_block_types_from_metadata_collection() function is only available in the latest WordPress 6.8 release, you may still want to support older WordPress versions. Fortunately, the function can be easily replaced by a few lines of codeLines of Code Lines of code. This is sometimes used as a poor metric for developer productivity, but can also have other uses., as long as you have a generated blocks manifest in place as described above.

Here is a code example that uses the respective best practices for WordPress 6.8, WordPress 6.7, and older versions:

if ( function_exists( 'wp_register_block_types_from_metadata_collection' ) ) {
	wp_register_block_types_from_metadata_collection( __DIR__ . '/build', __DIR__ . '/build/blocks-manifest.php' );
} else {
	if ( function_exists( 'wp_register_block_metadata_collection' ) ) {
		wp_register_block_metadata_collection( __DIR__ . '/build', __DIR__ . '/build/blocks-manifest.php' );
	}
	$manifest_data = require __DIR__ . '/build/blocks-manifest.php';
	foreach ( array_keys( $manifest_data ) as $block_type ) {
		register_block_type( __DIR__ . "/build/{$block_type}" );
	}
}

The @wordpress/create-block NPM package has been enhanced to use the new functions conditionally, using a similar code snippet as shown above.

Summary and further reading

The new wp_register_block_types_from_metadata_collection() function is a very simple but neat way to eliminate individual block type registration calls from your PHP code, allowing you to focus exclusively on working on the block types in your plugin without having to modify anything else in the plugin.

Please see the following links for further reading:

  • 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. #62267
  • Relevant WordPress 6.7 dev note about the previous block type registration enhancements

Props to @gziolo, @stevenlinx for review and proofreading.

Update (2025-04-16): As of @wordpress/scripts version 30.14.0, a bug regarding blocks manifest generation was fixed. This post was updated accordingly to recommend the --blocks-manifest argument of the build command in the NPM scripts to use instead of the build-blocks-manifest command in combination with other commands.

#6-8, #dev-notes, #dev-notes-6-8

Dotorg Core Committers Check In

On March 27, 2025 nearly 30 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers, project leaders, and core team members gathered to discuss the release cadence and if there is a need to change it. The impetus for this conversation is due to organizations cutting back on the number of hours they are donating towards contributing to WordPress.

Attendees: @matt, @desrosj, @jorbin, @timothyblynjacobs, @davidbaumwald, @jjj, @clorith, @jeffpaul, @joemcgill, @kadamwhite, @fabiankaegy, @4thhubbard, @adamsilverstein, @swissspidy, @whyisjake, @spacedmonkey, @eidolonnight, @matveb, @audrasjb, @mamaduka, @karmatosed, @sergeybiryukov, @westonruter, @ryelle, @flixos90, @williampatton, @poena, @johnbillion, @joedolson.

An assessment of core team activity shows the number of both 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/ tickets and Core TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets remaining nearly flat over the last 6 months. However, the volume of new features being worked on inside the Gutenberg repository has plunged since January. In light of this information, the discussion focused on if the current release cadence should be reduced.

Numerous pros and cons were discussed.

The pros included:

  • Aligns WordPress with the release cadence that is becoming en vogue amongst some large organizations such as eBay and Airbnb
  • Can use this change to signal an intentional reset and focus on quality
  • Allows for greater focus on canonical plugins and on individual component roadmaps, which can be iterated on and shipped independent of major releases.
  • Slowing down helps allow for documentation and any needed infrastructure improvements.
  • Allow for each release to contain larger features and enhancements and not be “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. fix only” releases.
  • Reduces the workload and coordination overhead for contributors, systems team, and release leads.
  • Allows for work to further automate release processes, making future releases quicker and less manual.

The cons and risks discussed included:

  • Fewer releases can slow down user feedback loops for new features.
  • Slower cadence can lead to contributors not being able to see their work published or feel recognized as quickly.
  • Makes it harder for changes that we may want to roll out over multiple releases
  • Harder to make changes such as coding standard updates that can lead to a release 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". and 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. changing.
  • Potential for anxiety over larger releases from users, site owners, and anyone else applying updates.
  • Potentially harder for organizations to justify time and resources for sponsored contributors.
  • Less visible momentum towards the project’s overall goals, possibly perceiving the project as stale.
  • Care needs to be taken to preserve the culture and trust built in auto-updates that the project has worked hard to build over the last decade.

Proposed Focus Areas

The conversation moved to discussing where contributors could effectively focus their efforts in the project should the release schedule shift to just one release per year.

Canonical Plugins

Community maintained canonical plugins such as Preferred languages, 2FA, and the Performance Team’s suite of plugins are a great way to ship features and iterate without requiring a major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. of WordPress itself. There were two main improvements that need to be addressed to make them more effective.

First is the need for better means to collect user feedback. Active installs is currently the only metric available, but doesn’t provide enough value. Does a user actually interact with the feature? In what ways? Do they feel it’s valuable? Feedback is mainly received from users when something breaks. There was agreement to explore telemetry and ways to establish meaningful feedback loops within canonical plugins.

The second improvement needed is promotion. It’s often not widely known that canonical plugins exist or that they are officially maintained. Different ways to raise awareness about canonical plugins will be explored, including posts on the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ News blogblog (versus network, site), mentioning them in presentations such as State of the WordState of the Word This is the annual report given by Matt Mullenweg, founder of WordPress at WordCamp US. It looks at what we’ve done, what we’re doing, and the future of WordPress. https://wordpress.tv/tag/state-of-the-word/., and possibly the currently barren Tools page in the WordPress adminadmin (and super admin).

Backlog Management

  • Going through the backlog of ~13,000 total tickets on Trac and Gutenberg’s 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 be the repository owner. https://github.com/ repository is something that can be done independent of major releases.
  • The majority of bugfixes can be shipped in minor releases.
  • maybelater' resolution exists for a reason and should be used more often. Discussion can always continue on closed tickets.
  • A large backlog can damage the perception of project quality and maintainability.
  • All numbers are just numbers in isolation. They need to be considered in context with surrounding factors.

Miscellaneous

  • Look for ways to encourage wider testing of 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). releases, and even nightly builds through the initiatives like the Host Tests, and educating developers of the possible advantages of continually using trunk for testing.
  • Reevaluate the Core SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase./Gutenberg repository setup to find ways to streamline the release process.
  • With overall fewer features being built in the Gutenberg repository, shifting the 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’s release cadence to once a month may make sense. Though the current cadence is manageable, mostly automated, keeping this consistent is preferable if volume allows.
  • Encourage component maintainers to be more active by clarifying the responsibilities and expectations of volunteering in that capacity.
  • Release squads should primarily coordinate, encouraging broader autonomy and participation by components and various Make WordPress teams.
  • 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), clarify the differences between mandatory compliance (WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/.) and what non-blocking aspirational best practices are.
  • Explore faster release models once shortcomings in tooling are addressed.
  • Get better at involving contributors with non-development skill sets (e.g., design, testing, product) in more ways.

Summary

In light of these discussions, the current plans of project leadership are for 6.8 (due this month) to be the final major release of 2025. Gutenberg releases will continue on the current every two week schedule and minor releases will take place as needed throughout the year. Minor releases will continue and happen as necessary with a more relaxed barrier for inclusion of enhancements, but the “no new files in minor releases” rule should continue to be followed.

Based on this productive conversation, a decision was made to organize these calls on an ongoing basis starting with a quarterly cadence. I will ensure to schedule accordingly.

Props to @jorbin and @desrosj for collecting the summary and writing this post.

Summary, Dev Chat, Apr 2, 2025

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @benjamin_zekavica. 🔗 Agenda post.

Announcements 📢

WordPress 6.8 | 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). 2 is now available 🥳

The Release Candidate 2 release of WordPress 6.8 is now available! A heartfelt thank you to everyone who joined the Release Party. We appreciate your testing and feedback.

@jeffpaul reminds all CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committers to read this article and follow the outlined process for the upcoming steps: WordPress 6.8 Release Candidate Phase

Help Test 6.8 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. version 🧪

The Test-Team has written two helpful guides for people interested in testing:

Forthcoming releases 🚀

Release Candidate 3: April 8, 2025

The Release Candidate 3 release of WordPress 6.8 will be available on Tuesday, April 8, 2025.

A detailed overview of the release schedule for WordPress 6.8 can be found here. The article also includes information about the individuals assigned to each release party.

Next 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/ version: 20.6

Gutenberg 20.6 is scheduled for release on Wednesday, April 2, 2025.

Next 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.: 6.8

We are currently in the WordPress 6.8 release cycle. Read more about the release squad, timeline and focus for this release.

Highlighted posts ✨

Discussion 🤔

There were no significant topics that we would list in the summary.

Open Floor 💬

PHPDocs Improvements

@sirlouen is requesting a status update on Ticketticket Created for both bug reports and feature development on the bug tracker. #57299 on Core TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., which concerns the improvement of PHPDocs for arrays. The goal is to enhance code quality and developer-friendliness in WordPress.

Style Book Integration

@smrubenstein is asking for advice on handling tab color states. Currently, custom color attributes and slotfill are used for the color inspector, but there’s no clear way to define 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. states like hover or focus. He’s asking how to integrate these into the Style Book and Style Engine so users can set default values.

Github Pull-Request

#6-8, #core, #dev-chat, #summary

Interactivity API best practices in 6.8

WordPress 6.8 comes with a few new best practices and requirements in the Interactivity 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 are part of a longer-term continuous-improvement effort. Some of the relevant changes in 6.8 are an intermediary step: They do not include these enhancements themselves, but they prepare the project to add them in a future release by adding two new deprecation warnings.

If you have been using the Interactivity API in your project, especially if you have been writing your own stores, please read on to learn how you can prepare your changes for the latest and future behavior of the API.

How to apply the latest best practices (and avoid deprecation warnings)

To help the Interactivity API speed up WordPress, the project is working towards running most store actions asynchronously by default, as a better foundation for achieving good INP (“Interaction to Next Paint”) performance. Right now, browsers invoke all synchronous Interactivity API event handlers as part of the same task—this means they stack up. This can make the user wait for longer than 50 milliseconds (also called a “long task”) for the site to reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. to some interaction, like clicking a button.

Starting with 6.8, and going forward, the Interactivity API’s push towards asynchronous handlers as the default will make those long tasks less likely. The 6.8 release only prepares for the transition. In the following WordPress release, the API will automatically yield to the main thread in between handlers, so ideally there’s nothing to stack up, and nothing to make the user wait. (Also refer to async actions and the splitTask() function.)

This performance enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. also helps with cross-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 compatibility, as handlers for the same event may come from different plugins. The new requirements outlined below are an important step to prepare the Interactivity API for that future.

Wrap certain action callbacks in withSyncEvent()

Pay attention to any store action that is attached to an event listener (like data-wp-on--click) and accesses the event object: If the action callback uses any of the event properties or methods below, you need to wrap it in a newly added utility function called withSyncEvent():

  • Property: event.currentTarget
  • Method: event.preventDefault()
  • Method: event.stopImmediatePropagation()
  • Method: event.stopPropagation()

Starting in WordPress 6.8, if any action callback uses the above event properties or methods and is not wrapped in withSyncEvent(), that action callback will trigger a deprecation warning. For now, the logic will continue to work as before. But in a future WordPress release it will break if you do not migrate. For example, event.preventDefault() will not prevent the default action since the action will be asynchronous by default. As such, please make sure to resolve any deprecation warnings you see.

This correct (✅) code example illustrates how to use withSyncEvent():

import { store, withSyncEvent } from '@wordpress/interactivity';

store( 'myPlugin', {
	actions: {
		// `event.preventDefault()` requires synchronous event access.
		preventNavigation: withSyncEvent( ( event ) => {
			event.preventDefault();
		} ),

		// `event.target` does not require synchronous event access.
		logTarget: ( event ) => {
			console.log( 'event target => ', event.target );
		},

		// Not using `event` at all does not require synchronous event access.
		logSomething: () => {
			console.log( 'something' );
		},
	},
} );

This bad (❌) example will, going forward, emit a deprecation warning:

import { store } from '@wordpress/interactivity';

store( 'myPlugin', {
	actions: {
		// Missing `withSyncEvent()` around synchronous event access.
		preventNavigation: ( event ) => {
			event.preventDefault();
		},
	},
} );

Do not use actions to determine HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. attribute values

If you have been relying on Interactivity API store functions (like actions or callbacks) to determine HTML attribute values (e.g. via data-wp-bind--attr), please revise these attributes now. Instead, use global state, local context, or derived state. And please do not combine these function calls with directive logic like the ! operator.

Starting in WordPress 6.8, any directive using a store function in combination with the ! operator will emit a deprecation warning. The logic will continue to work as before for now, but in a future WordPress release it will break if you do not migrate. More broadly, if you are using store functions in directives that determine HTML attribute values, please migrate to using global state, local context, or derived state instead. More deprecation warnings around incorrect usage of store functions are expected soon, and eventually unmigrated code is going to break.

Please refer to the following correct (✅) code example to illustrate how to use derived state:

import { store } from '@wordpress/interactivity';

store( 'myPlugin', {
	state: {
		get isOpen() {
			const ctx = getContext();
			return !! ctx.open;
		},
	},
} );
<div
	data-wp-interactive="myPlugin"
	data-wp-bind--hidden="!state.isOpen"
>
	Content.
</div>

This bad (❌) example will, going forward, emit a deprecation warning:

import { store } from '@wordpress/interactivity';

store( 'myPlugin', {
	actions: {
		isOpen() {
			const ctx = getContext();
			return !! ctx.open;
		},
	},
} );
<div
	data-wp-interactive="myPlugin"
	data-wp-bind--hidden="!actions.isOpen"
>
	Content.
</div>

To provide context on why this new requirement is relevant: Using store functions for anything other than the “on”, “init”, or “watch” groups of directives has always been an anti-pattern. It is now being more formally discouraged, and will in the future be made impossible.

Support for the .length property in directives

An additional Interactivity API enhancement in WordPress 6.8 is support for the .length property on strings and numeric arrays in directives, ensuring consistency between server and client rendering.

Previously, the .length property was unavailable on the server, requiring workarounds. This update allows developers to use .length within all directives that reference global state, local context, or derived state, aligning behavior across environments.

This code example illustrates using the .length property:

<div data-wp-interactive="example">
  <div data-wp-bind--hidden="!state.list.length">
    <input type="range" min="1" data-wp-bind--max="state.list.length">
  </div>
  <div data-wp-bind--hidden="!state.string.length">
    <h1 data-wp-text="state.string"></h1>
  </div>
</div>

This improvement streamlines logic and improves developer experience.

Summary and further reading

Please refer to the following links for further reading:

  • 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 request #68097 for the withSyncEvent and new directive requirement enhancements
  • Gutenberg issues #64944 and #69552 with additional context on the long-term plans to run Interactivity API actions asynchronously by default.
  • Gutenberg issue #69269 with additional context on the long-term plans to more clearly separate directives that do something vs that determine a value.
  • 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. #62582 for support of the .length property.
  • Documentation for understanding global state, local context, or derived state.

Co-authored by @gziolo.
Props to @westonruter, @jonsurrell, @webcommsat, @marybaum for review and proofreading.

#6-8, #dev-notes, #dev-notes-6-8, #interactivity-api, #performance

WordPress 6.8 Field Guide

This guide outlines major developer features and breaking changes in 6.8 and is published in 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 to help inform WordPress extending developers, CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. developers, and others.

There are more than 300 Core Trac tickets included in WordPress 6.8, 104 of which are enhancements and feature requests, and more than 170 bug fixes. This release includes 23 tickets focused on performance, 34 on accessibility, and 16 on modernizing code and applying coding standards. Changes in 6.8 are spread across 43 Core components.

This release also includes 387 enhancements, 525 bug fixes, and 70 accessibility improvements for 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 (a.k.a. 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/).

Below is a breakdown of the most important developer-related changes included in WordPress 6.8.


Table of contents


Block Editor

A wide array of improvements enhance performance, developer experience, and the overall editing interface.  This release introduces new tools like the should_load_block_assets_on_demand 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 optimizing asset loading, a helpful warning system for developers using useSelect, and a more efficient block registration system.  Additionally, it updates the design tool availability per block, polishes user interface components, and delivers a collection of miscellaneous refinements that improve consistency and extensibility.

Performance and Asset Loading

New tools support developers in building more performant block-based experiences.  A warning in the useSelect hook alerts when selectors are defined inline—a common pattern that can lead to unnecessary re-renders.  The should_load_block_assets_on_demand filter offers fine-grained control over whether block assets are enqueued globally or only when needed, helping reduce unused CSSCSS Cascading Style Sheets. and 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/. on the front end.  Together, these enhancements promote more efficient and optimized development workflows.

Block and Design Tool Registration

Improvements to block registration and design tool visibility streamline development and enhance clarity.  A more efficient approach to block type registration reduces the overhead of loading block metadata, especially in environments with many custom blocks.  Complementing this, the updated roster of design tools per block outlines which blocks support tools like padding, margin, and typography—giving developers a clearer picture of available customization options and improving consistency in the editor experience.

Editor UIUI User interface and Component Updates

Refinements across the block editor interface improve consistency, usability, and developer ergonomics.  Updates to core UI components—such as buttons, inputs, and layout primitives—align styling and behavior with the emerging 40px design system standard.  Additional changes include improved markup consistency in the Navigation block, enhanced preview content for the Group block, and better 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) across interface elements.  Together, these updates support a more polished and predictable editing experience.

Accessibility

A broad set of accessibility enhancements improves navigation, markup clarity, and screen reader support throughout the block editor.  The .screen-reader-text class now offers more consistent focus behavior across components, while dozens of refinements address menu structures, block labels, tooltips, and interface semantics.  These changes create a more inclusive editing experience and bring the block editor closer in line with accessibility best practices.

Internationalization

Several improvements to internationalization tooling and infrastructure enhance the translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. and localization experience for both developers and users.  Updates include new and refined translation functions, consistency fixes, and improved support for plural forms—making it easier to build plugins, themes, and interfaces that are fully translatable and globally accessible.

Performance

New tools and guidance help developers build faster, more responsive experiences.  The speculative loading feature leverages the Speculation Rules 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. to prefetch or prerender likely navigation targets, improving perceived performance for end users.  Additionally, updated best practices for the Interactivity API provide recommendations for writing efficient, scalable interactive front-end code—supporting modern, performance-focused development in WordPress.

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

Enhancements to the REST API expand its flexibility and usefulness for headless and decoupled WordPress applications.  A new filter, rest_menu_read_access, allows developers to control public access to navigation menus, menu items, and menu locations via the REST API.  This change enables more precise control over what menu data is exposed, supporting a wider range of front-end implementations and use cases.

Security

Password security is strengthened with support for bcrypt as the new default hashing algorithm.  This change modernizes WordPress’s password storage, offering improved resistance to brute-force attacks and aligning with current industry best practices.  Existing passwords remain valid and will be rehashed with bcrypt upon the next successful login.

Miscellaneous Developer Changes

A range of smaller developer-focused updates improves consistency, extensibility, and the overall development experience.  These changes span various areas of core, including media handling, shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. output, post type registration, scheduling, and theme support.  While individually minor, they collectively reflect ongoing efforts to modernize WordPress and provide a more predictable and flexible foundation for developers.

But wait, there is more!

6.8 offers so much more!  More than 170 bugs, 104 enhancements and feature requests, and 21 blessed tasks have been marked as fixed in WordPress 6.8.  WordPress 6.8 will display Emoji 15.1’s new emojis for visitors not able to display them natively, such as the 🐦‍🔥.

Below are a few more to highlight:

  • Administration: Replace “Add New {Item}” wording with “Add {Item}” across the administration (#61219)
  • Bundled Theme: Improve text strings in Twenty Twenty-Five (#62482)
  • Bundled Theme: Accessibility additions to the site title link (#62895)
  • Date/Time: Date setting should have two more options: j.n.Y and d.m.Y (#55685)
  • Embeds: Add Canva as an oEmbed provider (#58840)
  • Options, 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. APIs: Rename the setted_transient action to set_transient (#62849)
  • REST API: Handle trailing slashes in rest_preload_api_request (#57048)
  • Security: Explicitly require the hash PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher extension and add requirement checks during installation and upgrade (#56017)
  • Upgrade/Install: Prevent an unnecessary 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 update check when the plugin update data is up to date (#44118)
  • Widgets: Add post type support to get_calendar() function. This changeset also introduces a new get_calendar_args filter. (#34093)

Please, test your code.  Fixing issues that your code has with WordPress core helps you and millions of WordPress sites.  Please test your code.

Props to @joedolson @webcommsat @audrasjb @jorbin for review.

#6-8, #field-guide