Updates to the Interactivity API in 6.6

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. development for WordPress 6.6 has been focused on maintenance. Its updates include new features and directives, a better debugging experience, and improved code quality.

Table of Contents

New async directives

WordPress 6.6 includes three new directives aimed at improving performance:

  • data-wp-on-async
  • data-wp-on-async-document
  • data-wp-on-async-window

These async directives optimize event callbacks by first yielding to the main thread. That way, complex interactions won’t contribute to long tasks, improving the Interaction to Next Paint (INP). You can read more about this approach in Optimize Interaction to Next Paint.

These directives are recommended over the sync ones (data-wp-ondata-wp-on-document, and data-wp-on-window), but you can use them only when you don’t need synchronous access to the event object, specifically if you need to call event.preventDefault()event.stopPropagation(), or event.stopImmediatePropagation(). The directives in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks have been updated to use async where available.

When you must resort to using the non-async directives, the @wordpress/interactivity package now exports a splitTask function which can be used to manually split yield an action to the main thread after calling the synchronous event API. Please see the documentation on async actions for how to implement this.

GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ pull requests: #61885 and #62665

Support for derived state props inside wp_interactivity_state

Since WordPress 6.5, developers can define the initial state of interactive blocks in the server with wp_interactivity_state(). Directives referencing these state properties are evaluated to render the final HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.. However, derived state props, defined as getters in 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/., were a feature missing in PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher.

In WordPress 6.6, the wp_interactivity_state() function now accepts derived state props using Closures (anonymous functions). This feature is equivalent to the getters already used in JavaScript inside the store() function exposed from the @wordpress/interactivity package.

const { state } = store( 'myPlugin', {
	state: {
		taxRate: 0.21,
		shippingFee: 4,
		get priceWithTax() {
			const context = getContext();
			return context.basePrice * ( 1 + state.taxRate );
		},
		get totalPrice() {
			return state.priceWithTax + state.shippingFee;
		}
} );

In the same way, the Closures can access the current Interactivity API context by calling the new wp_interactivity_get_context() function―equivalent to their JavaScript version, getContext(). This function returns the current context for either the current namespace―when omitted―or the specified one. Also, wp_interactivity_state() can be used when the value depends on other parts of the state.

wp_interactivity_state( 'myPlugin', array(
	'taxRate'      => 0.21,
	'shippingFee'  => 4,
	'priceWithTax' => function() {
		$state = wp_interactivity_state();
		$context = wp_interactivity_get_context();
		return $context['basePrice'] * ( 1 + $state['taxRate'] );
	},
	'totalPrice'   => function() {
		$state = wp_interactivity_state();
		return $state['priceWithTax']() + $state['shippingFee'];
	}
) );

It’s important to note that using Closures for derived state is not always necessary. When the initial value is static, and the Closure will always return the same value because the values it depends on do not change on the server, regular values can be used instead:

$basePrice    = 100;
$taxRate      = 0,21;
$shippingFee  = 4;
$priceWithTax = $basePrice * ( 1 + $taxRate );
$totalPrice   = $priceWithTax + $shippingFee;

wp_interactivity_state( 'myPlugin', array(
	'basePrice'    => $basePrice,
	'taxRate'      => $taxRate,
	'shippingFee'  => $shippingFee,
	'priceWithTax' => $priceWithTax,
	'totalPrice'   => $totalPrice,
) );

Read more about this new feature on the TRACTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #61037 and in the GitHub Issue #6394

Integration with Preact Devtools

The Interactivity API runtime uses Preact internally to transform directives into components and manage all DOM updates. Since WordPress 6.6, developers can use Preact Devtools to inspect interactive blocks and check the component tree for all rendered directives.

To enable this feature, the SCRIPT_DEBUG constant must be enabled. This constant makes WordPress serve an extended version of the Interactivity API runtime that’s compatible with the Preact dev tools.

In the future, there are plans to improve the displayed information by including the names of the directives used in each of the elements, among other enhancements.

Read more about this new feature on the TRAC ticket #61171 and in the GitHub PR #60514

Interactivity API warnings in 6.6

In WordPress 6.6, both the server-side directives processing and the JavaScript runtime will warn developers when the directives, the namespace, or the markup cannot be evaluated.

To enable this feature, the SCRIPT_DEBUG constant must be enabled.

Warning messages will be shown for the following cases:

Unbalanced HTML tags

If the processed HTML contains any unbalanced tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.), the server processing will bail out. This causes the flash effect on page load. Now, developers will find which tag is missing within a warning message.

One example could be <span data-wp-text=”hello” />

Unsupported HTML tags

Some tags, like SVG or MathML ones, are not yet supported by the HTML API, which is used internally by the Interactivity API. Directives inside them or in their inner tags won’t be server-side processed. Now, a warning will appear if any directives are found in those positions.

Non-parseable data inside data-wp-context

The context data provided to data-wp-context directives must be a valid 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. stringified object.

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. namespace inside data-wp-interactive

The value passed to data-wp-interactive directive cannot be an empty object {}, an empty string, or a null value. Namespaces must be non-empty strings.

Props to @darerodz, @westonruter and @luisherranz for co-authoring this post
and to @fabiankaegy and @juanmaguitar for review

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

Summary, Dev Chat, June 26, 2024

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

Announcements

  • WordPress 6.6 RC1 was released on June 25. We are now in a hard string freeze. Note that the dev-feedback and dev-reviewed workflow is required prior to committing to the 6.6 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". (handbook reference).
  • WordPress 6.5.5, a security release, was shipped on June 24.
  • Gutenberg 18.6.1 was released on June 25.

Great work getting all of these milestones done this week :tada:

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

We are currently in the WordPress 6.6 release cycle. The WordPress 6.6 RC2 release is scheduled for next Tuesday, July 2. Please review this post for an update about the Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). Phase.

