Proposal: Major releases for 2025

With WordPress 6.7 out the door, it’s time to plan for next year’s releases. The following dates try to account for flagship events and major international holidays:

  • 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. 1 on March 4, stable release on April 15 (Beta 1 ten days after WC Asia)
  • 6.9 – Beta 1 on June 24, stable release on August 5 (WCEU in early June)
  • 7.0 – Beta 1 on  September 30, stable release on November 11 (no flagship events nearby)

The release cadence is similar to past years, with a longer initial release cycle, including the end-of-year festivities and ~4-month ones. Please leave your feedback below or through a 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/. DM by November 29.

Although the 6.8 dates aren’t final yet, they are close to final enough to let contributors know their availability around that time. If you want to participate in the WordPress 6.8 release, stay tuned for an upcoming post with the call for volunteers.

Props to @jeffpaul for reviewing the proposed dates and this post.

#planning

#6-8, #6-9, #7-0

Internationalization improvements in 6.7

Various internationalization (i18n) improvements are in WordPress 6.7, and this developers note focuses on these.

Determining whether a translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. exists

Sometimes it can be useful to know whether a translation already exists for in memory without having to first load the translation for the given text domain. The new has_translation() function allows for exactly that.

See #52696 / [59029] for more details.

Sending emails in the adminadmin (and super admin)’s localeLocale A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English.

Back in version 4.7, WordPress added the ability for users to set their preferred locale. When sending emails to a user, they are always sent in that locale, and everyone else receives the email in the site’s locale.

Now, WordPress 6.7 is going a step further: every time an email is sent to the administrator email address (admin_email), WordPress checks if a user with the same email address exists. If so, the email is sent in that user’s locale.

See #61518 / [59128] for more details.

Warnings if translations are loaded too early

WordPress now warns developers if they are loading translations too early in 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 or theme, before the current user is known. Existing functions like load_plugin_textdomain() and load_theme_textdomain() were updated to defer the actual loading to the existing just-in-time translation logic in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. This reduces the likelihood of triggering the warning, and even improves performance in some situations by avoiding loading translations if they are not needed on a given page.

Reminder: if your plugin or theme is hosted on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ and is still using load_*_textdomain(), you can remove this call. Since WordPress 4.6, plugins and themes no longer need load_plugin_textdomain() or load_theme_textdomain(). WordPress automatically loads the translations for you when needed. If you still support older WordPress versions or do not host your plugin/theme on WordPress.org, move the function call to a later hook such as init.

When attempting to load translations before after_setup_theme or init, WordPress tries to load the current user earlier than usual, without giving other plugins a chance to potentially hook into the process. It also prevents any plugins from filtering translation calls, e.g. for switching the locale or file location. Hence the addition of this warning to call out this unexpected behavior.

See #44937, [59127], and [59157] for more details.

Your plugin might be _doing_it_wrong() if you for example directly call get_plugin_data() (which attempts to load translations by default) or __() without waiting for the init hook. Here is a common example that was found in an actual plugin that was fixed:

/**
 * Plugin Name: Awesome Plugin
 */

function myplugin_get_version() {
	require_once ABSPATH . 'wp-admin/includes/plugin.php';
	// Prevent early translation call by setting $translate to false.
	$plugin_data = get_plugin_data( __FILE__, false, /* $translate */ false );
	return $plugin_data['Version'];
}

define( 'MYPLUGIN_VERSION', myplugin_get_version() );

If you do not explicitly set $translate set to false when calling get_plugin_data(), the function translates the plugin metadata by default. Since this plugin just needs the version number, there is no need for translating any of the other fields.

Another example:

/**
 * Plugin Name: Awesome Plugin
 */

class My_Awesome_Plugin {
	public $name;
	public function __construct() {
		// This triggers just-in-time translation loading
		$this->name = __( 'My Awesome Plugin', 'my-awesome-plugin' );

		// ... do something
	}
}

// This immediately instantiates the class, way before `init`.
$myplugin = new My_Awesome_Plugin();

Here, a class is immediately instantiated in the main plugin file, and code within the class constructor uses a translation function. This can be avoided by deferring the class instantiation until after init, or deferring the translation call until later when it is actually needed.

