Proposal: Server to client data sharing for Script Modules

Abstract

Script Modules were introduced in WordPress 6.5. wp_add_inline_script is often used to initialize or make data available to Scripts. Feedback on Script Modules and explorations suggest this would be a useful feature for Script Modules, but nothing exists at this time. This post will describe the problem in detail and propose a solution. The proposed solution consists of three main points:

  • A new filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. runs for each Script Module that is enqueued or in the dependency graph. This filter allows arbitrary data to be associated with a given Script Module and added to the rendered page.
  • Script Module data is embedded in the page as 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. in a <script type="application/json"> 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.).
  • Script Modules are responsible for reading the data and performing their own initialization.
Read more: Proposal: Server to client data sharing for Script Modules

The feedback period will end 2024-05-24 (Friday, May 24). Please provide any feedback before then.

This post will use “scripts” to refer to WP Scripts and “modules” to refer to WP Script Modules.

Scripts or modules?

Most 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/. for WordPress is probably using scripts unless it was specifically compiled as a module. Modern JavaScript is often authored using import apiFetch from '@wordpress/api-fetch', which is module syntax. Until very recently, WordPress build tooling has always removed the module syntax and compiled a script.

Only the most recent WordPress version 6.5 introduced support for modules. WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. includes exactly two modules to expose functionality at this time: @wordpress/interactivity and @wordpress/interactivity-router. JavaScript that uses 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. is probably a module.

This post will talk about a common script dependency, wp-api-fetch. The @wordpress/api-fetch module mentioned in this post is hypothetical; it does not exist at this time.

A note about modules

It’s important to know a few things about scripts versus modules in the context of this post. A few key differences:

  • Scripts and their dependencies will be executed as the page is parsed even if a dependency is never directly used.
  • Script “exports” are attached to the window object, e.g. wp-api-fetch is available as window.wp.apiFetch.
  • Modules will execute after the page has finished parsing.
  • Module dependencies can be loaded on demand.
  • Modules have true encapsulation, using import and export to share values.
More about scripts and modules…

Scripts that are either enqueued or are dependencies of enqueued scripts will be added to the page as script tags, like <script src="path/to/script.js">. The browser will fetch and execute these scripts before it continues to parse the page. There are attributes like async and defer that can change how the browser executes scripts.

Modules that are enqueued will appear on the page as script tags of type module, like <script src="path/to/module.js" type="module">. Processing of modules is deferred, they will be executed after the whole document has been parsed. The async attribute will cause a module to execute in parallel as the document is parsed. WordPress Script Modules do not use async at this time.

Modules that are in the dependency graph of enqueued modules will appear in an importmap. This is a mapping of names to URLs so that a browser knows what module to fetch when it sees an import. It’s what associates the module used in a statement like import "a-module"; with a URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org { "imports": { "a-module": "path/to/a-module.js" } }.

The problem

Scripts often require some initialization or other data to work correctly in WordPress. The wp-api-fetch script is a good example, it requires a significant amount of configuration. For example, Core uses the following inline script to initialize wp-api-fetch so it can send requests to the appropriate place:

$scripts->add_inline_script(
	'wp-api-fetch',
	sprintf(
		'wp.apiFetch.use( wp.apiFetch.createRootURLMiddleware( "%s" ) );',
		sanitize_url( get_rest_url() )
	),
	'after'
);

This snippet uses PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher to create a string of JavaScript code with some data from PHP embedded. This will be included in a script tag that appears immediately after the script tag for wp-api-fetch, something like this:

<script src="path/to/wp-api-fetch.js"></script>
<script>
// The JavaScript code is printed here:
wp.apiFetch.use( wp.apiFetch.createRootURLMiddleware( "…/index.php?rest_route=/" ) );
// More code may follow from other calls to `wp_add_inline_script`…
</script>

Notice that the JavaScript depends on wp-api-fetch, it imperatively calls wp.apiFetch.use(…). That same approach with a hypothetical @wordpress/api-fetch module would look something like this:

<script type="importmap">
{ "imports": { "@wordpress/api-fetch": "…url/to/api-fetch-module.js" } }
</script>
<script type="module">
import apiFetch from '@wordpress/api-fetch';
wp.apiFetch.use( wp.apiFetch.createRootURLMiddleware( "…/index.php?rest_route=/" ) );
</script>

In this approach, the initialization module would fetch and execute the @wordpress/api-fetch module just to initialize it! That eliminates one of the important advantages of modules, their ability to load on-demand. 🤔 It looks like this imperative initialization isn’t a good fit for modules. Let’s see if there’s a better solution…

The proposal

Here are some requirements that arise from the naive implementation:

  • Modules should be fetched and initialized on demand.
  • Modules should be responsible for their own initialization when they’re executed.
  • Variables should be scoped to modules and not pollute the global namespace.
  • The data should introduce minimal overhead.

Add server data via filters

Filters provide a nice method to collect the data needed by modules. The WP_Script_Modules class introduces a new filter that runs for each module that is enqueued or present in the dependency graph. Adding or modifying data for a module looks like this:

add_filter(
	'scriptmoduledata_@wordpress/api-fetch',
	function ( $data ) {
		$data['rootURL'] =  sanitize_url( get_rest_url() )
		return $data;
	}
);

Multiple filters can be added to add or modify the data exposed to the script, and if no data is added, nothing will be serialized on the page for the client. It’s also worth mentioning that no JavaScript code is written in PHP, a nice improvement over wp_add_inline_script which requires valid JavaScript to be added.

A drawback to this approach is that all the data passed must pass through JSON. Data without a valid JSON representation is not supported by default.

Use an inert script tag to expose data on the client

The data is embedded it in the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. in a script tag:

<script id="scriptmoduledata_@wordpress/api-fetch" type="application/json">
{ "theData": "JSON Serializable data can be shared" }
</script>

This script tag is effectively ignored by the browser because of its type attribute. This approach is an example on MDN of how to embed data in HTML and it’s already used in WordPress to pass Interactivity API data to the client.

Because modules are always deferred, it should be safe to print these script tags at the bottom of the page. They should have limited impact on page load because the browser will not parse or execute the contents.

Modules read data from the script tag

This script tag doesn’t do anything on its own. The module is responsible for getting the data and performing its initialization when it executes:

