More-reliable email in WordPress 6.9

Emails sent from WordPress will be more reliable in WordPress 6.9 thanks to a few updates and 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 to the wp_mail() function.

The sender address is extensibly configured.

The sender address, also known as the Envelope-From, the MAIL FROM, the Return-Path (and even more), is the address where other email servers send “bounce messages” when they can’t deliver a message. Since WordPress 4.7.0 this value was being set by the outgoing mail server and would often end up misconfigured1. That doesn’t sound like it should be a big problem — a site may not receive those notifications from failed delivery — but it’s a bigger problem because of the Sender Policy Framework (SPF) and DMARC systems which help prevent the transmission of spam. They reject these emails entirely.

Thanks to the change in [61010], WordPress 6.9 sets the sender address in an extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. way:

  • If a From email headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. is present it uses the From address. Otherwise it defaults to wordpress@home_url(), where home_url() is “the URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org for the current site where the front end is accessible.”
  • Plugins can then 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 sender address via the wp_mail_from filter in the case the inferred or default address is incorrect2.

For those with custom email configurations it may be necessary to hook into the wp_mail_from filter. If your site was relying on 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 to work around this issue before, or you relied on the phpmailer_init filter to do so, you may no longer need to do that. Otherwise, without any effort on your part, WordPress 6.9 should become more reliable out-of-the-box at sending emails.

The Encoding headers are protected between calls.

wp_mail() calls a $phpmailer global object to actually send emails, meaning that certain state is shared between calls for a given PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher request. Internal logic in the PHPMailer class looks for certain factors in a message that it uses to set or change the Encoding headers in outbound emails. Because this object is global, those encoding changes persisted and, in some cases, would apply to successive emails and cause problems when trying to read them.

In [61131] the internal encoding is reset before sending emails so that PHPMailer sends the appropriate encoding type for each email, based solely on the server configuration and specifics in that message.

Multipart messages are assigned the proper Content-Type.

For the past seventeen years there was a lurking bug in how WordPress interacts with PHPMailer for multipart messages. Ironically, the bug was introduced in a 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. meant to address this specific case, but an oversight left WordPress sending a corrupted ContentType to PHPMailer. In these cases, PHPMailer would further corrupt the outbound message because of this invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. content type. In rare cases this led to a duplicate Content-Type header, but the normative expression was corrupting the multipart boundaries.

This complicated interaction is resolved in [61201] which simplifies the previous fix by relying on PHPMailer’s facilities for setting the content type rather than attempting (erroneously) to manually specify that header.

Acknowledgements

Props to @jorbin, @sirlouen, @stankea, and @westonruter for reviewing this post, and to @websupporter and @stankea for providing expertise knowledge on the interactions of the sender address and SPF/DMARC/DKIM.

  1. Many mail servers auto-generate a sender address from the system user running on the server and the local server hostname, such as www@node-14-dc3.example.com. ↩︎
  2. This could be the case for sites with more advanced email setups, particularly those which send emails from a subdomain or different domain than on which the site is hosted. ↩︎

#6-9, #dev-notes, #dev-notes-6-9, #email

Modernizing UTF-8 support in WordPress 6.9

A number of changes in WordPress 6.9 are coming which modernize WordPress’ text encoding and UTF-8 handling. These improvements establish more reliable and consistent text processing across WordPress’ widely-supported environments, benefiting plugins and themes that handle international content, emoji, diacritics, and more.

TL;DR

  • UTF-8 handling in WordPress no longer depends on the running environment thanks to a new fallback pipeline written in pure PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher. This means that code which works on your development server will work everywhere it’s deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors..
  • Some legacy functions are misleading in their design and are difficult to use properly; these have been deprecated and replaced by more specific and purpose-built alternatives.
    • Prefer wp_is_valid_utf8() instead of seems_utf8().
    • Prefer wp_scrub_utf8() instead of wp_check_invalid_utf8().
    • Prefer mb_convert_encoding() instead of utf8_encode() and utf8_decode().