If your plugin is affected by this warning, you can use code like follows to find out the code path that triggers it:

add_action(
	'doing_it_wrong_run',
	static function ( $function_name ) {
		if ( '_load_textdomain_just_in_time' === $function_name ) {
			debug_print_backtrace();
		}
	}
);

Developer tools such as Query Monitor are also helpful in situations like this.


Props to @ocean90, @fabiankaegy for review.

#6-7, #dev-notes, #dev-notes-6-7, #i18n

Let’s reconsider adopting the WP Consent API

This post is a follow up to Feature Plugin Proposal: WP Consent API from 2020, which as part of the Core Privacy Roadmap, proposed a framework to allow extenders to coordinate user consent signals and help websites honor user privacy preferences.

Objective of this proposal

The legal and moral implications around respect for user consent and tracking have evolved steadily since the original proposal was published in 2020. Powering over 40% of the web, WordPress is in a position to lead by example and provide site operators built-in and extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. means to address these concerns. This proposal seeks to gather consensus around adopting the WP Consent 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. for inclusion in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

A brief history of the API

In early 2020, the WP Consent API feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. was announced. It enables the setting and retrieval of user consent preferences, made accessible to plugins that register with the API. It was designed to be lean and unobtrusive, opt-in only, and with no UIUI User interface.

Rather than try to enforce cookie-setting compliance itself, the API lets opted-in plugins verify consent before placing cookies. It also allows consent categories to be defined and user choices set and stored by consent management providers (CMPs) and other extenders, where the technical and legal details around the various flavors of consent can be managed outside of WordPress.

In December 2020 the Consent API feature was swept up along with other features during a clean up of the features list, and marked as “Closed”. However, subsequent discussions in #core-privacy in following months were incognizant of the change, and there was confusion that it had been marked closed when attempts were made to move 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 to the WordPress 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/ org.

Until early this year, adoption of the plugin was minimal, but has been steadily maintained by @rogierlankhorst, @szepeviktor, @xkon, @aurooba, @mujuonly, @phpgeekdk, @paapst, @aahulsebos, @pputzer, and @markwolters.

Why does this matter now?

In March 2024, enforcement of the European Union’s Digital Markets Act (DMA) began, and adoption of the plugin has since grown from under 1,000 to over 100,000 active installations. Uptake of the plugin can largely be attributed to consent-requiring plugins such as Google Site Kit, WooCommerce, and WP Statistics, which use the API to support site analytics, advertising, marketing, and 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.) management.


Beyond the DMA, there are numerous other privacy-focused regulations around the world that over the past few years have come into effect, or will soon. User consent is a key theme to achieving many of these protections, and WordPress can provide the foundation on which consent plugins interact.

Considerations for Core adoption

The API has remained largely unchanged since its introduction, so would likely require refreshing to meet today’s Core merge expectations. There may also be features that need to be revisited, such as how non-consent-related plugins appear in Site Health recommendations.

Along with the API, Core could implement a default cookie “popup” or blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. that could be activated similar to the built-in Privacy Policy feature. This would give site owners a simple mechanism to request and track consent (cookie-based), and be customizable without requiring an additional plugin.

A sample use would be to request “statistics” consent through the popup, styled through a theme, and wrap client-side tracking code inside a wp_has_consent() check. Extenders can take things further by expanding the default categories and storage mechanism for more advanced integrations, as current adopters of the API do today.

Canonical plugin alternative

If adding this feature to Core is not viable at this time, then another option would be to make it canonical. While originally developed under @rogierlankhorst‘s personal repo, it has since been migrated to that of a specific plugin developer and vendor in the CMP space.

Considering the original intent that this feature be merged to Core, agreement from Rogier that it remain available to the community, and the API’s adoption by other vendors, officially bringing the plugin into the WordPress org would send a clear signal to site owners and extenders that this is a community-built and supported standard.

Where to find more info

Share your thoughts

What do you think about WordPress paving the way for easier integration of consent-based privacy controls? Please comment below, especially if you have dealt with implementing consent management in WordPress.

Special thanks to @rogierlankhorst and @azaozz for review and feedback on this post.

#consent-api #core-privacy #feature-plugins #privacy #privacy-roadmap