if ( typeof document !== 'undefined' ) {
	const serializedData = document.getElementById(
		'scriptmoduledata_@wordpress/api-fetch'
	)?.textContent;
	if ( serializedData ) {
		let config = null;
		try {
			config = JSON.parse( serializedData );
		} catch {
			// there was a problem parsing the serialized data
		}
		performInitialization( config );
	}
}
function performInitialization( config ) {
	if ( config?.rootURL ) {
		registerMiddleware( createRootURLMiddleware( config.rootURL ) );
	}
	// etc.
}

This approach is used by @wordpress/interactivity to retrieve store data on the client.

Try it!

I’ve prototyped this proposal in the following PRs:

  • WordPress-develop PR 6433 applies the filters and adds the necessary filters to expose data to @wordpress/api-fetch. The proposal in this post is contained in this PR.
  • Gutenberg PR 60952 builds and registers the @wordpress/api-fetch module. This PR is helpful for testing, but is beyond the scope of this post.

Try it in the WordPress Playground here. If you run the following JavaScript in the inspector console —make sure you pick the JavaScript context, something like wp (scope:abc123)— you’ll see the @wordpress/api-fetch module log some initialization when it’s imported and then work as expected:

const { apiFetch } = await import( '@wordpress/api-fetch' );
await apiFetch( { path: '/wp/v2/block-types' } )
Screenshot of browser console showing the `@wordpress/api-fetch` module initializing on demand and being used to make a REST request.

Relevant links

Props @youknowriad, @cbravobernal, @bph, and @andronocean for review.

#javascript, #script-loader

WordPress 6.5.4: An upcoming maintenance release

A number 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 authors have reported that the fix introduced as a part of #60992 has not sufficiently helped their users, therefore #61269 is being proposed as a short cycle fix. In order to get this fix released quickly, WordPress 6.5.4 is being planned with the following schedule.

  • 30 May 2024 – 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). made available and announced here on the make/coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. site.
  • 5 June 2024 – Final release made available.

Specific times will be decided in advance and adjustments to the schedule may be made. All adjustments will be noted in this post.

Minor or Maintenance releases of WordPress are intended as bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.-fix only releases. If you have 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. that you think should be considered, please put it in the 6.5.4 milestone. If you have a 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/ issue, please add it to the 6.5.x Editor Tasks board. If you lack bug gardening capabilities and have a ticket or issue you wish to highlight for 6.5.4, please add a comment here.

Note: except in extreme situations, only bug fixes will be considered and generally only bugs that have been introduced during the 6.5 cycle.

Get involved with 6.5.4

Each of the open tickets in the milestone is going to require development work along with testing and review. Additionally, while the intent is for no new translated strings in this release, some locales have strings in 6.5 in need of translation.

General coordination for the release will happen in the #6-5-release-leads channel and decisions around code for the release will be made in the #core room.

This minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. will be led by @hellofromtonya, @costdev, and myself (@jorbin). If there are editor related issues that need to be included, @grantmkin has agreed to lead those as well.

Thanks to @joemcgill, @costdev, @grantmkin, and @hellofromtonya for prepublication review.

#6-5, #6-5-x

Agenda, Dev Chat, Wednesday May 29, 2024

The next WordPress Developers Chat will take place on  Wednesday May 29, 2024 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, as below. If you have ticketticket Created for both bug reports and feature development on the bug tracker. requests for help, please do continue to post details in the comments section at the end of this agenda.

Announcements

The scheduled date for WordPress 6.6 Beta 1 is June 4, which is 1 week from today. From this point on, core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. should focus on testing and fixing bugs discovered during 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. testing. We should also begin publishing 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. and the About page.

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. See the Roadmap Post for details about what is planned for this release.

Next maintenance release: 6.5.4

@jorbin has confirmed that there will be a 6.5.4 release scheduled for June 5, to accommodate #61269. An 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). is scheduled for May 30.

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

Gutenberg 18.5 RC is scheduled for May 31 and will include these issues.

Discussions

With the Beta 1 deadline quickly approaching, we’ll use the discussion time to check in on priority items for this release. Review the list of Editor Updates section of this agenda for a list of updates of several key features related to this release.

@fabiankaegy has flagged that there are a number of commits that still need to be synced from the Gutenberg repo as part of this tracking issue. He also is tracking related PRs in this table on the WP 6.6 Editor Tasks board. Support from folks to review and commit these PRs is appreciated as we approach the 6.6 beta 1 deadline.

Highlighted posts

Editor updates

Props to @annezazu for putting together a list of editor related updates.

Quick updates:

  • Grid layout: Stabilise grid layout visualiser and resizer saw a bonus aspect of the grid layout work land, offering a visual way to resize. Tied to this, a recent change makes the outlines of the visualizer easier to see based on the
  • Unify publish flows: Curious to hear from folks around a change to the Revisions panel making it behind a three dot menu (adding an extra step) rather than displaying it as a top level item in the post 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.. For scheduled posts, a PR is underway to ensure the publish date control selection is shown within the modal.
  • 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. shadows: Edit/create shadows in global styles landed and is in a solid spot for the release.
  • Block 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.: after more research and experiments, work to Add support for block name aliases for variations is being mostly pushed to 6.6 except for items from this list, which should all be significantly lower risk, and prepare the ground for the bigger changes (for are targeted for 6.7).
  • Inserter: PR is underway to explore showing all blocks when searching for blocks while a block is selected. The current experience shows either a limited set or no blocks depending on allowed blocks.
  • Data Views: a recent PR bootstraps an APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. to allow third-party developers to register and unregister post type actions. This is going to be available in the Gutenberg pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party only for now and is not planned for 6.7 but relates to the overall efforts.
  • 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)review and join a discussion around a recently opened issue for Consistent Sidebar DOM and Open/Closing Interactions

Opportunities to get involved and help:

Tickets for assistance

Tickets for 6.6 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 if there are any questions or you will be async.

Open floor

Items for this can be shared in the comments.

Props to @joemcgill for reviewing.

#agenda, #core, #dev-chat

Script Modules in 6.5

A new “Script Modules” interface has been introduced to support native JavaScript modules in WordPress. 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/. modules use import and export and are often referred to as ECMAScript Modules or “ESM”.

This post will refer to “scripts” and “modules” for Scripts and Script Modules concepts, respectively.

JavaScript modules are a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. web technology with a number of benefits like import and export for proper scoping, forced strict mode, and deferred loading. It’s important for WordPress to support modules and encourage their use as the future of JavaScript development.

Script Modules 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.