While humbler than some of the other exciting features in this release, this overhaul of UTF-8 support reflects WordPress’ commitment to a stable and trustworthy internationalized experience.

Read on to learn more about these changes and how to avoid common mistakes and misunderstandings around strings and text.

Continue reading

#6-9, #dev-notes, #dev-notes-6-9, #formatting, #utf8

WordPress 6.9 Frontend Performance Field Guide

This post is the latest in a series of updates focused on the performance improvements of major releases (see 6.8, 6.7, 6.6, 6.5, 6.4, 6.3, and 6.2).

WordPress 6.9 is the second and final 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 2025. It includes numerous improvements to the performance of loading pages on the frontend:

  • Scripts: improve script loading performance by adding support for fetchpriority, printing script modules in the footer, and optimizing the emoji detection script.
  • Styles: optimize loading of stylesheets by loading 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. styles on demand in classic themes, omitting styles for hidden blocks, increasing the inline style limit from 20K to 40K, and inlining minified stylesheets in block themes.
  • Introduce the template enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. output buffer to implement optimizations previously impossible (such as the aforementioned on-demand style loading in classic themes).
  • More: spawn WP Cron at shutdown, eliminate layout shifts in the Video block, fix RSS feedRSS Feed RSS is an acronym for Real Simple Syndication which is a type of web feed which allows users to access updates to online content in a standardized, computer-readable format. This is the feed. caching, and so on.

The performance changes in this release include 38 Trac tickets (26 enhancements, 11 defects, 1 task) and 31 Gutenberg PRs, although this post does not describe improvements to the performance of the editor nor the database query and caching optimizations. This post highlights the key changes to the frontend for site visitors, as well as looking at their impact in terms of web vitals metrics, such as TTFB, FCP, and LCP.

Continue reading

#6-9, #core, #core-performance, #css, #dev-notes, #dev-notes-6-9, #javascript, #performance

Consistent Cache Keys for Query Groups in WordPress 6.9

Query caches have historically used the last changed timestamp as a salt. While this has proven effective for most sites, it leads to an excessive number of caches which can be problematic on high-traffic and heavily updated sites. WordPress 6.9 introduces changes to how cache keys are created in order to ensure efficient use of object caches and help caches clean up after themselves.

These changes are compatible with existing implementations of persistent caching drop-ins. Vendors are not required to make any changes to their code to support these features in WordPress 6.9. As with other caching functions, the functions are pluggable should vendors wish to optimize for their particular caching implementation. These new functions are:

  • wp_cache_get_salted( string $cache_key, string $group, string|string[] $salt ): mixed
  • wp_cache_set_salted( string $cache_key, mixed $data, string $group, string|string[] $salt, int $expire = 0 ): bool
  • wp_cache_get_multiple_salted( string[] $cache_keys, string $group, string|string[] $salt ): mixed[]
  • wp_cache_set_multiple_salted( mixed[] $data, string $group, string|string[] $salt, int $expire = 0 ): bool[]

What Behavior is Changing

Previous behavior in WordPress 6.8 and earlier:

  • A post object is saved
  • WordPress stores the last changed time of the posts table
  • WP Query is called
  • WordPress caches the database query using a key containing the last changed time
  • Another post is saved, updating the posts table’s last changed time
  • The previous cache becomes unreachable
  • WP Query is called
  • WordPress does not see a cached query
  • WordPress caches the database query using a new key containing the updated last changed time

New behavior in WordPress 6.9

  • A post object is saved
  • WordPress stores the last changed time of the posts table
  • WP Query is called
  • WordPress caches the database query alongside the last changed time
  • Another post is saved, updating the posts table’s last changed time
  • WP Query is called
  • WordPress hits the previously generated cache
  • WordPress uses the last changed value to determine if the cache is up-to-date
  • WordPress replaces the previously generated cache with the new results