Agenda, Dev Chat, Dec 18, 2024

The next WordPress Developers Chat will take place on Wednesday at 20:00 UTC in the core channel on Make WordPress Slack.

This will be the last Dev Chat of 2024 and we will resume the meetings again on January 8, 2025.

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

The Nominations for 2025’s Core Team Reps are now open! Please nominate people in the comments of that post. Self-nominations are welcome. The deadline is January 31, 2025.

Forthcoming releases

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. The call for volunteers for the 6.8 release squad closed on Dec 6 and the release squad will be put together soon based on these volunteers.

Next maintenance release: 6.7.2

There is currently no release date planned for WordPress 6.7.2. Review the next minor release milestone.

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/ release: 19.9

The next Gutenberg release will be 19.9, scheduled for December 18. It will include the following issues.

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.

If you want 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.

Highlighted Posts

Editor Updates

Props to @annezazu for putting this list of updates together:

You can keep up to date with the major Editor features that are currently in progress by viewing these Iteration issues.

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 if you intend to be available during the meeting for discussion or if you will be async.

Thank you and props to @joemcgill and @annezazu for contributing to this agenda.

#6-8, #agenda, #dev-chat

Block Bindings: Improvements to the Editor Experience in 6.7

WordPress 6.7 introduces various improvements to 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. Bindings 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. and the built-in post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. source, including a default UIUI User interface and the beginnings of a public editor API.

For an introduction to Block Bindings, first introduced in WordPress 6.5, see the prior dev note.

New Block Bindings UI

Compatible blocks — which currently include Heading, Paragraph, Image, and Button — have received a new default UI for viewing bindings.

Called Attributes, you can find the new tool panel in block settings whenever a compatible block is selected in either the post or site editor.

The panel shows active bindings on the current block. If there are any post meta available, the panel is also interactive, allowing you to bind attributes to those custom fields via the built-in post meta block bindings source.

Currently, there are two limitations to the panel:

  1. It will not allow users to bind attributes to custom sources just yet. 

    Bindings to custom sources, which can be added via the code editor or other programmatic means, will still display in the panel — they just can’t be connected via the UI for the moment in WordPress 6.7.

    A flexible API for connecting custom sources to the Attributes panel is currently under development and is planned for public release in the future.

    For now, the rollout of that API has started with the built-in post meta source to allow time for gathering feedback.
  2. For each attribute, the panel will only show custom fields that match its data type. For example, an attribute of type string or rich-text can only be connected to a custom fieldCustom Field Custom Field, also referred to as post meta, is a feature in WordPress. It allows users to add additional information when writing a post, eg contributors’ names, auth. WordPress stores this information as metadata. Users can display this meta data by using template tags in their WordPress themes. of type string, and an attribute of number can only be connected to another number.

New Post Meta Label Attribute

To improve how custom fields appear in the editor UI, a new label attribute has been created for post meta, which can be defined during registration:

If specified, the label will render in place of the meta key in the Attributes panel — in this example, the label would replace movie_director. The label will also render under certain circumstances in other parts of the editor, including as a placeholder for Rich Text if a block is bound to the post meta source and a default value is undefined.

Usage In Custom Post Templates

One of the primary use cases for Block Bindings is to assist in creating templates for custom post types. Given a 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. called movie, for example, one can define how custom fields for that post type will render, such as via connected images, headings, paragraphs, and buttons.

Here is an example of how one could use connected blocks to create a layout:

One can override the content in connected blocks for each instance of the custom post type, a much simpler and more flexible way of creating layouts than in the past — all without needing to create custom blocks.

Default Permissions

Accompanying this UI is a new canUpdateBlockBindings editor setting, used to determine whether the UI is interactive for users or not.

By default, this editor setting is set to a new edit_block_binding capability, which maps to a user’s ability to either:

  1. Edit the post type (in the post editor), or
  2. Edit the theme options (in the site editor)

This means that the setting is by default set to true for administrators, and false for other users.

This default setting can be overridden using the block_editor_settings_all filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. and modifying $editor_settings['canUpdateBlockBindings'] as follows:

function my_plugin_override_can_update_block_bindings( $settings ) {
    $settings['canUpdateBlockBindings'] = true;
    return $settings;
}
add_action( 'block_editor_settings_all', 'my_plugin_override_can_update_block_bindings' );

New Public Editor APIs

Several functions have been exposed to enable the use of block bindings in the editor.

Registration API

Source Bootstrapping 

As part of the new editor API, Block Bindings will automatically register custom sources defined on the server with bootstrapped values in the editor. This will allow existing sources registered using just the server APIs to render in the UI.

This means that any sources already registered using the server APIs, available since 6.5, will appear in the UI, at least minimally, without any action required.

For example, given the following server registration and block markup…

Server Registration
function my_plugin_register_block_bindings_post_attributes() {
    register_block_bindings_source(
        'my-plugin/post-attributes',
        array(
            'label'              => _x( 'Post Attributes', 'block bindings source', 'my-plugin' ),
            'get_value_callback' => 'my_plugin_block_bindings_post_attributes_get_value',
            'uses_context'       => array( 'postId' ),
        )
    );
}
add_action( 'init', 'my_plugin_register_block_bindings_post_attributes' );

function my_plugin_block_bindings_post_attributes_get_value( array $source_args, $block_instance ) {
    $allowed_fields = array( 'title', 'excerpt' );
    if ( ! in_array( $source_args['key'], $allowed_fields ) ) {
        return null;
    }
    $post = get_post( $block_instance->context['postId'] );
    return $post->{'post_' . $source_args['key']};
}
Block Markup
<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"my-plugin/post-attributes","args":{"key":"title"}}}}} -->
<p></p>
<!-- /wp:paragraph -->

…the source will get registered in the editor with the source’s name my-plugin/post-attributes, label, and uses_context values. This is enough for the UI to render as follows:

In this case, however, the bound paragraph in the block canvas will simply show the source label and will not be dynamic. Further customization of the editor experience requires using the new editor registration functions, detailed in the next section.

Editor Registration

The following functions have been exposed to allow customization of the editor experience:

  • registerBlockBindingsSource: Registers a source on the client (using this function will override the bootstrapped registration).
  • unregisterBlockBindingsSource: Unregisters an existing source.
  • getBlockBindingsSource: Gets a specific registered source and its properties.
  • getBlockBindingsSources: Gets all the registered sources in the client.

These are based on other registration APIs like block types, block variations, or block collections.

Source Properties

Registered sources in the client can include the following properties:

  • name: The unique and machine-readable name.
  • label: Human-readable label. Will overwrite preexisting label if it has already been registered on the server.
  • usesContext: Array of context needed by the source only in the editor. Will be merged with existing uses_context if it has already been registered on the server.
  • getValues: Function to get the values from the source. It receives select, clientId, context, and the block bindings created for that specific source. It must return an object with attribute: value. Similar to getBlockAttributes.
  • setValues: Function to update multiple values connected to the source. It receives select, clientId, dispatch, context, and the block bindings created for that specific source, including the new value. Similar to updateBlockAttributes.
  • canUserEditValue: Function to let the editor know if the block attribute connected should be editable or not. It receives select, context, and the source arguments.
Example Usages 
Register a Block Bindings Source

Building on the example server registration, use the following 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/. to register in the editor by enqueuing on the enqueue_block_editor_assets hook:

import { registerBlockBindingsSource } from '@wordpress/blocks';
import { __ } from '@wordpress/i18n';
import { store as coreEditorStore } from '@wordpress/editor';

const allowedAttributes = [ 'title', 'excerpt' ];

registerBlockBindingsSource( {
    name: 'my-plugin/post-attributes',
    usesContext: [ 'postType' ],	
    getValues( { select, bindings } ) {
        const values = {};
        for ( const [ attributeName, source ] of Object.entries( bindings ) ) {
            if ( allowedAttributes.includes( source.args.key ) ) {
                values[ attributeName ] = select( coreEditorStore ).getEditedPostAttribute( source.args.key );
            }
        }
        return values;
    },
    setValues( { dispatch, bindings } ) {
        const newValues = {};
        for ( const [ attributeName, source ] of Object.entries( bindings ) ) {
            if ( allowedAttributes.includes( source.args.key ) ) {
                newValues[ source.args.key ] = source.newValue;
            }
        }
        if ( Object.keys( newValues ).length > 0 ) {
            dispatch( coreEditorStore ).editPost( newValues );
        }
    },
    canUserEditValue( { context, args } ) {
        return allowedAttributes.includes( args.key ) && 'post' === context.postType;
    },
} );