The interface is modeled after the existing scripts interface and should feel familiar. Modules are identified by a unique identifier (ID), analogous to a script handle.

The registered module ID should be identical to the imported module name in JavaScript. For example, the @wordpress/interactivity module can be used in another module as:

import * as interactivity from '@wordpress/interactivity';

Registered modules have an array of module dependencies. Dependencies can be a simple string (the dependency module ID) or an associative array of the following form:

$dependencies = array(
'id' => '@wordpress/interactivity',
'import' => 'dynamic' // Optional.
);

The array form optionally includes an import key with the value 'static' (default) or 'dynamic'. Dependencies that may not be needed or should only be loaded under some circumstances should use 'import' => 'dynamic'.

Note that these dependencies are module dependencies, not script dependencies. Script handles should not be listed as module dependencies.

The following functions are the most relevant parts of the interface for developers working with modules:

  • wp_register_script_module( string $id, string $src, array $deps = array(), $version = false ): Registers the module.
  • wp_enqueue_script_module( string $id, string $src = '', array $deps = array(), $version = false ): Marks the module to be enqueued. An optional $src argument can be provided to enqueue and register the module.
  • wp_deregister_script_module( string $id ): Deregisters the module.
  • wp_dequeue_script_module( string $id ): Unmarks the module so it is not enqueued.

Important notes

It’s strongly recommended that developers currently utilizing JavaScript modules in their extensions migrate to the Script Modules API. This will standardize behavior, bring a number of benefits, and prevent some of the following potential issues:

  • Any code that is currently using import maps may run into compatibility issues because multiple import maps are not currently supported.
  • If a module appears before an import map, an error will be triggered that causes the import map to be ignored. This would break some critical functionality that the Script Modules API relies on.

It’s important to migrate to the new API to prevent these issues. If it’s unfeasible to migrate, moving modules script to the footer may mitigate some of the potential issues.

Available modules

Two core modules are provided with 6.5.

@wordpress/interactivity is the interface for building interactive frontends with the Interactivity API.

@wordpress/interactivity-router defines an Interactivity API store with the core/router namespace, exposing relevant state and actions for client-side navigation.

There are no other core modules available at this time. The JavaScript packages available as scripts before 6.5 are not available as modules. For example, the @wordpress/api-fetch package corresponds to the wp-api-fetch script and is not available in WordPress as a module.

Working with Script Modules

The most relevant functions for working with modules are wp_register_script_module to register and wp_enqueue_script_module to enqueue modules. For example:

// Registers a module, it can now appear as a dependency or be enqueued.
wp_register_script_module(
'@my-plugin/shared',
plugin_dir_url( __FILE__ ) . 'shared.js'
);

// Registers and enqueues a module.
wp_enqueue_script_module(
'@my-plugin/entry',
plugin_dir_url( __FILE__ ) . 'entry.js',
array( '@my-plugin/shared' )
);

// Enqueues a previously registered module.
wp_enqueue_script_module( '@my-plugin/a-registered-module' );

In this example, the @my-plugin/shared module will be available to the @my-plugin/entry module:

// "@my-plugin/entry" module at …/entry.js
import * as shared from '@my-plugin/shared';
shared.doSomethingInteresting();

Blocks

WordPress 6.5 introduces a new viewScriptModule block metadata field that will handle module registration and enqueue automatically analogous to viewScript. A full dev note about viewScriptModule can be read here.

Module registration

Developers familiar with modern JavaScript development will recognize the module system and may wonder, “Do I have to register all my modules with WordPress in order to use them?” The short answer is no, but the recommended approach is to register all the modules.

JavaScript modules can import be imported by URLs. It’s common to see imports like import { utility } from './utilities.js' in modern applications. Because the Script Modules API is built on top of native JavaScript modules, it’s possible for modules to import relative paths in WordPress. However, the recommended approach is to register modules and use the registered ID to import the module. This has a few benefits:

  • Registered modules are available globally. There’s no need to worry about the module URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org.
  • Registered modules have versions. The Script Modules API transparently handles associating a module ID with the correct URL and version.
  • Risk of module duplication is reduced. If a module is imported through different URLs, the browser may fetch and execute multiple copies of what is ostensibly the same module.
  • Dependencies that are imported statically will be preloaded when the module is enqueued. This allows the browser to fetch them in parallel.

Relative imports to unregistered modules may be useful for prototyping and exploration, but the best practice for production code is to register modules with the Script Modules API.

Limitations

Modules and scripts are not compatible at this time. Modules cannot depend on scripts and scripts cannot depend on modules. This means that modules cannot depend on scripts like wp-i18n, wp-api-fetch, etc.

There is a workaround to use scripts from modules. Script functionality is shared by adding variables to the window scope, for example wp-api-fetch can be accessed via window.wp.apiFetch. To use scripts from modules at this time, developers must:

  • Ensure that the script is enqueued: wp_enqueue_script( ‘wp-api-fetch’ )
  • Access the script through the global scope: const { apiFetch } = window.wp

There are a number of downsides to this workaround, but it can be an effective solution. Follow Core Trac ticket #60647 for work on script and module interoperability.

Compatibility

JavaScript modules have excellent support in most browsers today. In addition, the Script Modules API includes a polyfill for browsers with lacking or incomplete support to make the number of supported browsers even greater.

Technical details

A full explanation of how the Script Modules API works is beyond the scope of this note, but this section will provide a brief overview.

The Script Modules API will track registered and enqueued modules. For each enqueued module, a <script type="module"> 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.) will be added to load and execute the module.

A <script type="importmap"> tag will be added. The import map tells the browser how to map module IDs to URLs so that when it sees an import for '@wordpress/interactivity', it knows that the module should be fetched from the URL /wp-includes/js/dist/interactivity.min.js?ver=xyz. The import map includes all the dependencies of all enqueued modules, and all the dependencies of those dependencies, etc. The import map will not include dependencies of all the registered modules, only those that may be required on the page as dependencies, and it will not include the enqueued modules unless they are in the dependency graph of other enqueued modules.

A <link rel="modulepreload"> will be added for all static dependencies. Static dependencies are all dependencies that are not defined as array( 'id' => '…', 'import' => 'dynamic' ). This is an optimization hint for browsers, read more about it here.

Relevant links

Props

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

Agenda, Dev Chat, Wednesday May 22, 2024

The next WordPress Developers Chat will take place on  Wednesday May 22, 2024 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, as below. If you have ticketticket Created for both bug reports and feature development on the bug tracker. requests for help, please do continue to post details in the comments section at the end of this agenda.