While both operations perform two cache lookups, the new behavior re-uses the existing cache key and does an in memory comparison of the last changed time. This prevents the cache from containing unreachable cache keys.

The same change in behavior applies to other Query classes such as term queries, comment queries, user queries, etc.

Checking/setting query caches directly

Broadly, the caches affected are in the following cache groups:

  • comment-queries
  • network-queries
  • post-queries
  • site-queries
  • term-queries
  • user-queries
The following specific cache keys are affected and will now be different.  If you have been directly checking or setting caches that start with the following keys, you will need to adjust your code.
  • get_comments
  • get_comment_child_ids
  • get_network_ids
  • comment_feed
  • wp_query
  • get_sites
  • wp_get_archives
  • adjacent_post
  • get_page_by_path
  • find_post_by_old_slug
  • get_objects_in_term
  • count_user_postscount_user_posts

Additionally, keys that are generated by WP_User_Query:generate_cache_key and WP_Term_Query::generate_cache_key are affected as well. However, these keys are md5 hashes and thus are less likely to be used directly.

When using the new wp_cache_*_salted functions and passing in an array of salts, the order of items in the array must be consistent. If you are using the changed caches in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., please review the order in core and use the same order to ensure cache hits. 

If you need to support multiple versions of WordPress when updating your code, you can use code that looks similar to:

if (function_exists( 'wp_cache_get_salted` ) ){
  $data = wp_cache_get_salted( $cache_key, 'comment-queries', $last_changed );
} else {
  // your current code here
}

See [60697] for specific examples of how core has been updated and [60941] for an example of how these new functions help cache previously uncached code. 

On Upgrade to WordPress 6.9

With the update to cache keys, it’s expected that you may see a short term increase in cache misses upon upgrade. You may wish to preemptively evict the old cache keys in order to prevent stale entries from sticking around, potentially leading to unnecessary evictions based on your cache policies.

For more information, please see #59592.

Props to @desrosj@peterwilsoncc, and @spacedmonkey for review. Props to @spacedmonkey for comments on the ticketticket Created for both bug reports and feature development on the bug tracker. that could be easily reused here.

#6-9, #cache-api, #dev-notes, #dev-notes-6-9

Miscellaneous Developer-focused Changes in 6.9

In WordPress 6.9, a handful of small, developer-focused changes were made that deserve to be called out. Let’s take a look!

PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 8.5 New Function Polyfills

The upcoming 8.5 release of PHP includes 2 new functions that can be used to retrieve values from an array:

To encourage more modern PHP practices, polyfills of these functions have been added to WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. so that they can be used safely without needing to include function_exists() checks.

For more information, see #63853.

Improved Feed Caching on Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site Installs

When RSS feeds are fetched using fetch_feed(), they are currently cached using the (get|set|delete)_transient() functions. On multisite installs, single site transients cannot be shared between sites, but site transients managed through (get|set|delete)_site_transient() can.

In WordPress 6.9, fetch_feed() will now store feeds as site transients instead. This allows a feed to be fetched and stored once for all sites on a multisite install, which improves the overall performance of feeds and reduces the amount of data cached in the database (or persistent object cache, if configured). One example where this is beneficial is the WordPress News blogblog (versus network, site) feed, which is fetched and displayed in a widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. on the dashboard for every user.

See #63719 for more details.

External Library Updates

The following external libraries bundled in WordPress are being updated in the 6.9 release:

  • ID3 has been updated to include two changes from the upstream repository that address PHP 8.5 compatibility issues (see #64051). Once a new version containing these two changes has officially been tagged, the library will be updated in full (see #64253).
  • PHPMailer has been updated from 6.9.1 to 6.11.1 (see #63811, #64052, #64055).
  • SimplePie has been updated from 1.8.0 to 1.9.0 (see #63717, #63961).
  • Sodium Compat has been updated from 1.21.1 to 1.23.0 (see #64008, #64079).

New Classic Themes Template for 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. Terms

In classic themes, you can now use term IDs when creating taxonomy templates. With taxonomy-$taxonomy-{$term->term_id}.php templates, you don’t need to worry about templates breaking if you rename the Oakland Athletics term to Athletics the way you do if you use slug based template names. 

See #35326 for more information.

Better Handling of Transparent PNGs

WordPress 6.8 introduced a regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. that could degrade the quality of PNG images with transparency when processed with Imagick. This was fixed in [60667] by improving the detection of the various types of transparent PNG files and handles them each appropriately.

See #63448 for more information.

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

WordPress 6.9 will see 21 new action and filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. hooks added. Some will be detailed in a separate developer note, but they’re all listed below for easy reference.

New Action Hooks

There are 8 new action hooks being introduced in 6.9: 

New Filter Hooks

There are 13 new filters being introduced in 6.9:

A Final Farewell to Flash

While Flash was officially retired at the end of 2020, there were a few artifacts remaining within WordPress in the form of SWFObject and SWFUpload. These were removed in [60281] and will no longer ship in new versions of WordPress going forward.

For more information, see #52699 on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

Props @adamsilverstein for helping to draft the post, and @jorbin for peer-review.

#6-9, #dev-notes, #dev-notes-6-9

Notes feature in WordPress 6.9

WordPress 6.9 introduces Notes, a new feature that allows you to leave contextual feedback at 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. level. With notes your team can stay aligned, track changes, and turn feedback into action all in one place. Notes can be resolved, and notes and their replies can be edited or deleted.

Who can use notes?

Because notes can only be created or viewed within the post editor, users must have the edit_post capabilitycapability 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 that post. By default, this means that:

  • Administrators and Editors can view all notes on all posts.
  • Authors and Contributors can view all notes for posts that they have authored.
  • Subscribers cannot view any notes.

Enabling notes for custom post types

Notes are enabled by default for the post and page built-in post types, but they can be enabled for any 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.. When you control the register_post_type() call, this is the preferred way to register support for Notes:

register_post_type( 'book', array(
	'label' => 'Books',
	'public' => true,
	'show_in_rest' => true,
	'supports' => array(
		'title',
		'editor' => array( 'notes' => true ),
		'author',
	),
) );

When the custom post type is registered through 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, support for Notes can be added by registering support using the following code snippet:

function custom_add_post_type_support() {
	$supports        = get_all_post_type_supports( 'my-post-type' );
	$editor_supports = array( 'notes' => true );

	// `add_post_type_support()` overwrites feature sub-properties, 
	// so they must be explicitly merged. 
	// See https://core.trac.wordpress.org/ticket/64156.
	if ( 
		is_array( $supports['editor'] ) && 
		isset( $supports['editor'][0] ) && 
		is_array( $supports['editor'][0] ) 
	) {
		$editor_supports = array_merge( $editor_supports, $supports['editor'][0] );
	}
	add_post_type_support( 'my-post-type', 'editor', $editor_supports );
}
add_action( 'init', 'custom_add_post_type_support' );

Since notes is a sub-feature of the editor, the code needs to manually merge the notes setting with other editor attributes. Work is underway in https://core.trac.wordpress.org/ticket/64156 to make this easier. Once this 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. is fixed, adding support will be simplified:

add_post_type_support( 'my-post-type', 'editor', array(
    'notes' => true,
) );

Accessing notes programmatically

Under the hood, Notes are WP_Comments stored in the comments table, and the standard comments APIs can be used to access them by specifying a comment_type of  note

For example, this will retrieve all notes for a given post ID:

$notes = get_comments( 
	array(
		'post_id' => $post_id,
		'type'    => 'note',
	)
);

Notes can also be retrieved using 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/.:

$request = new WP_REST_Request( 'GET', '/wp/v2/comments' );
$request->set_param( 'post', $post_id );
$request->set_param( 'type', 'note' );
$response = rest_get_server()->dispatch( $request );
if ( ! is_wp_error( $response ) ) {
	$notes = $response->get_data();
	foreach ( $notes as $note ) {
		// Process each note as needed
	}
}

Note status

When a note is added to a block, it:

  • Starts in an “Open” state with a comment_status of 0 (aka hold). 
  • When resolved, changes to a comment_status of 1 (aka approve).
  • When deleted, changes to a status of trash, unless EMPTY_TRASH_DAYS is 0 in which case deleted immediately.

The following snippet will get a list of all unresolved Notes for a given post:

$notes = get_comments( 
	array(
		'post_id' => $post_id,
		'type'    => 'note',
		'status'  => 'hold'
	)
);

Important: Notes must be explicitly requested by specifying either the note or all comment type. Otherwise they are excluded when retrieving comments:

// This only returns comments, 'notes' are automatically excluded.
$comments = get_comments( array ( 'post_id' => $post_id ) );

Notification emails

When another user adds a note to a post, the post_author will receive a notification that a note has been added to the post. Notifications are enabled by default and can be controlled at a site level under Settings->Discussions – Email me whenever > Anyone posts a note. Developers can also use the existing comment filters to control notifications. 

For example, to send notifications for notes on pages but not posts, use this snippet:

function only_notify_page_authors_of_notes( $notify, $comment_id ) {
	if ( 'note' !== get_comment_type( $comment_id ) {
		return $notify;
	}

	if ( 'page' === get_post_type( $comment_post_ID ) {
		return true;
	}

	return false;
}
add_filter( 'notify_post_author', 'only_notify_page_authors_of_notes', 10, 2 );

Miscellaneous

Notes permissions

As previously mentioned, only users who can edit a given post are able to add notes. Because notes are an internal/authorized user feature, the normal restrictions that apply to comment posting do not apply to notes, including the flood protection and duplicate prevention. In addition, the pre_comment_approved 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. is not run for notes.

Linking blocks to notes

Top level notes are linked to blocks with a metadata attribute. . When you add a new note to a block, the note ID is stored in block attributes metadata as noteId. Replies are linked to top level notes as children (with their parent set to the top level note)

To get the note ID from a block based on its clientId, you can use this code:

const attributes = getBlockAttributes( clientId );
const noteId     = attributes.metadata?.noteId;

Important: The reverse is not true – notes do not contain a link back to their associated block. To identify the block(s) associated with a note, search the blocks for the noteId in metadata. You can use this code snippet:

import { store as blockEditorStore } from '@wordpress/block-editor';

const { getBlockAttributes } = useSelect( blockEditorStore );

const { clientIds } = useSelect( ( select ) => {
	const { getClientIdsWithDescendants } = select( blockEditorStore );
	return {
		clientIds: getClientIdsWithDescendants(),
	};
}, [] );

// expectedNoteId is the note we are filtering for.
const blocksWithNote = clientIds.reduce( ( results, clientId ) => {
	const commentId = getBlockAttributes( clientId )?.metadata?.noteId;
	if ( commentId === expectedNoteId ) {
		results[ clientId ] = commentId;
	}
	return results;
}, {} );

Known limitations

  • A note can be associated with more than one block. If a block with a note is split or duplicated, the note becomes associated with both blocks. This is primarily due to an underlying limitation 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/ that will be fixed in #29693.
  • A notification is sent for each new non-author note which may not be ideal for all users, especially for cases where a high volume of notes are added to a post will in turn generate a high volume of emails to the post author.
  • Notes do not work outside post content types, for example in templates.
  • All notes are block level, for example this means that they can not reference specific text within a paragraph or text across paragraph blocks.  In-line notes will become available as part of #59445.

What’s next

There are already new features and enhancements planned for Notes in the next release of WordPress (7.0). These features were suggested during the development cycle, but didn’t make it into the 6.9 release.

  • Fragment notes – the ability to leave a note on a part of a block or across blocks.
  • “@” mentions – mention another user in a post and they will receive a notification.
  • Improved notifications – control frequency for notifications, for example receive a daily digest of all new note activity.
  • Improved floating layout for wide screens – shift the floating to sit between the editor frame and the sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme..
  • Minified mode – notes display as icons with avatars beside blocks that expand when clicked..
  • Wider availability across the editor including using notes with templates.
  • Real time collaboration with Notes.

You can follow along and contribute to the ongoing effort on the Notes iteration for 7.0 tracking issue.

Have an idea for how to improve Notes? Leave your feedback as a comment below or on the tracking issue linked above.

Props to @jeffpaul, @mamaduka, @wildworks, @annezazu, and @desrosj for review.

#core, #dev-notes, #notes

Heading Block CSS Specificity Fix in WordPress 6.9

WordPress 6.9 fixes a specificity issue with the Heading block’s background padding. Previously, padding styles applied to headings with backgrounds were affecting other blocks that use heading elements, such as the Accordion Heading 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.. This fix ensures that background padding is only applied to actual Heading blocks.

What’s changed?

The CSSCSS Cascading Style Sheets. selector for applying padding to headings with backgrounds has been made more specific. The selector now targets .wp-block-heading.has-background instead of just heading element tags (h1h2, etc) with the .has-background class.

Before:

h1, h2, h3, h4, h5, h6 {
  &.has-background {
    padding: ...;
  }
}

After:

h1, h2, h3, h4, h5, h6 {
  &:where(.wp-block-heading).has-background {
    padding: ...;
  }
}

The use of :where() ensures the CSS specificity remains at 0-1-1, minimizing impact on existing theme styles. As the CSS specificity remains unchanged, existing theme styles targeting heading elements should continue to work as expected.

What does this mean for themes?

If a theme applies the .has-background class to heading elements that are not Heading blocks (e.g., <h1 class="page-title has-background">Hello World</h1>), these elements will no longer receive the default block background padding. If a theme relies on this behavior, it will need to be updated to include explicit padding styles for these elements.

Props to @priethor for reviewing.

#6-9, #css, #dev-notes, #dev-notes-6-9

Changes to the Interactivity API in WordPress 6.9

Standardized 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 set unique IDs in directives

HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. does not allow multiple attributes with the same name on a single element, yet multiple plugins may need to add directives of the same type to the same element. To address this, WordPress 6.9 introduces a standardized way to assign unique IDs to Interactivity API directives, allowing an element to have multiple directives of the same type, as long as each directive has a different ID.

To assign a unique ID to a directive, append a triple-dash (---) followed by the ID, as shown in the following example.

<div
    data-wp-watch---my-unique-id="callbacks.firstWatch"
    data-wp-watch---another-id="callbacks.secondWatch"
></div>

The triple-dash syntax unambiguously differentiates unique IDs from suffixes. In the example below, click is the suffix, while plugin-a and plugin-b are the unique IDs. The order is also important: the unique ID must always appear at the end of the attribute name.

<button
    data-wp-on--click---plugin-a="plugin-a::actions.someAction"
    data-wp-on--click---plugin-b="plugin-b::actions.someAction"
>
  Button example
</button>

See #72161 for more details.

Props to @luisherranz and @santosguillamot for the implementation.

Deprecated data-wp-ignore directive

The data-wp-ignore directive was designed to prevent hydration of a specific part of an interactive region. However, its implementation broke context inheritance and caused potential issues with the client-side navigation feature of the @wordpress/interactivity-router module, without addressing a real use case.

Since WordPress 6.9, this directive is deprecated and will be removed in subsequent versions.

See #70945 for more details.

Props to @Sahil1617 for the implementation.

New AsyncAction and TypeYield type helpers

WordPress 6.9 introduces two new TypeScript helper types, AsyncAction<ReturnType> and TypeYield<T>, to the Interactivity API. These types help developers address potential TypeScript issues when working with asynchronous actions.

AsyncAction<ReturnType>

This helper lets developers explicitly type the return value of an asynchronous action (generator). By using any for yielded values, it breaks circular type dependencies when state is used within yield expressions or in the final return value.

TypeYield<T extends (...args: any[]) => Promise<any>

This helper lets developers explicitly type the value that a yield expression resolves to by providing the type of the async function or operation being yielded.

For more information and examples, see the Typing asynchronous actions section in the Interactivity API reference > Core Concepts > Using TypeScript guide.

See #70422 for more details.

Props to @luisherranz for the implementation.

#6-9, #dev-notes, #dev-notes-6-9, #interactivity-api

Interactivity API’s client navigation improvements in WordPress 6.9

In WordPress 6.9, the client-side navigation feature provided by the @wordpress/interactivity-router module has been expanded to cover additional use cases that were previously unsupported.

Support for new script modules and stylesheets

Previously, only the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. of the new page was updated, keeping the styles present in the initial page and ignoring any new script modules. This worked for basic client-side navigation cases, but it didn’t handle more complex situations, such as when new blocks appear on the next page.

With this update, WordPress now replaces stylesheets and loads any script modules after client-side navigation.

  • The new algorithm reuses the stylesheets shared with the previous page to minimize networknetwork (versus site, blog) requests, loads any new stylesheet not present in the previous navigations, and disables those that no longer apply.
  • The new algorithm also loads all the script modules belonging to interactive blocks that didn’t exist on the previous pages. To correctly support module dependencies, new importmap definitions are also supported.
  • To maintain the experience of instant navigations, prefetching a page also prefetches all the stylesheets and script modules that were not previously prefetched or loaded.

While all styles are handled in the browser by 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. runtime, script modules must be explicitly marked as compatible with client-side navigation.

For blocks, this is done automatically by checking the supports.interactivity to either true or contain an object with { clientNavigation: true } to mark its support in their block.json file (see docs here). If that’s the case, the corresponding viewScriptModule will be automatically marked as compatible.

For other script modules registered “manually”, developers must use the add_client_navigation_support_to_script_module method of the main WP_Interactivity_API instance, as shown in the example below.

wp_register_script_module( 'my-module', '/my-module.js' );
wp_interactivity()->add_client_navigation_support_to_script_module( 'my-module' );
wp_enqueue_script_module( 'my-module' );

That method would mark the passed script module ID as compatible, and its script 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.) would include a data-wp-router-options directive containing the value {"loadOnClientNavigation":true}.

Script modules without that directive are ignored and not imported. Remember that regular scripts are simply ignored regardless of whether they contain the data-wp-router-options directive, as they are not supported by the Interactivity API.

For details on the implementation, see #70353.

Support for router regions inside interactive elements

Router regions are those elements marked with the data-wp-router-region directive. When the navigate() action from @wordpress/interactivity-router is invoked, the content of these regions is updated to match the newly requested page.

In previous WordPress versions, router regions needed to match a root interactive element (i.e., one of the top-most elements with a data-wp-interactive directive). This meant that if the data-wp-router-region directive was used anywhere else in an interactive region, its content wouldn’t be updated.

<div data-wp-interactive="example">
    <button data-wp-on--click="actions.doSomething">Click me!</button>
    <div
      data-wp-interactive="example"
      data-wp-router-region='example/region-1'
    >
      I wasn't updated on client navigation (now I am!)
    </div>
</div>

Now, router regions are updated whenever they are placed in an interactive region. The only requirement is that they must still be used alongside the data-wp-interactive directive so they receive the corresponding namespace.

For more details, refer to the related issue #71519 and pull request #71635.

New attachTo option for router regions

In WordPress 6.9, router regions accept an attachTo property that can be defined inside the data-wp-router-region directive, allowing the region to be rendered even when it was missing on the initial page. This option supports cases like overlays that are necessary for a 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., but may appear outside all the regions.

The attachTo property should be a valid CSSCSS Cascading Style Sheets. selector that points to the parent element where the new router region should be rendered. For example, the following router region would be rendered in <body> if it appears on a visited page, even if it wasn’t initially rendered.

<div
  data-wp-interactive="example"
  data-wp-router-region='{ "id": "example/region", "attachTo": "body" }'
>
  I'm in a new region!
</div>

See #70421 for more details.

Improved getServerState and getServerContext functions

When using the Interactivity API with client-side navigation, the getServerState() and getServerContext() functions now properly handle the following scenarios:

  1. Properties that are modified on the client but should reset to server values on navigation
    Now, whenever getServerState or getServerContext is tracking a value that doesn’t change after a client-side navigation, it will still trigger an invalidation so that it can be used to reset values, such as:
   const { state } = store( 'myPlugin', {
    // ...
    callbacks: {
        resetCounter() {
            const serverState = getServerState(); // Always { counter: 0 };
            state.counter = serverState.counter; // Reset to 0;
        },
    },
   } );
  1. Properties that only exist on certain pages
    Server state and contexts are now fully overwritten: only the properties present on the current page are retained, and those from previous pages are removed. This allows having the certainty of knowing if a property doesn’t exist in the server state, even if it was present on the previous page.
   store( 'myPlugin', {
    // ...
    callbacks: {
        onlyWhenSomethingExists() {
            const serverState = getServerState();
            if ( serverState.something ) {
                // Do something...
            }
        },
    },
   } );

Additionally, these functions now include proper type definitions and error messages in debug mode, among other improvements.

See #72381 for more details.

Props to @darerodz and @luisherranz for the implementations.

#6-9, #dev-notes, #dev-notes-6-9, #interactivity-api

Preparing the Post Editor for Full iframe Integration

As part of an ongoing effort to modernize the editing experience, WordPress is moving toward running the post editor inside an iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser.. This work builds upon the original iframe migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. in the template editor and introduces new compatibility measures in WordPress 6.9, ahead of the full transition planned for WordPress 7.0.

For background, see the original post.

What’s Changing in WordPress 6.9

Starting with WordPress 6.9, several important updates have been introduced to prepare for this change, which will be completed in WordPress 7.0.

Browser console warnings for legacy blocks

To help developers identify legacy blocks, WordPress 6.9 now displays a warning in the browser console when a 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. is registered with apiVersion 2 or lower, and SCRIPT_DEBUG is enabled. This serves as an early signal to update existing blocks before the post editor becomes fully iframed in WordPress 7.0.

When a block is registered with apiVersion 2 or lower, the post editor runs in a non-iframe context as before to maintain backward compatibility. Developers are encouraged to migrate their blocks to apiVersion 3 and test them within the iframe-based editor to ensure full compatibility with future WordPress releases.

See #70783 for more details.

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. schema now only allows apiVersion: 3

Alongside these compatibility measures, the block.json schema has been updated to only allow apiVersion: 3 for new or updated blocks. Older versions (1 or 2) will no longer pass schema validation.

See #71107 for more details.

Why iframe the Post Editor?

The main goal of iframing the editor is isolation. By loading the editor content within an iframe, styles from the WordPress adminadmin (and super admin) no longer interfere with the editor canvas.

This separation ensures that the editing experience more closely mirrors what users see on the front end.

From a technical perspective, the iframe approach offers several benefits:

  • Admin styles no longer leak into the editor, eliminating the need to reset admin CSSCSS Cascading Style Sheets..
  • Viewport-relative units (vwvh) and media queries now behave naturally within the editor.

The iframed Post Editor will make life easier for block and theme authors by reducing styling conflicts and improving layout accuracy.

Props to @mamaduka for helping review this dev-note.

#6-9, #dev-notes, #dev-notes-6-9