@meher brought up a discussion from the #6-6-release-leads channel about the string freeze in the release candidate stage. We discussed when the soft string freeze should happen and if it should exist, when the hard string should happen, how these two different freezes are different and if there are any exceptions.

@audrasjb highlighted the glossary items:

Hard freeze:
See String freeze. A hard string freeze or a hard freeze is announced when all the strings of the upcoming release are frozen including the strings of the About page. A hard freeze is the final string freeze before a release.

Soft freeze
See String freeze. A soft string freeze or “soft freeze” is announced when all the strings of an upcoming WordPress release are frozen, except for the strings of the About page.

@desrosj suggested we decide on the course of action for this release (6.6) and then do the research suggested here to adjust the practice going forward.

@audrasjb also found an example of a string change after the hard string freeze here.

@joemcgill summarised the next steps as follows:

  • We’re currently operating in a Hard Freeze for 6.6
  • @audrasjb is going to check with Polyglots to see if we can extend that date to RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 3
  • If we really do need Hard Freeze to start at RC1, we will update our docs for future releases

We’ll aim to have an update and share by next week’s Dev Chat.

Next maintenance release

No maintenance releases are currently being planned. However, we discussed follow-up tickets that were opened following the 6.5.5 release.

@audrasjb noted:

The most annoying post-6.5.5 ticketticket Created for both bug reports and feature development on the bug tracker. was #61488.
It was fixed in trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. and is waiting for potential backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. to branch 6.5. Question is: do we need a 6.5.6 for this?

@jorbin noted that we’re waiting to see how #61489 shakes out, and we should allow for a day or two if possible so that 6.5.7 does not need to follow quickly behind.

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: 18.7

Gutenberg 18.7 is scheduled for July 3 and will include these issues. This version will NOT be included in the WordPress 6.6 release.

Discussion

The main discussion was around 6.6 this week, so we moved straight onto the Open Floor section.

Open Floor

@grantmkin asked if we could discuss this issue to allow themes to side-load single block plugins, which could help seamlessly open up more creativity and options baked into 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. themes:

As I’ve been looking into the idea of canonical block plugins, one point of feedback I’ve received from theme designers is a desire to use such blocks in theme templates and patterns. One example shared was the desire for a tabs block to use in a product page template. If you’re releasing the theme for general use (rather than it being specific to an individual site) you’re currently limited to using coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks. And naturally, we’re conservative about adding new blocks to core. So I’m curious about possibilities for making more blocks available for use in themes and patterns.

There were several comments and questions raised, including:

  • Sounds a lot like 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 dependencies for theme. – @afragen
  • So not just starter content for themes, but starter blocks?  Interesting, seems pretty reasonable desire for themes. – @jeffpaul
  • I wonder what a fallback would look like if a block was no longer available in the repo as well? Would it just no longer show, or would there be a way for the external block to fall back to core blocks? – @joemcgill
  • In principle the idea of blocks like this is good because keeps them outside theme. – @karmatosed

@poena highlighted if the plugin that has that block is not installed, the user will be prompted to install it. If they don’t install it, they can keep the block as is, or delete it. So what is the problem we’re trying to solve with side-loading single block plugins?

@poena also noted that themes in the wordpress.org theme directory are not allowed to require plugins. That does not mean that those themes are not allowed to recommend and use block plugins.

@joemcgill encouraged folks to keep the convo going in the GH issue.

@mmaattiiaass also raised a discussion about the WordPress Importer project:

I would like to discuss the current state of WordPress-importer project. I think it’s an important piece for production sites, and it seems to be unattended.
Example: the font assets can not be imported automatically because that functionality wasn’t shipped to the users. There’s a PR adding that functionality that has been sleeping for months without any review despite being flagged as a blockerblocker A bug which is so severe that it blocks a release. for the font library in the WordPress 6.5 release.

@jeffpaul noted that the Import component team is vacant: https://make.wordpress.org/core/components/import/.

@joemcgill offered to do some research to find some answers.

Finally, @azaozz asked for more reviews on #60835:

#360835 is a fix for few bugs introduced in WP 6.5. It’s been ready for about two months now. Yes, there are some different opinions there but the best way to iron out any differences is to have more reviews, right? 

@joemcgill highlighted that as an aside, it seemed like one of the things that has stalled the refactoring efforts is that there was an expectation set that there would be a proposal posted on make/core outlining the plan for more top-level directories like the /fonts directory. Joe offered to follow up with any updates for this.

Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.

Props to @joemcgill for proofreading.

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

WordPress 6.6 Release Candidate Phase

Now that WordPress 6.6 has entered the Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). (RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).) phase, the following policies are in place.

These policies mainly cover how and when CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers can commit. For non-committing contributors, this post may help explain why a Core committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. makes a certain decision.

String Freeze

To allow the Polyglots teamPolyglots Team Polyglots Team is a group of multilingual translators who work on translating plugins, themes, documentation, and front-facing marketing copy. https://make.wordpress.org/polyglots/teams/. time to get their local language’s translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. of WordPress ready, no new strings are permitted to be added to the release. Existing strings can be removed and/or duplicated if needed.

Seek guidance from the Polyglots team leadership for any strings reported as buggy. A buggy string is one that can not be translated to all languages in its current form. In such case, another RC may eventually be released to update the related strings. This will be done in a responsible and reasonable manner, only when necessary.

Tickets on the WordPress 6.6 milestone

For the remainder of the cycle, only two types of tickets may be placed on/remain on the 6.6 milestone:

  • Regressions: bugs that have been introduced during the WordPress 6.6 development cycle, either to existing or new features.
  • Test suite expansion: tests can be committed at any time without regard to code or string freezes. This can cover either new or existing features.

Trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. is now WordPress 6.7-alpha

WordPress 6.6 was recently forked to its own branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch"., trunk is now open for commits for the next version of the software.

Backporting to the 6.6 branch

Backporting commits of production code (that is, anything that ends up in the zip file) now requires double sign-off by two core committers. The dev-feedback keyword should be used to request a second committer’s review, dev-reviewed should be added to indicate a second committer has reviewed and approved the commit to the 6.6 branch.

Commits to the test suite and docblockdocblock (phpdoc, xref, inline docs) changes do not require double sign-off.

Props to @peterwilsoncc for writing the initial post that inspired this one, and to @meher and @hellofromtonya for peer review.

#6-6

WordPress 6.6 Field Guide

This guide outlines major developer features and breaking changes in 6.6 and is published in the Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). cycle to help inform WordPress extending developers, CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. developers, and others.

There are almost 299 Core TRACTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets included in WordPress 6.6, 108 of which are enhancements and feature requests, 171 bug fixes, and 10 other blessed tasks. This time, 16 tickets focused on performance, 24 on accessibility, and 15 on modernizing code and applying coding standards. Changes in 6.6 are spread across 40 Core components.

This release includes 392 enhancements, 462 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, and 46 accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) improvements for the Block Editor (a.k.a. gutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/).

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