To connect example blocks to the source, go to the post editor, open the code editor, and use the following markup:

<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"my-plugin/post-attributes","args":{"key":"title"}}}}} -->
<p></p>
<!-- /wp:paragraph -->

<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"my-plugin/post-attributes","args":{"key":"excerpt"}}}}} -->
<p></p>
<!-- /wp:paragraph -->

For a more in-depth example of how these properties can be defined in a real-world scenario, see the registration for the built-in post meta source.

Unregister a Block Bindings Source
import { unregisterBlockBindingsSource } from '@wordpress/blocks';

unregisterBlockBindingsSource( 'plugin/my-custom-source' );
Get All Block Bindings Sources
import { getBlockBindingsSources } from '@wordpress/blocks';

const registeredSources = getBlockBindingsSources();
Get a Block Bindings Source
import { getBlockBindingsSource } from '@wordpress/blocks';

const blockBindingsSource = getBlockBindingsSource( 'plugin/my-custom-source' );

Note: If desired, sources may be registered only on the client and not on the server at all. This could be useful for creating forms in the adminadmin (and super admin), or otherwise using bindings to interact with other parts of WordPress, or other dynamic data.

Block Bindings Utils

The useBlockBindingsUtils hook returns helper functions to modify the metadata.bindings attribute. The hook accepts an optional clientId argument. If the clientId is not specified, the helper functions will execute in the current block edit context.

Right now, the helpers include:

  • updateBlockBindings: This works similarly to updateBlockAttributes. It can be used to create, update, or remove specific connections.
  • removeAllBlockBindings: This is used to remove all existing connections in a block.

Example usage

import { useBlockBindingsUtils } from '@wordpress/block-editor';

const { updateBlockBindings, removeAllBlockBindings } = useBlockBindingsUtils();

// Updates bindings for url and alt attributes.
updateBlockBindings( {
    url: {
        source: 'core/post-meta',
        args: {
            key: 'url_custom_field',
        },
    },
    alt: {
        source: 'core/post-meta',
        args: {
            key: 'alt_custom_field',
        },
    },
} );

// Removes all bindings set for the block.
removeAllBlockBindings();

Used internally by the default UI for the post meta source and pattern overrides, these utils can be useful in building custom UI for other sources.

For more examples of how these functions are used in practice by the built-in UI, see the calls to updateBlockBindings and removeAllBlockBindings.

New Server Filter

A block_bindings_source_value filter has been introduced to allow for overriding of the value returned by a source in a bound block. It takes the following arguments:

  • value: Value returned by the source.
  • name: Name of the source.
  • source_args: Arguments passed to the source.
  • block_instance: The bound block.
  • attribute_name: The connected attribute in the bound block.
function modify_block_bindings_source_value( $value, $name, $source_args, $block_instance, $attribute_name ) {
    if ( 'core/post-meta' === $name && 'movie_runtime' === $source_args['key'] ) {
        return $value . ' minutes';
    }
    return $value;
}
add_filter( 'block_bindings_source_value', 'modify_block_bindings_source_value', 10, 5 );

Conclusion

The developers behind Block Bindings are always happy to hear feedback. Please feel free to share bugs, feature requests, or other thoughts by creating issues on 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/ or leaving a comment on this post.

Anyone can also follow and comment on Block Bindings development via the latest iteration, which is posted in the Block Bindings tracking issue at the beginning of each release cycle. Be sure to subscribe to the tracking issue for updates!

Lastly, if you’d like to help shape the roadmap for Block Bindings by sharing your use cases, feel free to post in Block Bindings discussions.

Props to @santosguillamot @gziolo @cbravobernal @greenshady @fabiankaegy and @welcher for their help compiling this post.

#6-7, #block-bindings, #dev-notes, #dev-notes-6-7

Agenda, Dev Chat, Dec 11, 2024