Announcements

The scheduled date for WordPress 6.6 Beta 1 is June 4, which is less than 2 weeks away. From this point on, core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. will focus on testing and fixing bugs discovered during 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. testing. Begin writing 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. and the About page (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/. archive, ZIP download).

@ellatrix recently announced that the last 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 to go into WP 6.6 will have an 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). next Friday, May 31.

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. See the Roadmap Post for details about what is planned for this release.

Next maintenance release: 6.5.4

@jorbin requested that we discuss the potential of doing a 6.5.4 release to accommodate #61269.

Next Gutenberg release: 18.4

Gutenberg 18.4 is scheduled for release on May 22 and includes these issues.

Discussions

With the Beta 1 deadline quickly approaching, we’ll use the discussion time to check in on priority items for this release. Review the list of Editor Updates section of this agenda for a list of updates of several key features related to this release.

Highlighted posts

Editor updates

Props to @mikachan for putting together a list of editor related updates.

Get involved

Updates

Tickets for assistance

Tickets for 6.6 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 if there are any questions or you will be async.

@vcanales mentioned the following issues in the WordPress 6.6 Editor Tasks board that are up for grabs for developers:

@dmsnell requested that we highlight the following issues:

  • #61009 allows storing the proposed “Bits” syntax, making it possible for experimentation inside Gutenberg.
  • #61052 allows storing custom data attributes containing dashes, which is what 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. relies on.

Open floor

Items for this can be shared in the comments.

Props to @jeffpaul for reviewing.

#agenda, #core, #dev-chat

WordPress 6.6 Planning Proposal & Call for Volunteers

  • Please leave your feedback about the schedule and release squad size in the comments by April 7th.
  • If you are interested in participating in WordPress 6.6’s release squad as a lead or as a cohort, please show interest in the comments below, specifying the role and the type of involvement (lead/cohort).

With WordPress 6.5 almost ready, it’s time to start planning WordPress 6.6 so that the release leads can participate from the start of the release cycle.

The timeline for the second release of 2024 takes into consideration WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe in June, WordCamp US in mid-September, and the observed lower number of contributors available during the northern hemisphere summer. To avoid having major milestones (Beta1, RC1) conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. with flagship events, this proposal suggests having WordPress 6.6 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 before WCEU 2024, as the opposite would result in an even shorter release cycle for WordPress 6.7.

According to the schedule proposed below and the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ release cadence, WordPress 6.6 would include up to Gutenberg 18.5 for a total of 8 Gutenberg releases.

Proposed WordPress 6.6 Schedule

MilestoneDate
Alpha (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. open for 6.6 release)March 5, 2024
Beta 1June 4, 2024
Beta 2June 11, 2024
Beta 3June 18, 2024
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). 1June 25, 2024
Release Candidate 2July 2, 2024
Release Candidate 3July 9, 2024
Dry RunJuly 15, 2024
WordPress 6.6 General ReleaseJuly 16, 2024

Please leave your feedback about the schedule in the comments by April 7th.

Release Leads call for volunteers

Having more than one lead per role has proven helpful in sharing responsibilities, especially in the case of unexpected events, and fostering leadership by pairing experienced leads with first-timers. However, recent feedback has also pointed in the opposite direction, with the squad having too many voices when combining role duplicity with the increased number of different roles. These larger squads have also fostered a bystander effect, creating the sometimes false feeling that somebody else must be working on things, resulting in unclear direction.

Since this release cycle is shorter than the last ones, I propose scaling back the release squad size again, trying to find a middle ground. Reducing role duplicity is less risky at this point as, in the event of unexpected release leadRelease Lead The community member ultimately responsible for the Release. availability, plenty of now-experienced contributors are ready to step up and lend a hand in case of necessity.

This squad reduction also includes experimenting with unifying the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and Editor Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. roles so that the Triage Leads have a wider picture of issues across the technical side and can act as a nexus between Core and Editor Tech Leads.

With this smaller release squad, release leads should have proven experience and good availability during the release cycle. Less experienced folks and newcomers are still welcome to join as a cohort.

Some folks have already volunteered in the previous call for volunteers; some roles are already filled, whereas availability has changed for some people and there are still open spots. The TBDs found in the list below indicate the number of desired vacancies to fill.

  • Release Lead: Matt Mullenweg
  • Release Coordinator:
  • Core Tech Leads: TBD, TBD
  • Editor Tech Leads: Ella van Durpe, TBD
  • Triage Leads: Fabian Kägy, Damon Cook *
  • Documentation Leads: TBD, TBD
  • Marketing & Communications Lead: TBD
  • Test Lead: TBD
  • Design Lead: TBD
  • Performance Lead: TBD
  • Default Themes Lead: TBD

* Both Triage Leads had volunteered for either Core or Editor Triage roles.

All release decisions will ultimately be this release team’s to make and communicate while gathering input from the community.

As a reminder, if you are interested in participating in WordPress 6.6’s release squad as a lead or as a cohort, please show interest in the comments below, specifying the desired role and level of involvement (lead/cohort).


Thanks to @jeffpaul and @desrosj for the peer review and feedback

#6-6 #planning

Roadmap to 6.6

WordPress 6.6 is set to be released on July 16, 2024. With a slightly shorter cycle, this release heavily builds on the foundation of the last with some new items, like section styles and overrides in synced patterns, and loads of enhancements to features that landed in the last few releases, including the Font Library and 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.. Data Views, the first taste of the admin redesign work introduced in 6.5, continues to evolve with new layout options, a combined template part and pattern experience, and more readily accessible management sections. Finally, design tools take center stage with everything from grid layout support to section styles to more power baked into style variations out of the box. 

As always, what’s shared here is being actively pursued, but doesn’t necessarily mean each will make it into the final release of WordPress 6.6.

For a more detailed look at the work related 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. editor, please refer to the 6.6 board and review the currently open Iteration issues. After a recent organization effort, Iteration issues are meant to reflect active work that’s been scoped down for a major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.. To get a sense of some of what’s being worked on both for this release and beyond, check out the demos shared in a recent hallway hangout.

Foundational experience

Advancing the new Data Views in the Site Editor