Table of contents


    BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor

    WordPress 6.6 brings 8 Gutenberg releases into core – 17.8, 17.9, 18.0, 18.1, 18.2, 18.3, 18.4, and 18.5. The Block Editor receives several improvements related to the ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. library, the Block 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., Themes, and more.

    React

    A new version of React and the new JSX transform is available in WordPress 6.6.

    Block API

    Some Block API improvements available in WordPress 6.6 include:

    • Unification of slots and extensibility APIs between the post and site editors
    • Improvements on isActive property of Block variations
    • Improvements on some core blocks
    • Block Bindings: Editing custom fields from connected blocks

    Themes

    WordPress 6.6 introduces several theme-related updates, including:

    • A new version 3 of theme.json
    • Uniform CSSCSS Cascading Style Sheets. specificity applied across core styles
    • Introduction of section styles to streamline the styling of blocks and their internal elements
    • Additional features for the grid layout type in blocks
    • Capability to define site-wide background images in theme.json and the Site Editor

    Miscellaneous Block Editor Changes

    Some other updates to the Block Editor are also included in WordPress 6.6:

    A table on design tools supported per block at WordPress 6.6 has been published as a reference.

    Interactivity API

    WordPress 6.6 includes updates for the Interactivity API, such as new async directives, support for derived state props from PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher, integration with Preact Devtools, and new warning messages available when the SCRIPT_DEBUG configuration constant is enabled.

    HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. API

    WordPress 6.6 includes a helpful maintenance release to the HTML API. This work includes a few new features and a major improvement to the HTML Processor’s usability. This continues the fast-paced development since WordPress 6.5.

    There’s also a new data structure coming in WordPress 6.6 for the HTML API: the WP_Token_Map.

    Options API

    Several changes have been made to the Options API to support an optimization for the autoloading behavior, and to create a way to apply further optimizations going forward.

    PHP Support

    Support for PHP 7.0 and 7.1 is dropped in WordPress 6.6.

    I18Ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.

    Various internationalization (i18n) improvements are in WordPress 6.6, including:

    Miscellaneous Developer Changes

    Some other changes included in WordPress 6.6 are:

    Other updates

    One of the highlight features included in WordPress 6.6 is the automatic rollback of 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 auto-updates upon detecting PHP fatal errors.

    New/Modified HooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.

    For a list of all new and updated Functions/Hooks/Classes/Methods in WP 6.6, please see this page on Developer Resources after the release: https://developer.wordpress.org/reference/since/6.6.0/.

    Modified 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

    New Filter Hooks

    • interactivity_process_directives [58234]
    • wp_theme_files_cache_ttl [58025]
    • wp_default_autoload_value [57920]
    • wp_max_autoloaded_option_size [57920]
    • wp_autoload_values_to_autoload [57920]
    • lang_dir_for_domain [58236]
    • activate_tinymce_for_media_description [58372]
    • site_status_autoloaded_options_action_to_perform [58332]
    • site_status_autoloaded_options_size_limit [58332]
    • site_status_autoloaded_options_limit_description [58332]

    New Action Hooks

    • delete_post_{$post->post_type} [57853]
    • deleted_post_{$post->post_type} [57853]

    Props to @sabernhardt, @milana_cap, @stevenlinx and @bph for review.

    #6-6, #dev-notes, #field-guide

    Miscellaneous developer changes in WordPress 6.6


    Table of contents


    Autosave

    Allowed disabling autosave support for individual post types

    [58201] added a way to allow disabling autosave support for individual post types. Not all post types support autosaving. By making autosave a post type feature, support can be more granularly handled without any workarounds or hardcoded allowlists. For backward compatibility reasons, adding editor support implies autosave support, so one would need to explicitly use remove_post_type_support() to remove it.

    See #41172 for more details.

    Bundled Theme

    Twenty Sixteen: Fixed mismatch of visual and DOM order of elements

    Starting in Twenty Sixteen’s version 3.3 (released with WordPress 6.6), the site information links remain below the social navigation at any screen size. Before that, the social navigation had displayed after the site information on larger screens, which created a mismatch between the visual order and the Document Object Model (DOM) order.

    Site, Privacy Policy, and Proudly powered by WordPress links appear beneath three social icon links in the site footer
    The two footer elements are stacked, now at screen widths larger than 910 pixels.

    If you would like to have the two elements side-by-side, with the social navigation first, you could paste styles in a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. or in the Customizer’s Additional CSS panel.

    Check the instructions on how to do this
    @media screen and (min-width: 56.875em) {
    	/*
    	  1. Reset the social navigation width.
    	  2. Adjust margins to place site info along the right edge.
    	*/
    	.site-footer .social-navigation {
    		width: auto;
    		margin: 0.538461538em auto 0.538461538em 0;
    	}
    	.site-info {
    		margin: 0;
    	}
    
    
    	/* Reverse the margins for right-to-left languages. */
    	.rtl .site-footer .social-navigation {
    		margin: 0;
    	}
    	.rtl .site-info {
    		margin: 0.538461538em auto 0.538461538em 0;
    	}
    }
    
    Three social icon links appear on the left side of the site footer, but Site, Privacy Policy, and Proudly powered by WordPress links are on the right.
    Custom CSSCSS Cascading Style Sheets. could place the site information links on the right side.

    See #60496 for more details.

    Comments

    Default length of time for comment author cookies has changed

    [58401] changed the default length of time for comment author cookies from 0.95129375951 of a year to 1 year by taking advantage of the YEAR_IN_SECONDS constant. The comment_cookie_lifetime filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. can still be used to change this value.

    See #61421 for more details.

    Editor

    Site Editor Patterns on Classic Themes

    #61109 now directs a classic theme’s Appearance > Patterns menu to the site editor Patterns view (/wp-admin/site-editor.php?path=/patterns), providing a consistent pattern and template management experience regardless of theme type. For themes with block-template-parts support, the Appearance > Template Parts menu has been removed, with template parts now accessible under the site editor’s Patterns > Template Parts view.

    Fluid Typography

    Some theme.json presets require custom logic to generate their values, for example, when converting font size preset values to clamp() values.

    The custom logic is handled by callback functions defined against the value_func key in WP_Theme_JSON::PRESETS_METADATA. The callback functions are invoked in WP_Theme_JSON::get_settings_values_by_slug().

    In WordPress 6.6, settings of the current WP_Theme_JSON instance, are now passed to these callback functions. The permits callback functions to return values that rely on other settings in the 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. tree.

    In the case of font sizes presets, it fixes a bug whereby the callback function — wp_get_typography_font_size_value() — was not taking into account settings values passed directly to the WP_Theme_JSON class.

    External libraries

    jQuery UIUI User interface library update

    The jQuery UI library was updated to version 1.13.3. For more information on the changes included, see jQuery UI 1.13.3 release notes.

    Login and Registration

    New array arguments for wp_login_form

    The wp_login_form() function has two new array arguments: required_username and required_password. Passing true to these arguments adds the ‘required’ attribute to the input fields.

    $args = array(
        'required_username' => true,
        'required_password' => true,
    );
    wp_login_form( $args );
    

    There is no change to the default field output.

    See #60062 for more details.

    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

    Custom ports for multisite site addresses

    #21077 made it possible to install and operate a Multisite installation on a host name that includes a port number, and the corresponding #52088 added full support for this to the local development environment. This means it’s now possible to run Multisite on an address such as localhost:8889.

    Update enabled mime types for new multisite installs

    In #53167, the list of mime types that are enabled for upload were aligned to those enabled by regular sites by switching from a hard-coded list of types (that had become outdated) to using coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s get_allowed_mime_types function. This ensures that new multisite installs are up to date with the current mime types supported in core, including the recently enabled image/webp and image/avif types.

    Note that, since this is only used to populate the schema for new networks, it will only affect newly created multisite networks – it does not change the allowed mime types for existing networks. To adjust the mime types allowed for existing sites, developers can continue to use an approach as follows for filtering the upload_filetypes option:

    Script Loader

    Obsolete polyfills dependencies have been removed

    In [57981], now obsolete polyfills such as wp-polyfill, wp-polyfill-inert and regenerator-runtime were removed from the react script dependency in WordPress, as they are no longer needed in modern browsers supported by WordPress. Developers relying on wp-polyfill need to manually add it as a dependency to their scripts.

    See #60962 for more details.

    Script modules can now be used in the WordPress adminadmin (and super admin)

    With #61086, script modules can now be used in the WordPress admin. Before WordPress 6.6, script modules were only available on the front end.

    Toolbar

    Search has a much later priority

    In [58215], the search input on the front-end admin bar is added at a different priority. It was previously inserted at priority 4 and then floated to appear at the end of the admin bar. It is now inserted at priority 9999 to load at the end of the admin bar without CSS manipulation.

    Extenders placing admin bar nodes after the search or replacing core search should take the new priority into consideration.

    Example: Assign different priority based on WordPress version

    $priority = ( version_compare( $GLOBALS['wp_version'], '6.6-alpha', '>=' ) ) ? 4 : 9999;
    add_action( 'admin_bar_menu', 'wpadmin_toolbar_test_link', $priority );
    /**
     * Add a node to the WP admin toolbar.
     *
     * @param object $wp_admin_bar WP Admin Bar object.
     */
    function wpadmin_toolbar_test_link( $wp_admin_bar ) {
    	$wp_admin_bar->add_node(
    		array(
    			'parent' => 'top-secondary',
    			'id'     => 'mylink',
    			'href'   => '#',
    			'title'  => __( 'My Link' ),
    		)
    	);
    }
    

    See #60685 for more details.


    Props to @swissspidy, @jorbin, @johnbillion, @audrasjb, @joedolson, @ironprogrammer, @ramonopoly, @jonsurrell, @sabernhardt, @jdy68, @afercia and @juanmaguitar for their contribution and/or reviews.

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

    Updates to the HTML API in 6.6

    WordPress 6.6 includes a helpful maintenance release to 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.. Included in this work are a few new features and a major improvement to the usability of the HTML Processor. This continues paced development since WordPress 6.5.

    Table of Contents

    1. A spec-compliant text decoder.
      1. An idealized view of an HTML document.
      2. An optimized class for looking up string tokens and their associated mappings.
    2. Features
    3. Bug Fixes

    A spec-compliant text decoder.

    This may be surprising, but PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher leaves us hanging if we want to properly read the text content of an HTML document. The html_entity_decode() and htmlspecialchars_decode() functions work somewhat well for pure XML documents, but HTML contains more complicated rules for decoding, rules which change depending on whether the text is found inside an attribute value or normal text. These functions default to XML and HTML4 parsing rules and require manually setting the ENT_HTML5 flag on every invocation (for example, HTML5 redefined two of HTML4’s character references), but are still wrong in many cases.

    Luckily you shouldn’t need to know about or call the new decoder, developed in Core-61072. It fits into get_modified_text(), further improving the HTML API’s implementation without requiring you to change any of your existing code. With WordPress 6.6 your existing code becomes more reliable for free.

    One part of this change you might want to know about is WP_HTML_Decoder::attribute_starts_with(). This new method takes a plaintext prefix and a raw attribute value and indicates if the decoded value starts with the given prefix. This can be invaluable for efficiently detecting strings at the start of an attribute, as some attributes can be extremely large, and if not careful, naive parsers can overlook content hidden behind long slides of zeros.

    $html = 'bob&#x00000000000000000003a,';
    
    'bob&#x00000000000000000003a,' === html_entity_decode( $html, ENT_HTML5 );
    'bob:,' === WP_Text_Decoder::decode_attribute( $html );
    true    === WP_Text_Decoder::attribute_starts_with( $html, 'bob:' );
    

    In the case of extremely long attribute values (for example, when pasting content from cloud document editors which send images as data URIs), the attribute_starts_with() can avoid megabytes of memory overhead and return much quicker than when calling functions which entirely decode the attribute value.

    The new text decoder will mostly help ensure that the HTML API remains safe and reliable. There are complicated rules in parsing HTML, so as always, it’s best to leave the low-level work to the HTML API, preferring to call functions like get_attribute() and get_modified_text() directly instead of parsing raw text segments.

    An idealized view of an HTML document.

    The Tag Processor was initially designed to jump from 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.) to tag, then it was refactored to allow scanning every kind of syntax token in an HTML document. Likewise, the HTML Processor was initially designed to jump from tag to tag, all the while also acknowledging the complex HTML parsing rules. These rules largely exist in the form of a stack machine that tracks which elements are currently open. While the HTML Processor has always maintained this stack, it has never exposed it to calling code.

    In WordPress 6.6 the HTML Processor underwent a major internal refactor to report those stack events (when an element opens and when an element closes) rather than when it finds raw text that represents things like tag openers and tag closers. This is a really big change for calling code! Previously, the HTML Processor would track all elements, but only return when a tag or token appeared in an HTML document. For instance, it always knew that <p><p> represents two sibling P elements, but it only presented each opening P tag to calling code. Now, the HTML processor is going to present not only the tags and tokens that exist in the raw HTML text, but also the “virtual nodes” that are implied but not textually present.

    $processor = WP_HTML_Processor::create_fragment( '<h1>One</h3><h2>Two<p>Three<p>Four<h3>Five' );
    while ( $processor->next_token() ) {
    	$depth = $processor->get_current_depth();
        $slash = $processor->is_tag_closer() ? '/' : '';
    	echo "{$depth}: {$slash}{$processor->get_token_name()}: {$processor->get_modifiable_text()}\n";
    }
    

    Let’s compare the output in WordPress 6.5 against the output in WordPress 6.6.

    HTML Processor in WordPress 6.5

    H1:
    #text: One
    /H3:
    H2:
    #text: Two
    P:
    #text: Three
    P:
    #text: Four
    H3:
    #text: Five
    

    HTML Processor in WordPress 6.6

    3: H1:
    4: #text: One
    2: /H1:
    3: H2:
    4: #text: Two
    4: P:
    5: #text: Three
    4: /P:
    4: P:
    5: #text: Four
    3: /P:
    3: /H2:
    3: H3:
    4: #text: Five
    0: /H3:
    

    With the HTML API in WordPress 6.6, it’s possible to treat an HTML document in the idealized way we often think about it: where every tag has an appropriate corresponding closing tag in the right place, and no tags overlap. In WordPress 6.5, only the opening tags which appeared in the document return from next_tag(), and the </h3> closing tag appears as an H3 closing tag, even though the HTML specification indicates that it closes the already-open H1 element. In WordPress 6.6, every opening tag gets its closer, and the </h3> appears as if it were an </h1>. This is because the HTML Processor is exposing the document structure instead of the raw text.

    Two new methods make working with HTML even easier:

    • WP_HTML_Processor->get_current_depth() returns the depth into the HTML structure where the current node is found.
    • WP_HTML_Processor->expects_closer() indicates if the opened node expects a closing tag or if it will close automatically when proceeding to the next token in the document. For example, text nodes and HTML comments and void elements never expect a closer.

    With the help of these methods it’s possible to trivially detect when an element opens and closes, because the HTML Processor guarantees a “perfect” view of the structure.

    $processor = WP_HTML_Processor( $block_html );
    if ( ! $processor->next_tag( 'DIV' ) ) {
    	return $block_html;
    }
    
    $depth = $processor->get_current_depth();
    while ( $processor->get_current_depth() > $depth && $processor->next_token() ) {
    	// Everything inside of here is inside the open DIV.
    }
    if ( ! isset( $processor->get_last_error() ) ) {
    	// This is where the DIV closed.
    }
    

    An optimized class for looking up string tokens and their associated mappings.

    As part of the text decoder work the WP_Token_Map was introduced. This is a handy and efficient utility class for mapping between keys or tokens and their replacements. It’s also handy for efficient set membership; for example, to determine if a given username is found within a set of known usernames.

    Read more in the Token Map announcement.

    Features

    • The HTML Processor will now return the depth of the current node in the stack of open elements with get_current_depth(). [58191]
    • The HTML Processor now includes expects_closer() to indicate the currently-matched node expect a closing token. For example, no HTML void element expects a closer, no text node expects a closer, and none of the elements treated specially in the HTML API as atomic elements (such as SCRIPT, STYLE, TITLE, or TEXTAREA) expect a closer. [58192]
    • The WP_HTML_Decoder class can take a raw HTML attribute or text value and decode it, assuming that the source and destination are UTF-8. The HTML API now uses this instead of html_entity_decode() for more reliable parsing of HTML text content. [58281]
    • The HTML Processor now visits all real and virtual nodes, not only those which are also present in the text of the HTML, but those which are implied by what’s there or not there. [58304]

    Bug Fixes

    • Funky-comments whose contents are only a single character are now properly recognized. Previously the parser would get off track in these situations, consuming text until the next > after the funky comment. [58040]
    • The HTML Processor now respects the class_name argument if passed to next_tag(). Formerly it was overlooking this constraint. [58190]
    • The Tag Processor was incorrectly tracking the position of the last character in some tokens, internally and when bookmarking. While 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. did not affect the operation of the Tag Processor, it has been fixed so that future code which might rely upon it will work properly. [58233]
    • When subclassing WP_HTML_Processor the ::create_fragment() method will return the subclass instance instead of a WP_HTML_Processor instance. [58365]

    Props to @gziolo, @jonsurrell, @juanmaguitar, and @westonruter for reviewing this post and providing helpful feedback.

    #6-6, #dev-note, #dev-notes, #dev-notes-6-6, #html-api

    Introducing the Token Map

    There’s a new data structure coming in WordPress 6.6: the WP_Token_Map, but what is it? The ongoing work in the HTML API required the ability to find named character references like &hellip; in an HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. document, but given that there are 2,231 names this is no easy task. The WP_Token_Map is a purpose-built class designed to take a large set of static string tokens with static string replacements, and then be used as a lookup and replacement mechanism. That’s all very technical, so let’s see it in action and consider how it might be useful to you.

    As an important note: you probably don’t need this because it’s an optimized data structure built for lookup with a very large set of tokens. The examples are unrealistically short but are meant only to illustrate the class usage in a readable form. If working with small datasets it’s possibly faster for most purposes to stick with familiar tools like in_array() or associative arrays.

    The Token Map, in short, is a new semantic utility meant to answer one simple question: given a string and a byte offset into that string, does the next sequence of bytes match one of a known set of tokens, and if so, what is the replacement for that token? It’s designed as a low-level utility for use in combination with other string parsing logic.

    Continue reading

    #6-6, #dev-note, #dev-notes, #dev-notes-6-6

    Miscellaneous Editor changes in WordPress 6.6

    In this post, you will find dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. for smaller changes to the editor in WordPress 6.6.


    Table of contents


    Added wp-block-list class to the list 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.

    Styling a list block using the Site Editor or 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. also applied the style to other lists, partially or in full. This caused styling conflicts with blocks that use lists internally and with lists in the editor interface.

    The problem has been fixed by adding the CSSCSS Cascading Style Sheets. class wp-block-list to the <ul> and <ol> elements of the list block, and only applying the styling to lists with this class name.

    If you have relied on the list block styles to style generic lists, you may need to update your CSS.

    GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ pull request: #56469

    Props to @poena for writing the dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase..

    Allow view access of the template 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/. endpoint to anyone with the edit_post capability

    Before WordPress 6.6 the templates and template-parts REST API endpoints were restricted to only be viewed/edited by anyone with the edit_theme_options capability (Administrators). WordPress 6.6 changes the permission checks to allow any user role with the edit_post capability to view these endpoints. Editing is still restricted to the edit_theme_options capability.

    This change is because the post editor now includes the ability to preview a post’s template while editing the post. In WordPress 6.5, this option was limited to administrators only. However, WordPress 6.6 now supports previewing the template for all user roles.

    GitHub pull request: #60317

    Props to @fabiankaegy for writing the dev note.

    Unified split logic for writing flow

    RichText’s optional onSplit prop was deprecated and replaced with a block.json support key called splitting. The onSplit prop was only used by a few coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks (paragraph, heading, list item, and button), so it’s not expected that this affects a lot of third-party blocks.

    In any case, when the onSplit is used, splitting will still work but can’t be controlled as granularly as before: the callback won’t be called, and the block will split in a generic way.

    GitHub pull request: #54543

    Props to @ellatrix for writing the dev note.

    BlockPopover Component is now public

    The BlockPopover component is now publicly accessible. For more details, you can check the README.

    GitHub pull request: #61529

    Props to @gigitux for writing the dev note.

    Add 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. to modify the list of post content block types

    When WordPress renders a post/page’s template at the same time as the content, most template blocks are disabled/locked. However, some blocks, like the Post Title, Post Content, and Post Featured ImageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts., still allow users to edit the content within them. They get rendered in the contentOnly rendering mode.

    WordPress 6.6 now adds a filter to modify this list of blocks that should get the contentOnly rendering mode applied when rendered as part of the template preview.

    import { addFilter } from '@wordpress/hooks';
    
    function addCustomPostContentBlockTypes( blockTypes ) {
        return [ ...blockTypes, 'namespace/hello-world' ];
    }
    
    addFilter(
        'editor.postContentBlockTypes',
        'namespace/add-custom-post-content-block-types',
        addCustomPostContentBlockTypes
    );
    

    It is important that only settings that store their data in custom ways are exposed when rendered in this contentOnly mode. An example is a block that stores a subtitle 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.. Anything that gets stored to the standard block attributes won’t persist.

    GitHub pull request: #60068

    Props to @fabiankaegy for writing the dev note.

    Global Styles: Filter out color and typography variations

    In addition to style variations, WordPress 6.6 adds the ability for themes to create color and typography presets. These are subsets of style variations and give users the ability to replace the color or typography of a site without all the other changes that come in a style variation.

    To add color and typography presets to a theme, developers follow the same process as adding style variations, except that each variation must contain only color or typography rules. Any style variations that contain only these rules will be treated as presets and will appear under Global Styles > Typography or Global Styles > Colors > Palette.

    Style variations that already conform to this requirement, i.e. they contain only color or typography rules, will automatically be treated in this way. That means these style variations will no longer appear under Global Styles > Browse styles, but instead in the relevant section for either colors or typography.

    GitHub pull request: #60220

    Props to @scruffian for writing the dev note.

    Add custom Aspect Ratio presets through theme.json

    WordPress 6.6 adds a new two new properties to the settings.dimensions object in theme.json. settings.dimensions.aspectRatios allows defining your own custom Aspect Ratio presets. These presets will be used by any block that uses the aspectRatio block support. In core that means the Image, Featured Image, and Cover block.

    {
        "version": 2,
        "settings": {
            "dimensions": {
                "aspectRatios": [
                    {
                         "name": "Square - 1:1",
                         "slug": "square",
                         "ratio": "1"
                     },
                     {
                         "name": "Standard - 4:3",
                         "slug": "4-3",
                         "ratio": "4/3"
                     },
                ]
            }
        }
    }
    

    Additionally the settings.dimensions.defaultAspectRatios key allows you to disable the list of core aspect ratio presets.

    {
        "version": 2,
        "settings": {
            "dimensions": {
                "defaultAspectRatios": false
            }
        }
    }
    

    GitHub pull request: #47271

    Props to @fabiankaegy for writing the dev note.

    Root padding style updates

    Root padding styles have been updated to address inconsistencies in pattern display and make the application of padding more predictable across different sets of markup. It’s now expected that:

    • Padding is applied to the outermost block with constrained layout (this is the layout enabled when “Inner blocks use content width” is set).
    • Padding is applied to all blocks with constrained layout that are full width or wide width.
    • Padding is applied to all blocks with constrained layout inside a full width flow layout (this is the layout enabled when “Inner blocks use content width” is unset) block.
    • Nested full width blocks will always be full width: a full width block inside another full width block will extend to the edges of the viewport.

    GitHub pull request: #60715

    Props to @isabel_brison for writing the dev note.

    Added Text alignment block support

    WordPress 6.6 adds new block support for setting the horizontal alignment of text.

    This support is controlled by settings.typography.textAlign in theme.json, which defaults to true. To opt-in to this support for a block, add the supports.typography.textAlign field in block.json. For example:

    {
        "$schema": "https://schemas.wp.org/trunk/block.json",
        "apiVersion": 3,
        "name": "gutenpride/my-block",
        "title": "My Block",
        "supports": {
            "typography": {
                "textAlign": true
            }
        }
    }
    

    Currently, core blocks do not support textAlign and the Text Alignment UIUI User interface is implemented separately without this block support. In the future, it is planned to gradually migrate core blocks to this support as well, and progress will be tracked in this Github issue: #60763.

    The default horizontal alignment style can also be defined via theme.json. For example:

    {
        "$schema": "https://schemas.wp.org/trunk/theme.json",
        "version": 3,
        "styles": {
            "blocks": {
                "core/heading": {
                    "typography": {
                        "textAlign": "center"
                    }
                }
            }
        }
    }
    

    There is a known issue where the default horizontal alignment defined in the global styles or theme.json cannot be overridden on a block instance, which is currently being addressed in #62260.

    GitHub pull request: #59531

    Props to @wildworks for writing the dev note.


    Props to @juanmaguitar for review.

    #6-6, #dev-note, #dev-notes, #dev-notes-6-6

    Internationalization improvements in 6.6

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

    Enhanced support for only using PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. files

    WordPress 6.5 shipped with a completely new localization system with improved performance, which uses .l10n.php files in addition to .po and .mo files. This system was slightly enhanced in 6.6 to better support scenarios where only these PHP translation files exist, but not the others. This specifically applies to wp_get_installed_translations(), which is used to check which translations are installed, and the Language_Pack_Upgrader for updating translations.

    See #60554 for more details.

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

    A new lang_dir_for_domain filter has been added to WP_Textdomain_Registry, allowing plugins to override the determined languages folder when using just-in-time translation loading. This is mostly useful for multilingual plugins.

    See #61206 for more details.

    Additional context for the load_translation_file filter

    The load_translation_file filter was introduced in WordPress 6.5 to support changing the file path when loading translation files, regardless if it’s a PHP or an MO translation file. In 6.6, the 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. is passed as an additional argument to this filter, bringing it more in line with similar i18ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. filters.

    See #61108 for more details.

    Props to @audrasjb and @juanmaguitar for review.

    #6-6, #dev-note, #dev-notes, #dev-notes-6-6, #i18n

    Section Styles

    In WordPress 6.6, Section Styles simplify the process of styling individual sections of a webpage by offering users a one-click application of curated styles, eliminating the need for repetitive manual configuration.

    Table of Contents

    1. What’s Changed?
    2. Usage
      1. Registration of Block Style Variations
      2. Defining Block Style Variations
        1. Theme.json Partial Files
        2. Programmatically
        3. Via Theme Style Variations (Not Recommended)
    3. Backwards Compatibility
    4. Limitations
    5. What’s Next?
    6. Useful Links

    What’s Changed?

    Section-based styling has been enabled by extending the existing Block Styles feature (aka 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. style variations) to support styling inner elements and blocks. These enhanced block style variations can even be applied in a nested fashion due to uniform CSS specificity (0-1-0) for Global Styles introduced in WP 6.6.

    In addition block style variations can now be:

    • registered across multiple block types at the same time
    • defined via multiple methods; primarily through 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. partials, or by passing a theme.json shaped object in the style’s data given to existing block style registration functions
    • customized via Global Styles (see also current limitations)

    Usage

    Registration of Block Style Variations

    The block style variations that can be defined and manipulated through Global Styles are limited to those that have been registered with the WP_Block_Styles_Registry or via a block type’s styles property, such as Outline for the Button block. If a block style variation has not been registered, any theme.json or global styles data for it will be stripped out.

    Any unregistered block style variation defined within a theme.json partial with be automatically registered.

    Outlined below are three approaches to registering extended block style variations. The approaches leveraging theme.json definitions will automatically register the block style variation with the WP_Block_Styles_Registry.

    Defining Block Style Variations

    Outlined below are recommended approaches to registering extended block style variations.

    Theme.json Partial Files

    With the extension of block style variations to support inner element and block type styles, they essentially are their own theme.json file much like theme style variations. As such, block style variations also reside under a theme’s /styles directory. They are differentiated from theme style variations however by the introduction of a new top-level property called blockTypes. The blockTypes property is an array of block types the block style variation can be applied to.

    A new slug property was also added to provide consistency between the different sources that may define block style variations and to decouple the slug from the translatable title property.

    {
    	"$schema": "https://schemas.wp.org/trunk/theme.json",
    	"version": 3,
    	"title": "Variation A",
    	"slug": "variation-a",
    	"blockTypes": [ "core/group", "core/columns", "core/media-text" ],
    	"styles": {
    		"color": {
    			"background": "#eed8d3",
    			"text": "#201819"
    		},
    		"elements": {
    			"heading": {
    				"color": {
    					"text": "#201819"
    				}
    			}
    		},
    		"blocks": {
    			"core/group": {
    				"color": {
    					"background": "#825f58",
    					"text": "#eed8d3"
    				},
    				"elements": {
    					"heading": {
    						"color": {
    							"text": "#eed8d3"
    						}
    					}
    				}
    			}
    		}
    	}
    }
    

    Programmatically

    Within a theme’s functions.php or 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, a call can be made to register_block_style, passing it an array of block types the variation can be used with as well as a theme.json shaped style object defining the variation’s styles. The style object provided here will be absorbed into the theme’s theme.json data.

    register_block_style(
    	array( 'core/group', 'core/columns' ),
    	array(
    		'name'       => 'green',
    		'label'      => __( 'Green' ),
    		'style_data' => array(
    			'color'    => array(
    				'background' => '#4f6f52',
    				'text'       => '#d2e3c8',
    			),
    			'blocks'   => array(
    				'core/group' => array(
    					'color' => array(
    						'background' => '#739072',
    						'text'       => '#e3eedd',
    					),
    				),
    			),
    			'elements' => array(
    				'link'   => array(
    					'color'  => array(
    						'text' => '#ead196',
    					),
    					':hover' => array(
    						'color' => array(
    							'text' => '#ebd9b4',
    						),
    					),
    				),
    			),
    		),
    	)
    )
    

    This approach has been enabled as a temporary means to facilitate ergonomic definitions of shared block style variations through theme style variations. It is being flagged here for transparency however it will likely be deprecated soon as the Global Styles architecture is updated to address growing complexity and simplify its mental model.

    More details on what’s ahead for Global Styles can be found in this issue.

    Shared block style variations can be defined via styles.variations. Style data defined under styles.variations will be copied to, and merged with, variation data stored at the block type level for all block types that have a matching variation registered for it.

    Additionally, a new translatable title property has been added here to mirror the capabilities of the theme.json partial files outlined above.

    The key for the variation correlates to the slug property for theme.json partials. In the example below, this would be variation-a.

    {
    	"$schema": "https://schemas.wp.org/trunk/theme.json",
    	"version": 3,
    	"title": "Theme Style Variation",
    	"styles": {
    		"variations": {
    			"variation-a": {
    				"color": {
    					"background": "#eed8d3",
    					"text": "#201819"
    				},
    				"elements": {
    					"heading": {
    						"color": {
    							"text": "#201819"
    						}
    					},
    				},
    				"blocks": {
    					"core/group": {
    						"color": {
    							"background": "#825f58",
    							"text": "#eed8d3"
    						},
    						"elements": {
    							"heading": {
    								"color": {
    									"text": "#eed8d3"
    								}
    							}
    						}
    					}
    				}
    			},
    		}
    	}
    }
    

    Backwards Compatibility

    As the Section Styles feature was implemented via extensions to block style variations rather than as a replacement, existing block style variations will continue to work as before.

    Limitations

    The following limitations for block style variations in WordPress 6.6 should be noted:

    1. Only root styles, i.e. those that apply directly to the block type the block style variation belongs to, can be configured via Global Styles.
    2. Block style variations cannot redefine or customize inner block style variations.
    3. Block style variations do not support their own custom settings values (yet).
    4. Custom block style variations cannot be applied and previewed within the Style Book.

    What’s Next?

    The Global Styles UIUI User interface for block style variations will be updated to facilitate the customization of all available styles for inner elements and block types. This includes potentially enhancing the Style Book to support block style variations.

    Another future enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. is the possible support for settings per block style variations.

    Props to @bph, @oandregal and @juanmaguitar for review

    #6-6, #core-editor, #dev-note, #dev-notes, #dev-notes-6-6, #gutenberg