The next WordPress Developers Chat will take place on Wednesday at 20: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

There are no major announcements from the past week.

Forthcoming releases

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. The call for volunteers for the 6.8 release squad closed on Dec 6 and the release squad will be put together soon based on these volunteers.

Next maintenance release: 6.7.2

There is currently no release date planned for WordPress 6.7.2. Review the next minor release milestone.

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/ release: 19.9

The next Gutenberg release will be 19.9, scheduled for December 18. It will include the following issues.

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.

If you want 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.

Highlighted Posts

Editor Updates

You can keep up to date with the major Editor features that are currently in progress by viewing these Iteration issues.

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 if you intend to be available during the meeting for discussion or if you will be async.

Props to @joemcgill for contributing to this agenda.

#6-8, #agenda, #dev-chat

WordPress 6.7 Performance Improvements

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

WordPress 6.7, “Rollins” is the last major version of WordPress released in 2024. This release delivers important performance updates, including faster pattern loading, optimized previews in the data views component, improved PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 8+ support and removal of deprecated code, auto sizes for lazy-loaded images, and more efficient 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.) processing in the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. 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..

Explore the WordPress 6.7 Field Guide. Learn about the changes in this release with detailed developer notes.

Further details on the methodology behind these measurements are provided later in this article, along with an explanation of possible 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. sources.

Key improvements

Media: Auto sizes for lazy loaded images

In #61847,  support was added for sizes=”auto” for lazy-loaded images. This feature, which was recently added to the HTML specification, allows the  browser to use the rendered layout width of the image when selecting a source from the srcset list, since lazy loaded images don’t load until after the layout is known. It maintains backward compatibility while boosting performance, particularly for responsive and dynamic layouts. Explore the details in the official dev note.

Media: Caching _wp_image_editor_choose results for improved performance

In #61532, WordPress now caches the results of _wp_image_editor_choose, storing the WP_Image_Editor implementation that supports queried options. This avoids redundant and costly compatibility checks, such as multiple calls to WP_Image_Editor_Imagick::supports_mime_type(), often triggered during tasks like setting up wp_plupload_default_settings(). The cache, stored for one day, speeds up editor loading times and introduces a new global caching group, image_editor, to manage future optimizations for image editor performance.

Media: Improve speed of AVIF image generation

In #61758, the change results in the AVIF encoder working faster by raising heic:speed to 7 from the default of 5. AVIF generation time is reduced by up to 20% with minimal impact on image size.

Editor: New 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. type registration APIs to improve performance

In #62002, new block type registration APIs were introduced, offering a more efficient way to manage block metadata and improve performance across the board. These APIs allow developers to register blocks more flexibly, reducing server-side processing and enhancing editor load times. With these changes, WordPress lays the groundwork for faster, more scalable block-based experiences while maintaining backward compatibility. Explore the details in the official dev note.

Editor: Caching Global Styles for Blocks

In #59595, profiling WordPress 6.4 revealed that the WP_Theme_JSON::compute_style_properties method could account for 6-11% of server time during page generation. To address this, the editor now caches the generated CSSCSS Cascading Style Sheets. for block nodes derived from merged Theme 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. data. By saving the computed styles in a transient, WordPress avoids repeated and resource-intensive operations, significantly improving performance and reducing server load. This change is a key optimization for sites leveraging block themes and theme.json.

Themes: Improve performance of applying background image styles in theme.json.

In #61858, the cost of using WP_Theme_JSON::get_block_nodes() for this in its original shape was high enough to lead to a performance regression. Therefore this changeset introduces a new option on the method that allows to bypass all logic except for retrieving the node paths, which is much faster and everything that this functionality needs.

Miscellaneous Editor improvements:

In addition to the previously listed editor improvements, this release includes the following list of changes that improves the editor experience itself:

Additional performance focused changes

In total, there were 23 performance related improvements included in this release, split evenly between new enhancements (12) 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 (11).

Performance metrics

In our analysis, block themes (Twenty Twenty-Four was tested) experienced a modest regression in performance. The median Largest Contentful Pain (LCP) time increased by ~6ms or ~3.5% in tests, and the median Time To First Byte (TTFB) shows a 2ms (2%) regression.