Building on an initial launch in 6.5, the new views in the Site Editor continue to be refined and advanced. This includes work to bring the various management pages forward (manage all templates, manage all template parts, manage all pages) so those options are immediately seen when visiting the respective sections, reducing the number of steps to access important information. For pages, a new side by side layout will be introduced so one can see both a list of all pages and a preview of the currently selected page. For patterns, template part management will be removed and integrated into the current overall patterns section. Interspersed within all of these larger changes are smaller enhancements in functionality and feel. 

Manage template screen showcasing the side by side layout with navigation on the far left, a list of templates in the middle, and a larger preview window on the right showing the current template.

Follow this tracking issue for more information. 

Zoom out to compose with patterns

A few different initiatives are coming together to allow one to focus on building with patterns rather than granular block editing, including advancing contentOnly editing and zoomed out view. Key features planned include:

  • A zoomed out experience in the editor when inserting patterns to facilitate high level overview of the site.
  • Ability to shuffle top level patterns within a template in order to quickly explore alternative patterns.
  • Ability to manipulate patterns in the template via moving, deleting, etc while zoomed out. 
  • Improvements to UXUX User experience for dragging patterns (e.g. vertical displacement).

Taken together, this work aims to offer a first step towards a new way to interact with and build with patterns. Some questions remain including whether zooming out will be invoked in certain situations, like the patterns tab of the Inserter, or if it’s something that could be toggle on/off as one wants. 

Pattern inserter open to Banner patterns with the content of the site zoomed out, showing more of the template that the pattern is going to be added to.

Follow this iteration issue for more information. 

View inherited style values

Knowing where a block’s style comes from is key to knowing where a change might need to be made. For 6.6, work is underway to show locally the value that a block inherits globally, when applicable. This means that, for example, if you set a paragraph to always have blue text in Styles, every paragraph you added will show blue text and the block settings will show the blue color as the chosen text color. This is in contrast to today’s confusing experience, where it shows a circle with a line through it, to indicate that no local color has been set despite the block inheriting it globally. 

Follow this issue for more information. 

Unifying editor experiences, including publish flow

This is both a technical and design effort, consolidating shared code and creating a single, coherent flow across the post and site editors for common tasks. The more noticeable and big pieces will be seen in a unified publish flow and a new singular “summary” inspector panel, which will also be reused within the site editor when you are bulk editing. 

Follow this iteration issue for aligning features and this tracking issue for the inspector controls for more information. 

Design tools

Mix and match typography and color palettes from all styles variations 

Style variations allow you to change the look and feel of your site, all while using the same theme. To build on the design possibilities of a block theme with style variations, 6.6 aims to add the ability to mix and match the color and typography styles of each individual style variations. This means the eight community created style variations baked into the Twenty Twenty-Four theme turns into 48 styling combinations, thanks to the six typography presets and eight color presets available. Add in more typography options thanks to the Font Library and the optionality available is immense, alongside all of the granular tinkering you want to do. This evolution in style variation possibilities will work out of the box with all block themes with style variations with no additional opting in or adjustments on the theme author’s end. 

Follow this iteration issue for more information. 

Syncing specific blocks and attributes of patterns

Building upon synced patterns, overrides in synced patterns would allow users to ensure a synced layout and style across patterns while allowing each instance of the pattern to have customized content. This allows for consistency in design across different pieces of content. For instance, consider a testimonial pattern in a grid. With the enhanced feature, someone can insert this testimonial pattern into multiple posts, ensuring that the layout and styling components, such as the overall design of the recipe card, remain consistent across instances. Meanwhile, the content, such as Name, Image, and Role, would be local to each instance allowing for individual customization. Additionally, folks would then be able to revisit and modify the design of the overall testimonial pattern without affecting the content in existing instances. To get a sense of the current work happening here, check out the “overrides in synced patterns” demo from a recent hallway hangout below:

Follow this iteration issue for more information 

Expanding block style variations for more styling options 

Through work to extend the block style variations mechanism, 6.6 is set to introduce the ability for theme authors to define style options for sections of multiple blocks, including inner blocks. With just a few clicks, folks using block themes that add this functionality could quickly change just a section of a page or template to predefined styles that an author provided, like a light or dark version of a section. This feature is coming together thanks to work to expand the block style variations API. There are a few ways folks are aiming to offer this functionality:

  • Programmatically via gutenberg_register_block_style
  • By standalone 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 within a theme’s /block-styles subdirectory
  • Via theme style variations defining block style variations under styles.blocks.variations.

To see a very early look at this work, check out the “Section Styles” demo from a recent hallway hangout.

Follow this iteration issue for more information. 

Improvements to Grid Layout

Grid is a new layout variation for the Group block that allows you to display the blocks within the group as a grid, offering new flexibility. There are two options for the Grid layout:

  • “Auto” generates the grid rows and columns automatically using a minimum width for each item. 
  • “Manual” allows specifying the exact number of columns.

Outside of expanding functionality, including trying to implement drag and drop resizing, work is also underway to improve using layout tooling in general to make it simpler and clearer to accomplish what you want.

Follow this tracking issue for more information and/or join the dedicated #feature-grid 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. 

Refining the Font Library 

To build on its debut in 6.5, the Font Library will continue to see 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 enhancements based on incoming feedback. This work will be less about adding new functionality and more about refining what’s landed. 

Follow this iteration issue for more information. 

Additional supports

A selection of smaller efforts come together to provide more design options directly in the editor:

Adoption pathways

Bringing the Site Editor experience for Pattern management to Classic Themes

Thanks to some internal code changes, the path is set to enable Classic Themes to have access to the new Patterns experience that the Site Editor provides. This will provide an upgraded, modern experience of managing and creating patterns.

Follow this iteration issue for more information. 

Continued performance improvements

This release cycle, a variety of initiatives are focused on improved loading times, especially template loading with improved caching of theme.json, block templates and computed styles as well as optimizing autoload options. Research and initial work to address potential improvements to the INP (Interaction to next pain) metric is also continuing in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and the Interactivity API. In addition, ongoing performance improvements for the editor for this release are being tracked in this iteration issue, including major improvements to template loading.

Outside of the above efforts, work continues to improve performance tooling, including our automated performance test actions running in both GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ and core. The current effort is focused on making the performance tests more consistent, robust and reliable and on providing an easy-to-use GitHub action developers can leverage to implement the performance tests in their own 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.

API iterations

Various APIs recently introduced in the last few releases are all slated for continued upgrades.

Interactivity API