Classic themes show a slight improvement (Twenty Twenty-One was tested). The median Largest Contentful Pain (LCP) and Time To First Byte (TTFB) time shows a slight 0.2ms or 0.2% improvement in tests.

How release performance is measured

The performance measurements used for the overview are based on benchmarks conducted using an automated workflow on 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/ action runners. Benchmarks were taken from the homepage of the Twenty Twenty-one, Twenty Twenty-three, and Twenty Twenty-four themes, comparing WordPress 6.7 with WordPress 6.6.2 (the latest version of WP 6.6 available when 6.7 was released).

Performance metrics were collected from 100 runs for both CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Web Vitals (CWV) and Server-Timing headers provided by the Performance Lab pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party using CLI scripts from the WPP Research repo.

Benchmark Data

Follow up from this release

WordPress 6.7 shows a regression in performance. While some overhead typically accompanies new features, these declines point to areas where the performance team continues to investigate where these regressions came from and how they can be addressed in the upcoming releases.

Each release, the Performance Team looks for opportunities to improve the performance of WordPress for the following releases, which includes identifying ways we can improve the tooling and processes we use to support the performance practice. For example, we’re collecting opportunities to improve our performance testing in this GitHub issue

Performance Lab – the plugin(s) we use to test out new performance features for core – continues to add new features such as Image Prioritizer , Embed Optimizer, Speculative Loading, Performant Translations, Modern Image Formats, Enhanced Responsive Images, and Web Worker Offloading.

You can also follow progress on other performance-related work being planned for the WordPress 6.8 release in Trac. A full list of the Performance Team’s priorities for the year is available on the 2024 Roadmap page. Additionally, the 2025 Roadmap will be published early in Q1 2025 in the team’s handbook. Come join us in making WordPress as performant as possible.

Props to @joemcgill, @flixos90, @westonruter, and @fabiankaegy for contributing to this post.

#6-7, #core, #core-performance, #performance

Hallway Hangout: Performance End of Year Review 2024

Following up on the prior performance related Hallway Hangout: Performance End of Year Review 2023 in December, @flixos90 @joemcgill and @clarkeemily co-hosted a hallway hangout to review the work and impact of the performance team in 2024, and look ahead to performance improvements in WordPress for 2025.

The Hallway Hangout took place at 2024-12-17 16:00 UTC and the Google Meet link was shared in the #core-performance SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel before starting.

At a high level, we went through:

  • Review of WordPress performance improvements throughout 2024
  • Breaking down CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Web Vitals metrics (November 2023 – November 2024) resulting in CWV passing rates increasing by 6.07% on mobile and 5.92% on desktop
  • WordPress 2024 releases overview (6.5, 6.6 and 6.7) were discussed individually
  • The impact of specific metrics for major features released in 2024 (Enhanced translations engine, 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. and image sizes=auto)
  • A look ahead to 2025 plans

As a reminder, hallway hangouts are meant to be casual and collaborative so come prepared with a kind, curious mind along with any questions or items you want to discuss around this important area of the project, especially since the agenda is intentionally loose to allow for it.

Noting this specifically for folks who have expressed interest previously or who are involved directly in this work cc @hellofromtonya @aristath @oandregal @annezazu @illuminea @tweetythierry @desrosj @youknowriad @dmsnell @pbearne @swissspidy @westonruter @adamsilverstein @mukesh27 @joemcgill @johnbillion @linsoftware @spacedmonkey

Recording

Attendees:

@pbearne @joemcgill @benniledl @flixos90 @mukesh27 @mhamal @clarkeemily @b1ink0 @nazmul111 @shyamgadde @kafleg @westonruter @swissspidy @adamsilverstein @annamackenzie

Notes

@flixos90 presented the WordPress Performance 2024 CWV Impact Retrospective slide deck, thank you very much for pulling that together Felix.