The Interactivity API provides a standard way to allow developers to add interactivity to the frontend of their blocks. After the release of the initial version of the Interactivity API in 6.5, this next round of work is focused solely on enhancing the developer experience with better test coverage and code quality, improved error reporting, debugging tools, and fixing reported bugs.

Follow this iteration issue for more information and/or join the dedicated #core-interactivity-api slack channel. 

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

Introduced in WordPress 6.4 and iterated upon in 6.5, the Block Hooks API is an extensibility mechanism that allows you to dynamically insert blocks into block themes. At this stage of maturity, work is underway to help determine a proper UIUI User interface for hooked blocks and continued improvements to the developer experience. 

Follow this tracking issue for more information. 

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

Building on the initial launch in 6.2, work continues to evolve the HTML API with a focus on two aims for 6.6:

  • Complete and rely on a custom and spec-compliant encoder/decoder. 
  • Design how to communicate when an HTML document has retroactively changed, allow calling code to match on, stop at, and modify implicitly-created elements, including when elements are closed.

Follow this iteration issue for more information. 

Custom Fields & Block Bindings API

The Block Bindings API launched in 6.5 allows you to bind dynamic data to block attributes, solving many use cases for custom blocks and powering other features, like overrides in synced patterns. This next round of work is focused on allowing the editing of connected sources directly from the block. As showcased in a recent Hallway Hangout, users can update the value of 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. by editing the paragraph connected to it. As part of that, the existing editor implementation is being refactored, and the editor APIs are being defined with the goal of “potentially” making them public for 6.6. Outside of the broader technical work, initial explorations are underway around a UI to create bindings, but it’s unlikely to land for 6.6.

Follow this iteration issue for more information.  

Dropping support for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 7.0 and 7.1 

Support for PHP 7.0 and 7.1 will be dropped in WordPress 6.6, scheduled for release in July 2024. The new minimum supported version of PHP will be 7.2.24. The recommended version of PHP remains at 7.4 or greater. Read more in the Dropping Support for PHP 7.1 Make Core post

Add rollbacks to auto-updates

Since WordPress 6.3, when an administrator is manually updating plugins, the plugin will not be reactivated if the update causes a PHP fatal error. During an auto-update, this reactivation check does not occur and the next time the site runs users will see the white screen of death (WSOD). To further protect websites and increase confidence in automatic plugin updates, 6.6 aims to include the ability to perform rollbacks when fatal errors occur during attempted plugin auto-updates by default. To learn more, please review the merge proposal for this feature

Find something missing? Want to help?

If you have something you’re working on that you don’t see reflected in this post, please share a comment below so we can all be aware! If you’re reading this and want to help, a great place to start is by looking through each issue associated with each area or by diving into the Polish board where a curated set of issues are in place that anyone can jump in on.

Thank you to @adamsilverstein @joemcgill @fabiankaegy @get_dave @ellatrix for reviewing and contributing to this post!

#6-6, #release-roadmap

Introducing Plugin Dependencies in WordPress 6.5

Overview

#22316 introduces 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 to WordPress.

Extensibility of WordPress through plugins and the 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. APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. is one of its most beneficial features. There are many plugins that act purely as extensions of others, building functionality on top. The Plugin Dependencies feature aims to make the process of installing and activating addons (dependents) and the plugins they rely on (dependencies) consistent and easy.

New Plugin HeaderHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.

A new Requires Plugins header has been introduced.

This must contain a comma-separated list of 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/-formatted slugs for its dependencies, such as my-plugin (my-plugin/my-plugin.php is not supported). It does not support commas in plugin slugs.

How to use the new header

/**
* Plugin Name: Express Payment Gateway Checkout for Shop
* Requires Plugins: shop, payment-gateway
 */

Requirements

Dependent plugins

The following requirements are placed on dependent plugins:

  • Cannot be installed until its dependencies are installed.
  • Cannot be activated until its dependencies are activated.

Dependency plugins

The following requirements are placed on dependency plugins:

  • Cannot be deactivated while its dependents are activated.
  • Cannot be deleted while its dependents are installed.

What happens if a dependency is no longer met?

If a dependency plugin is deleted via FTPFTP FTP is an acronym for File Transfer Protocol which is a way of moving computer files from one computer to another via the Internet. You can use software, known as a FTP client, to upload files to a server for a WordPress website. https://codex.wordpress.org/FTP_Clients. or deployment, a notice will be displayed on the administration’s plugin screens, informing the user that there are missing dependencies to install and/or activate. Additionally, each dependent whose dependencies are no longer met will have an error notice in their plugin row.

What happens if a plugin update has a new dependency?

The update will be allowed for now, and the dependent will remain active. A notice will be displayed on the administration’s plugin screens, informing the user that there are missing dependencies to install and/or activate.

What happens if there are circular dependencies?

A circular dependency is when two or more plugins form a loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. in their requirements.

For example: Plugin A requires Plugin B requires Plugin C requires Plugin A

Plugin Dependencies includes circular dependency detection, and will display a notice to inform users of plugins whose requirements are 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.. The plugins cannot be activated, and users should contact the plugin authors so that this circular reference can be broken where appropriate.

Is defensive coding still needed?

Yes. Plugin Dependencies makes it easier for the user to install and activate required plugins, and informs them when these are not met. This means plugin authors can safely remove checks and notices when their dependencies are not installed or activated.

However, at this time, Plugin Dependencies does not include minimum or maximum version support for dependencies, nor does it account for the loading order of plugins. Plugin authors should therefore continue to use function|class|interface_exists() and version checks where their plugin relies on specific functionality being available at a given time.

Does Plugin Dependencies affect WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/?

Plugin Dependencies does not prevent the installation of dependent plugins without their dependencies via WP-CLI, as it is assumed that those using WP-CLI are advanced users that are aware of their dependency stack. However, to avoid missing dependencies going unnoticed, dependent plugins cannot be activated using WP-CLI until their dependencies are activated.

This affects wp plugin activate --all, which may need to be run multiple times if a dependent appears alphabetically earlier than its dependencies. We plan to collaborate with WP-CLI maintainers on possible ways of easing this burden by exploring loading order in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., WP-CLI, or both, if appropriate.

Limitations

Plugins hosted on WordPress.org

Dependent plugins hosted on WordPress.org can only declare dependencies that are also hosted on WordPress.org. If your plugin hosted on WordPress.org requires plugins that are not hosted there, it is recommended that you do not use the Requires Plugins header in your plugin at this time.

Plugins not hosted on WordPress.org

Dependent plugins not hosted on WordPress.org can declare dependencies whether hosted on WordPress.org or elsewhere. However, the UIUI User interface will not provide an installation link for the third-party dependencies, and these must continue to be installed manually by the user.

Must-Use plugins as dependencies

Must-Use plugins as dependencies are not officially supported by WordPress Core at this time. Discussion will continue in #60504 and we will release further information when decisions about possible future support have been made.

Themes that require plugins

Themes that require plugins are not supported by Plugin Dependencies at this time, and theme authors should continue to use the checks and messaging that they have in place.

New FilterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.

The wp_plugin_dependencies_slug filter hook has been introduced to allow for alterations to dependency slugs. For example, if a dependent plugin declares my-plugin as a dependency, and a premium version of my-plugin exists, the premium version can filter the slug and convert it to my-plugin-pro so that it can be detected by Plugin Dependencies.

  • Parameters
    string $slug – The slug.

Example usage

add_filter( 'wp_plugin_dependencies_slug', 'convert_myplugin_to_myplugin_pro' );

function convert_myplugin_to_myplugin_pro( $slug ) {
if ( 'my-plugin' === $slug ) {
$slug = 'my-plugin-pro';
}
return $slug;
}

UI Changes

Plugins > Installed plugins

The following changes are made:

  • Dependent plugin rows now contain a list of their dependencies, linked to the respective plugin modal to install and activate the dependency.
  • Dependency plugin rows now contain a list of their dependents.
  • If a plugin has dependencies that are not installed and active, the Activate link is disabled.
  • If a plugin has dependents that are active, the Deactivate and Delete links are disabled.
  • Bulk Actions are disabled for dependency plugins.

Before

Three plugin rows, with one plugin requiring the other two. However, there is no indication or enforcement of the requirements.
No dependents or dependencies are listed.

After

Three plugin rows, with one plugin requiring the other two. The requirements are listed under "Requires" and "Required by" sections. The Bulk Actions checkbox is disabled, as well as the Activate, Deactivate, or Delete actions, depending on the status of the plugins.
Dependents and dependencies are listed, and actions are enabled/disabled based on the status of requirements.

Plugins > Add New

The following changes are made:

  • If a plugin has unmet dependencies, the Install Now and Activate buttons are disabled, both in their plugin card and their plugin information modal.
  • Dependent plugin cards now contain a notice listing their dependencies, with a More Details link to the dependency’s information modal which contains Install Now or Activate buttons based on their current installation status.
  • Plugin information modals are now persistent after button clicks, and modal-based plugin installation and activation are now performed through AJAX directly within the modal.

Before

Plugin card with no dependencies listed and an active Install Now button despite unmet dependencies.

After

Plugin card with dependencies listed with modal links to install and activate each dependency, and the Install Now button disabled while dependencies are unmet.

Onboarding experiences

Due to the unified AJAX approach now used on the Plugins > Add New screen, activation of a plugin will no longer automatically redirect to the Plugins > Installed plugins screen, or to onboarding experiences implemented by plugin authors. This allows users to install and activate multiple plugins without leaving their current context.

Plugins with onboarding experiences usually incorporate checks so that if, for example, their plugin is installed and activated using WP-CLI, the onboarding experience will be triggered when the user enters one of the plugin’s settings screens. Such implementations will be unaffected by Plugin Dependencies, as will activation from the Plugins > Installed plugins screen Activate link.

New WP_Plugin_Dependencies Class

A new WP_Plugin_Dependencies class has been introduced.

The following public API methods are available:

static ::initialize()
Initializes Plugin Dependencies by reading dependencies from the Requires Plugins header, and fetching Plugins API data for dependencies. This runs only once per execution.

static ::has_dependents( $plugin_file )
Determines whether the plugin has plugins that depend on it.

  • Parameters
    string $plugin_file – The plugin file, relative to the plugins directory.
  • Return value
    bool Whether the plugin has plugins that depend on it.

static ::has_dependencies( $plugin_file )
Determines whether the plugin has plugin dependencies.

  • Parameters
    string $plugin_file – The plugin file, relative to the plugins directory.
  • Return value
    bool Whether the plugin has plugin dependencies.

static ::has_active_dependents( $plugin_file )
Determines whether the plugin has active dependents.

  • Parameters
    string $plugin_file – The plugin file, relative to the plugins directory.
  • Return value
    bool Whether the plugin has active dependents.

static ::get_dependents( $slug )
Gets filepaths of plugins that require the dependency.

  • Parameters
    string $slug – The dependency’s slug.
  • Return value
    array An array of dependent plugin filepaths, relative to the plugins directory.

static ::get_dependencies( $plugin_file )
Gets the slugs of plugins that the dependent requires.

  • Parameters
    string $plugin_file – The dependent plugin’s filepath, relative to the plugins directory.
  • Return value
    array An array of dependency plugin slugs.

static ::get_dependent_filepath( $slug )
Gets a dependent plugin’s filepath.

  • Parameters
    string $slug – The dependent plugin’s slug.
  • Return value
    string|false The dependent plugin’s filepath, relative to the plugins directory, or false if the plugin has no dependencies.

static ::get_dependency_filepath( $slug )
Gets the filepath for a dependency, relative to the plugin’s directory.

  • Parameters
    string $slug – The dependency’s slug.
  • Return value
    string|false If installed, the dependency’s filepath relative to the plugins directory, otherwise false.

static ::has_unmet_dependencies( $plugin_file )
Determines whether the plugin has unmet dependencies.

  • Parameters
    string $plugin_file – The plugin’s filepath, relative to the plugins directory.
  • Return value
    bool Whether the plugin has unmet dependencies.

static ::has_circular_dependency( $plugin_file )
Determines whether the plugin has a circular dependency.

  • Parameters
    string $plugin_file – The plugin’s filepath, relative to the plugins directory.
  • Return value
    bool Whether the plugin has a circular dependency.

static ::get_dependent_names( $plugin_file )
Gets the names of plugins that require the plugin.

  • Parameters
    string $plugin_file – The plugin’s filepath, relative to the plugins directory.
  • Return value
    array An array of dependent names.

static ::get_dependency_names( $plugin_file )
Gets the names of plugins required by the plugin.

  • Parameters
    string $plugin_file – The dependent plugin’s filepath, relative to the plugins directory.
  • Return value
    array An array of dependency names.