Please click the image above to view the slide deck

    TTFB Improvements

    @pbearne @flixos90 @joemcgill @westonruter and @adamsilverstein were discussing TTFB passing rates and why the rest of the web has higher rates than WordPress due to that metric. Discussions were held around filtering sites to the top 10k or 100k of sites to re-evaluate passing rates without the bottom end of sites that are not set up correctly. When WordPress is configured correctly, passing rates are much higher, so it was suggested that outreach in the ecosystem may be encouraged to facilitate better hosting environments. The new Core #core-performance-hosting channel will help facilitate these conversations.

    The team went on to discuss file caching and the potential to introduce a file caching API in core. It was agreed this would be a very large effort and would need contribution from multiple teams. We would need to revisit the original decision from WordPress to keep file caching in 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 territory as opposed to within Core. We would also need significant investigation into the large number of WordPress sites where static caching is not something their site can support. 

    Auto Sizes Metric

    The team discussed whether the auto-sizes metric in the slides was the top 70th percentile (it is). 

    Plans for 2025

    There are still some projects ongoing from 2024 to land, speculative loading now has a 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.. Next steps on responsive image sizes improvements are in progress. The accurate image sizes work. The last piece of dominant colour is going in too! 

    Accurate Image sizes

    The project @joemcgill and @mukesh27 are focusing on will have significant releases this week, around having more detail on the layout of the page and how we can make more informed choices about accurate image sizes. This essentially takes the layout information of image blocks and cover blocks, but also the constraints of the container around it (group blocks) so we can put limits on the size we expect to show things at. The discussion continued around how we can accurately set image sizes in WordPress. 

    Optimization Detective

    @westonruter is continuing to work on the optimisation detective plugin which will include prioritisation of background images defined in external file sheets – this will dramatically improve LCP. In the new year he will be continuing to refine the foundation and use cases to hopefully get more adoption and propose for core. @flixos90 reminded the team that this is a great plugin example which improves how well other performance optimisations are applied. It’s important to improve what we already have in core, and this plugin helps that.

    Props to @joemcgill for proof reading and @flixos90 for the excellent presentation.

    #core-performance, #hallwayhangout, #performance

    Agenda, Dev Chat, Dec 4, 2024

    The next WordPress Developers Chat will take place on Wednesday at 20: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

    There are no major announcements from the past week.

    Forthcoming releases

    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. The call for volunteers for the 6.8 release squad is open until Dec 6. There is also a proposal open for the major releases for 2025.

    Next maintenance release: 6.7.2

    There is currently no release date planned for WordPress 6.7.2. Review the next minor release milestone.

    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/ release: 19.8

    The next Gutenberg release will be 19.8, scheduled for December 4. It will include the following issues.

    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.

    If you want 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.

    Editor Updates

    You can keep up to date with the major Editor features that are currently in progress by viewing these Iteration issues.

    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 if you intend to be available during the meeting for discussion or if you will be async.

    Props to @joemcgill and @annezazu for contributing to this agenda.

    #6-8, #agenda, #dev-chat

    What’s new in Gutenberg 19.7? (20 November)

    “What’s new in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/…” posts (labeled with the #gutenberg-new tag) are posted following every Gutenberg release on a biweekly basis, showcasing new features included in each release. As a reminder, here’s an overview of different ways to keep up with Gutenberg and the Editor.



    Gutenberg 19.7 has been released and is available for download!

    1. Global Styles available on the main site editor sidebar
    2. Swifter hiding & showing the template
    3. Set image blocks as featured image
    4. Changelog
    5. First-time contributors
    6. Contributors

    Global Styles available on the main site editor sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme.

    The site editor sidebar is getting increasingly powerful, serving as the entry point to manage all-things your site. Up until this version, the styles panel offered limited style settings, focusing on style variations, color palettes, and typographies. Gutenberg 19.7 changes this by introducing a full-fledged Global Styles panel in its place, giving users site-wide granular control on styles at the top level.

    Swifter hiding & showing the template

    Switching between editing your site templates and content pages should be as smooth and seamless as possible; sometimes, you need to focus on the post content and hide the rest of the template. This was previously possible in the post settings, but now it is much easier thanks to the `Show template` toggle directly on the preview dropdown in the top toolbar.

    Featured images offer a nice touch in external previews, making them more attractive to potential readers. However, it can be easy to forget to set one! To help set featured images more easily, image blocks now offer a dropdown action to directly set them as the featured image of the post or page containing 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..

    Continue reading

    #gutenberg, #gutenberg-new