static ::get_dependency_data( $slug )
Returns API data for the dependency.

  • Parameters
    string $slug – The dependency’s slug.
  • Return value
    array|false The dependency’s API data on success, otherwise false.

FAQs

Where can I stay updated on the future development of Plugin Dependencies?

The Plugin Dependencies feature plugin will no longer receive updates now that the Plugin Dependencies feature has been merged into WordPress Core. The feature will be primarily maintained by contributors to the Upgrade/Install and Plugins components. You can stay updated on Plugin Dependencies and other developments by subscribing to the blog.

How can I get involved in the future development of Plugin Dependencies?

You can join us in the #core-upgrade-install channel on Slack. Our weekly meetings are held every Wednesday at 18:00 UTC. Tickets will be opened on WordPress Core Trac.

How can I report an issue?

You can search for an existing ticket or create a new ticket with the type of defect (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.) on WordPress Core TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

How can I request an enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.?

You can search for an existing ticket or create a new ticket with the type of enhancement on WordPress Core Trac.

Props to @afragen and @swissspidy for technical review, and @stevenlinx for copy review.

In memory of Alex Mills and Alex King.
WordPress Remembers.

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

Performance Chat Summary: 7 May 2024

Meeting agenda here and the full chat log is available beginning here on Slack.

Announcements

  • Welcome to our new members of #core-performance
  • Performance lab 3.1.0 release scheduled for May 20

Priority Items

Structure:

  • WordPress performance TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
    • Current release (WP 6.6)
  • 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 (and other performance plugins)
  • Active priority projects
    • Improve template loading
    • INP research opportunities
    • Improving the calculation of image size attributes
    • Optimized autoloaded options

WordPress Performance Trac Tickets

  • For WordPress 6.6:
    • @adamsilverstein only 14 tickets milestoned for 6.6 in the performance focus,  the 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. scrubs have been effective at keeping tickets moving
    • @spacedmonkey I would consider adding my ticketticket Created for both bug reports and feature development on the bug tracker. for loading multiple networknetwork (versus site, blog) options at once. I am hoping to get #61053 into this release.
      • @pbearne That would a good add, and we can it to 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.
    • @westonruter Happy to share that post embeds will now get lazy-loaded in 6.6 where previously they were excluded. This was committed yesterday https://core.trac.wordpress.org/changeset/58143

Performance Lab Plugin (and other Performance Plugins)

  • Performance lab plugin and the following performance plugins:
    • Auto-sizes for Lazy-loaded Images
    • Embed Optimizer
    • Fetchpriority
    • Image Placeholders
    • Modern Image Formats
    • Optimization Detective (Developer Preview)
    • Performant Translations
    • Speculative Loading

  • Modern images: @adamsilverstein for modern images work has continued on adding AVIF support, that is very close to ready – https://github.com/WordPress/performance/pull/1176
  • @ashwinparthasarathi Worked on a couple of features and PRs are underway,
  • @benoitfouc AVIF is now mainly supported, i’m agree with this proposition
    • @adamsilverstein supported in all browsers, however only ~30% of WordPress sites have the server support they need to upload AVIFs (and generate srcset images)
    • @benoitfouc is there a way to control this support on the plugin? Using WebP by default when the server do not support AVIF
    • @westonruter Yes, that’s how it works. And there is a user option to decide which format when AVIF is available
  • @adamsilverstein that would be my preference. then, what happens if users are already outputting WebP, does that change automatically to AVIF when they upgrade the plugin, or do they need to go in and change the output setting?
    • One thing we are trying to decide on that PR is haw to handle the default settings – especially for users who upgrade from the current version
  • @westonruter Would anyone be explicitly wanting WebP instead of AVIF, I guess the question is. Adam suggested doing a major version bump from 1.x to 2 as a signal for this significant change. Might be sufficient as a way to alert users that their attention may be needed. Otherwise, I guess an adminadmin (and super admin) pointer could be added, but that seems noisy. Maybe add an Upgrade Notice in the readme as well?
    • Agreement reached:
    • Going back up to @ashwinparthasarathi PR https://github.com/WordPress/performance/pull/1208 to improve visibility of the features’ Settings screens, take a look at the last comment on the PR. How about adding a link to the settings in the activation notice? “Feature activated. Review settings.”
    • Where settings is a link to the relevant settings screen. A settings link also appears with each feature once activated, but the thinking is that the user may not notice this appear all of a sudden
  • @ashwinparthasarathi yes, it makes sense, and I will make the changes to include it in the Activation notice. I also thought that your earlier idea to make those settings links more visible is a good one. I think if we could make it stand out, it’ll work.
  • @westonruter for Speculative Loading: Whether we should go ahead and prevent speculative loading for logged-in users (and when PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher sessions are being used): https://github.com/WordPress/performance/pull/1178
    • After thinking about it some more, I wonder if it may be premature to add this as we haven’t had any reports in the wild of this being a problem. The one user who reported it did so as part of an overall set of suggestions.
    • Perhaps we sit on this awhile longer to bake
    • There could also be a new setting we could add for turning off speculative loading for logged-in users. But ideally we’d be able to make a decision and not add to the user’s set of tasks. Although there are currently pretty low-level settings for prefetch vs prerender already, so maybe this isn’t a big deal for a feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. as we figure out what makes sense for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
    • Oh, I stand corrected, one user did report wanting to be able to disable speculative loading this in the support forumSupport Forum WordPress Support Forums is a place to go for help and conversations around using WordPress. Also the place to go to report issues that are caused by errors with the WordPress code and implementations.https://wordpress.org/support/topic/sl-lsc/#post-17699897

Active Priority Projects

Improve template loading

  • @thekt12 Last week I worked on feedback from #59595 and also worked on it’s unittest, just a few more checks and I should be able to give it for review today. I’ll resume back #57789

INP research opportunities

Improving the calculation of image size attributes

Optimized autoloaded options

  • No updates this week

Open Floor

  • @benoitfouc i want to know if somebody are interesting about working on this PR : https://github.com/WordPress/performance/issues/371 This PR make sens, and is on the same way that the new version of Modern Images Formats plugin
  • @clarkeemily I think last week one suggestion was made to have a bug scrub specifically for the Performance Lab plugin – wondered if folks were in favor of this in principle, then we can perhaps work to define the scheduling etc later

Our next chat will be held on Tuesday, May 21, 2024 at 15:00 UTC in the #core-performance channel in Slack.

#core-performance, #performance, #performance-chat, #summary