Merge Announcement: Interactivity API

View the kickoff post, the status update post, and the Trac ticket for 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..

Purpose & Goals

Currently, 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 implement their chosen 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/. frameworks (or vanilla JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors.) to enhance user experiences on WordPress sites. There is no consistency or standardized pattern for developing frontend JavaScript in WordPress.

The Interactivity API provides a standard way for developers to add interactions into the frontend of their blocks.

The API has been designed and created with these requirements:

  • 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.-first and PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher-first. Prioritizing blocks for building sites and server side rendering for better SEO and performance. Combining the best for user and developer experience.
  • Backward compatible. Ensuring compatibility with both classic and block themes and optionally with other JavaScript frameworks, though it’s advised to use the API as the primary method. It also works with hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. and internationalization.
  • Declarative and reactive. Utilizing declarative code to define interactions, listening for changes in data, and updating only relevant parts of the DOM accordingly.
  • Performant: Optimizing runtime performance to deliver a fast and lightweight user experience.
  • Send less JavaScript. Reduce the overall amount of JS being sent on the page by providing a common framework that blocks can reuse.  So the more that blocks leverage the Interactivity API, the less JS will be sent overall.

A live demo of what can be achieved was announced in the State of the WordState of the Word This is the annual report given by Matt Mullenweg, founder of WordPress at WordCamp US. It looks at what we’ve done, what we’re doing, and the future of WordPress. https://wordpress.tv/tag/state-of-the-word/..

Live site demo

In case you want to read more about the goals, you can refer to the initial proposal.

Project Background

The project started as an experimental plugin in early 2022. Then, the first API version debuted in Gutenberg 16.2 and has been continually refined until Gutenberg 17.7.

In WordPress 6.4,the Image, Search, File, Navigation, and Query coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks were refactored using the private version of the Interactivity API, addressing 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) issues and adding the long-time expected lightbox (or “expand on click”) feature for images.

The development has been done in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, using a Tracking Issue to monitor progress and a Discussions category to solicit feedback and offer guidance to developers who assisted in testing.

Implementation Details

The Interactivity API is a standard system of directives, based on declarative code, for adding frontend interactivity to blocks.

Directives are special HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. attributes that tell the Interactivity API to attach a specified interaction to a DOM element or to transform it, similar to HTMX or AlpineJS. Using HTML as the templating language enables the API to understand the directives both in the server (PHP) and in the client (JS).

As part of this project, and all the interactivity scripts are now implemented leveraging the new script modules which are also shipping in WordPress 6.5. All of them will only be loaded on the frontend if at least one interactive block is present, to avoid sending unnecessary JavaScript to the frontend.

Here is an example of an interactive block, with a JavaScript file in charge of increasing or decreasing a counter, and a PHP file in charge of counter initialization and rendering.

// JS File - viewScriptModule.js

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

const { state } = store("my-counter-block", {
 actions: {
   increaseCounter: () => {
     state.counter = state.counter + 1;
   },
   decreaseCounter: () => {
     state.counter = state.counter - 1;
   },
 },
});
// PHP File - render.php
wp_interactivity_state('my-counter-block', array(
   'counter' => 0,
))
?>

<div
   <?php echo get_block_wrapper_attributes(); ?>
   data-wp-interactive="create-block"
>
   <button data-wp-on--click="actions.increaseCounter">
       <?php esc_html_e( 'Increase', 'my-first-interactive-block' ); ?>
   </button>
   <p data-wp-text="state.counter"></p>
   <button data-wp-on--click="actions.decreaseCounter">
       <?php esc_html_e( 'Decrease', 'my-first-interactive-block' ); ?>
   </button>
</div>

This would result in a block like this one:

For developers looking to get started, there is a Getting Started guide available, with plans to transition it to a handbook in the near future.

Additionally, a detailed 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. will be released, providing further insights into utilizing the API and understanding its internal workings.

Modules and Import maps.

The Interactivity API brings along the support of Modules and Import Maps.

JavaScript modules have transformed the way developers write and organize JavaScript code. They provide a cleaner and more modular architecture, making code easier to maintain, test and reuse across projects.

With the addition of native support for registering and enqueueing JavaScript modules, WordPress can keep pace with web development by using efficient, effective and battle-tested methods to handle JavaScript libraries and their dependencies.

There will be another dev note about JavaScript Modules and a guide to use them.

Guide to Javascript Modules.

Contributions and Feedback.

The Interactivity API is intended to be a long-term project with future enhancements; feedback is highly welcome. The best way to reach out is via GitHub Discussions.

Code and documentation contributions are also welcomed, and the Gutenberg repository is the place to go.

Some examples of contributing could be:

  • Test the Interactivity API, create your own interactions, and share feedback about what you like and you don’t.
  • Suggest new features to include in the API.
  • Help creating tutorials or share demos that can inspire other people.

Spread the word

The more developers who use Interactivity API in their projects, the more consistency there will be in the WordPress ecosystem, and the less JavaScript will be sent to the world!

Feel free to spread the word about the Interactivity API in social media and events with your colleagues, friends, and everyone!

Props to @cbringmann, @gziolo, @swissspidy, @westonruter, @santosguillamot, @luisherranz, and @rmartinezduque for peer review.

#6-5, #feature-plugins, #feature-projects, #interactivity-api, #merge-proposals

Merge Announcement: Plugin Dependencies

Note: This post was updated to add the “Third-party plugins not hosted on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/” section. 15th February, 2024 – @costdev

View the kickoff post, the Trac ticket and the feature plugin for PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Dependencies.

Purpose & Goals

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/activating addons (dependents) and the plugins they rely on (dependencies) consistent and easy to use.

Plugin authors are currently implementing their own ways of informing users about other plugins that they depend on. The implementations are inconsistent and sometimes incomplete. Users are often left to search for and install the other required plugins themselves.

The feature does not intend to replace the need for defensive coding within dependent plugins, or ensure version compatibility with their dependencies; nor does it seek to mitigate the vast array of potential plugin interactions. For WordPress and/or PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher incompatibilities, CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. already has handling for preventing installing, updating, or activating plugins with unmet requirements.

Implementation Details

A plugin’s dependencies can be declared by the use of a new Requires Plugins 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. in the dependent plugin’s main file. This must contain a comma-separated list of WordPress.org slugs for its dependencies, such as jetpack (jetpack/jetpack.php is not supported). It does not support commas in plugin slugs.

Example

/**
 * Plugin Name: Bridge for Foo and Bar
 * Requires Plugins: foo, bar
 */

Version management support, such as providing specific minimum and maximum version numbers through the Requires Plugins header value, is not currently supported.

Requirements

Declaring a plugin dependency places the following requirements:

  1. Bridge for Foo and Bar can only be installed once Foo and Bar have been installed.
  2. Bridge for Foo and Bar can only be activated once Foo and Bar have been activated.
  3. Foo and Bar can only be deactivated once Bridge for Foo and Bar has been deactivated.
  4. Foo and Bar can only be deleted once Bridge for Foo and Bar has been deleted.

Viewing, installing and activating dependencies

In the Plugins > Add New screen, dependencies are listed in the dependent’s plugin card. Next to these is a View Details link to open a dependency’s information modal. The dependency can be installed and activated using the buttons in the modal’s footer.

Previously, the modal would close upon clicking the Install Now or Activate button. The feature makes the modal persistent, and the buttons used in the plugin cards and modal now use the same underlying markup and functionality for consistency and reduced maintenance burden.

The side effect of this shared functionality is that automatic redirection upon activating a plugin from Plugins > Add New is no longer available. This has the benefit of not redirecting a user away from the Plugins > Add New screen for each plugin, removing them from their current context. Users can therefore install and activate multiple plugins without leaving their current context.

For plugins with onboarding experiences, they often have additional logic in case a plugin is installed and activated through a tool such as 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/, so that the user is still presented with the onboarding experience upon navigating to a screen deemed an appropriate starting place.

Automatic deactivation of dependent plugins

As currently implemented, plugins with unmet dependencies are automatically deactivated. While this was the approach suggested in initial discussions, there were valid concerns raised about this behavior after merging into trunk. These have been weighed and discussed, and a decision was made to remove this behavior.

Third-party plugins not hosted on WordPress.org

Defining plugins not hosted on WordPress.org as dependencies will enforce and display the dependencies to the user. However, there will be no ability to install the missing plugins through the UIUI User interface changes, and these will need to be installed manually.

UI changes

The feature makes changes to the UI on two screens: Plugins > Installed plugins, and Plugins > Add New.

Design Feedback

Design feedback was requested on the ticketticket Created for both bug reports and feature development on the bug tracker. and responses were received from @azaozz, @paaljoachim and @karmatosed on the ticket and on the Feature Plugin repository.

Plugins > Installed plugins

The following changes are made:

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

Before

Plugin rows without listing any dependents or dependencies.
No dependents or dependencies are listed.

After

Plugin rows for a dependent and its two dependencies. The plugin row for a dependency shows a list of plugins that depend on it, and a dependent's plugin row shows a list of plugins that it depends on. The dependent's plugin row links the names of each dependency to a modal with buttons to install and activate the dependency.
Dependents and dependencies are listed, and actions are enabled/disabled based on the status of requirements.

Plugins > Add New

The following changes are made:

  1. If a plugin has unmet dependencies, the Install Now and Activate buttons are disabled, both in their plugin card and their plugin information modal.
  2. Dependent plugin cards now contain a notice listing their dependencies, with a View Details link to the dependency’s information modal which contains Install Now or Activate buttons based on their current installation status.
  3. 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

A plugin card that does not list dependencies for the plugin, and allows installation even if the dependencies are not installed first.
Plugin card with no dependencies listed and an active Install Now button despite unmet dependencies.

After

A plugin card with a notice containing a list of dependencies and a link to open a modal with buttons to install and activate the dependency
Plugin card with dependencies listed with modal links to install and activate each dependency, and the “Install Now” button disabled while dependencies are unmet.

User Testing

The feature team released calls for testing in October 2022 and March 2023. Additional user testing was performed during design and technical feedback with reports on the ticket and in the #core-upgrade-install 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 up to the day of commit.

Outcomes

Based on responses to calls for testing, and design and technical feedback, the following UI changes were made:

  1. Adminadmin (and super admin) notices for each unmet dependency were reduced to a single notice informing the user that there were plugins with unmet dependencies.
  2. A dedicated Dependencies tab was removed from the Plugins > Add New screen in favour of an integrated solution in plugin rows on Plugins > Installed plugins and plugin cards on Plugins > Add New.
  3. The plugin row on Plugins > Installed plugins had a Manage Dependencies action link removed, which linked to the removed Dependencies tab.
  4. Messaging was improved to inform the user about missing dependencies.

Security

A security review was performed by @costdev during the development of the feature following WordPress security best practices of escaping output, sanitizing input (slugs, POST, etc.), verifying AJAX referrers and using nonces where appropriate. Comparisons were also done with existing functionality to avoid missed opportunity for hardening the feature.

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)

The feature was reviewed by the team for accessibility concerns. In addition, @costdev reached out to @joedolson regarding the use of links (<a>) as buttons, rather than <button> elements.

It was deemed that this approach, though likely not ideal, is consistent with the patterns throughout the code base today. A wider conversation is needed before a decision can be made about this specific  accessibility pattern at a later date.

wp.a11y.speak() is implemented where appropriate 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/., consistent with prior functionality in Core.

Unit Tests

In addition to user testing, testing by Core developers, and the feature team, unit tests have been written for the feature and the public API is covered. There are plans to continue increasing test coverage during the 6.5 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. period.

Props to @afragen, @pbiron, @azaozz and @desrosj for peer review.

#6-5, #feature-plugins, #feature-projects, #feature-plugin-dependencies, #merge-proposals

Preferred Languages: Help test the latest version

Since the last update on the Preferred Languages feature plugin, a lot of work has been accomplished both on the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party side and in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to make the solution more robust in a variety of ways. Today, I want to provide a bit more details on these accomplishments, which resulted in the recent release of Preferred Languages 2.0, advancing the project a huge step closer towards a core merge proposal

But first, make sure to check out the previous update:

Improved Stability, Fully Rewritten

Over the last year, a lot of work has gone into making the plugin more stable by adding more tests and fixing bugs. This includes improving compatibility with other plugins and making translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. merging and 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. switching more robust. As a result, pure unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. code coverage is near 100%, with end-to-end tests adding another layer of confidence.

With WordPress adding several 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. improvements in WordPress 6.1 and 6.2, the Preferred Languages plugin is now fully compatible with WP_Textdomain_Registry and switch_to_user_locale(). The minimum required WordPress version has been bumped to 6.1 as a result.

Certainly the biggest change, however, was the full refactoring of the UIUI User interface itself. The whole 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/. portion of the code base was over 6 years old and using jQuery and jQuery UI. But not anymore! The UI has been completely refactored to use ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/., with the same components that also power 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. In the process, drag & drop sorting functionality was removed to simplify the UI, and 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) has improved, but otherwise everything looks mostly the same.

How to help

So, what’s next? The latest version of the Preferred Languages feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. needs more eyes testing it and providing feedback.

One big remaining question mark is the concept of translation merging. By default, if there are only some missing strings in a selected locale, these would be displayed in English. But with translation merging, the missing strings will be taken from the locale next in line instead. While this works great, it could be a tad slow due to the way translations are loaded in WordPress. Any help addressing this potential performance concern would be greatly appreciated.

Note: The merging feature can be enabled with add_filter( 'preferred_languages_merge_translations', '__return_true' );.

Active development is taking place on GitHub. If you want to get involved, check out the open issues and join the #core-i18n channel on Slack.

Props to @ocean90 for reviewing this post.

#feature-plugins, #feature-projects, #i18n, #polyglots, #preferred-languages

Enhancing the Scripts API with a loading strategy

Overview

This post outlines a proposal to add a script loading strategy enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s existing Scripts 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 underlying goal of this effort is to make it easier for WordPress 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 theme developers and core to use “modern” loading approaches for 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/. (like defer and async), which will help WordPress sites load faster and operate more smoothly, giving users a better experience.

Why add a loading strategy?

Data from the Web Almanac project (query) indicates that render blocking JavaScript is a significant problem on the web, with 77% of mobile pages having render-blocking scripts in the document <head> . This query shows that approximately 40% of WordPress sites stand to benefit from deferring additional scripts. Adding defer or async to script tags enables script loading without “blocking” the rest of the page load, resulting in more responsive sites overall better user experience.

Currently WordPress core as well as plugins and themes register scripts with the wp_enqueue_script and/or wp_register_script functions. Although these functions include the ability to control the placement of the script (with the in_footer parameter), they don’t include support for adding modern attributes such as defer or async to script tags. 

To add async or defer today, developers must resort to less flexible and more fragile approaches, such as directly filtering the tags at the point of output (using  the script_loader_tag 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.), or handling the 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.) output directly using wp_print_script_tag and the wp_script_attributes filter.

Using the first approach and directly filtering the tag can easily break: for example if two plugins both try to filter a tag, or if a tag has unexpected attributes already (eg. adding defer to a tag that already has async). Using the the second approach developers must carefully handle dependencies and output manually – things that that the Scripts API usually helps take care of.

How the loading strategy works

Developers specify a loading strategy when registering or enqueueing a script. For example, a defer strategy can be specified when the script isn’t required immediately during the page load cycle. WordPress will then determine which scripts can actually use a strategy based on logic for each strategy. For example, to ensure that scripts are executed in the order they are enqueued, defer can only be used on a script if every script that depends on that script can also be deferred. Inline script tags added with wp_add_inline_script would also be considered to ensure proper execution order.

The implementation would come with several initial built-in loading strategies: defer, async, and the default blocking behavior.

Out of scope for this feature

The loading strategy does not enable direct control of script tag attributes. This idea was originally proposed 10 years ago in #22249 and several approaches were considered on that ticketticket Created for both bug reports and feature development on the bug tracker. including a script attribute filter. This proposal takes a step back and aims to solve the script loading strategy aspect more comprehensively and directly while avoiding exposing the potential complications of direct attribute control.

It is worth noting that it is already possible to control attributes on wp_enqueue_script tags directly using the script_loader_tag filter. However, this is a bit of a “brute force” approach which is limited and fragile because it doesn’t consider dependencies and multiple plugins can take conflicting actions on the same tag. 

What are potential concerns with this feature?

One big concern with adding this feature to the WordPress Script API is potentially introducing a breaking change. wp_enqueue_script is a fundamental API in WordPress core, and any breaking changes could have widespread implications. Possible breakage is a possible reason that adding custom attributes as proposed in #22249 was never added to core.

This new proposal aims to ensure that there is 100% backwards compatibility, resulting in zero risk of breakage. The loading strategy will ensure that all existing uses continue to function as expected; for example, passing the boolean in_footer attribute will still control script placement. In addition, it will ensure that scripts continue to be executed in the order they are enqueued – as described above in the “How the loading strategy works” section.

Conclusion and Next Steps

Giving developers the ability to specify a loading strategy will enable them to use more advanced JavaScript loading methods while still ensuring that enqueued scripts are executed in the correct order. A “strategy” approach is also forward thinking: as the web evolves, new strategies can be developed and made available to WordPress developers. After gathering feedback, we will proceed to discussing the implementation approach and, ultimately, proposing a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing..

Have you tried using defer or async with WordPress (or do you already)? How do you think this enhancement would change that? Please leave your feedback about this proposal in the comments below and if you can, join us at our weekly performance team chats, where we are likely to discuss this proposal in the future.

Thanks to @flixos90, @tweetythierry and @mxbclang for help writing and reviewing this post and for the many contributors who have added to the discussion around this enhancement already.

#core, #feature-projects, #javascript, #performance, #proposal

Call for Testing: Plugin Dependencies

The Plugin Dependencies feature plugin is available for testing.

This feature allows 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 to identify which other plugins must be installed so that their plugin functions as expected. This is done by adding a “Requires Plugins” 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. to the docblockdocblock (phpdoc, xref, inline docs) of the main plugin file which contains a comma-separated list of slugs for the required plugins.

The feature is not intended to work with Must-Use plugins, nor does it impact them.

You can find out more about this feature project in the original Make post.

Test Setup

  • Install and activate the Plugin Dependencies feature plugin.
  • Delete the Hello Dolly plugin, a single file plugin cannot be a dependency
  • Copy the three test plugin files from /plugins/wp-plugin-dependencies/test-plugins to the /plugins directory.
  • Navigate to Plugins > Installed Plugins.

Test Instructions / Key Features

  • Confirm that a new adminadmin (and super admin) notice is displayed if there are additional plugins that must be installed if dependencies are missing.
  • Confirm that individual plugins with dependency relationships on Plugins > Installed Plugins display Requires or Required by: under the version information.
  • Add (install/activate) needed dependencies.
  • Confirm that admin notice goes away once all the dependencies have been installed. Dependencies don’t need to be activated for the admin notice to be satisfied and go away.
  • After installing all dependencies, confirm that the new admin notice disappears.
  • Confirm that the Deactivate link and checkbox are not available for plugins that are dependencies with active dependent plugins.
  • Once all dependent plugins are deactivated, confirm that plugin dependencies can then be deactivated and deleted.
  • Confirm that the Add Plugins > Dependencies page lists correct plugins, including non-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/ plugins that are and aren’t supported.

Other Things to Test

  • In a test plugin, try to add a dependency using a plugin’s full name (not slug).
    • No dependency should be noted
  • Add a dependency for a non-wordpress.org plugin slug that is installed/active.
  • Hook the Plugins 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 register a non-wordpress.org plugin.
    • This is done with the GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. Updater plugin
  • Test adding “Requires Plugins” to the DocBlock of a plugin in mu-plugins.
    • Nothing should happen as mu-plugins are not supported for this feature.

What’s New?

In the main plugin file’s docblock:

  • A Requires Plugins header has been introduced.
  • List the slugs of the dependencies in a comma separated string. For example:

Requires Plugins: hello-dolly, akismet, wp-plugin-dependencies

On the Plugins admin page:

  • An admin notice informs site owners if there are additional plugins that must be installed. It will display as long as there are uninstalled dependencies.
  • Each plugin that requires other plugins has a new line in the plugin description. For example:

Requires: <dependency-1>, <dependency-2>, <dependency-3>

Required plugins that are available on wordpress.org are linked to their plugin page.

  • Each plugin required by other plugins has a new line in the plugin description. For example:

Required by: <dependent-1>, <dependent-2>, <dependent-3>

  • Each plugin that is a dependency, and is also dependent on other plugins, has both lines above.
  • If all the dependencies of a plugin have not been installed and activated then the dependent plugin will not be able to be activated.
Plugins page

On the Plugins > Add New > Dependencies tab:

  • The above Requires and Required by data will display in the plugin card.
  • This tab shows a card for each plugin that is required for other plugins to work.
  • Familiar Install Now, Activate and Active buttons are provided so that site owners can manage these plugins.
  • If a dependency is not available on wordpress.org and does not integrate with the Plugin Dependencies feature, it will not be possible to install or activate via this tab. The plugin will display in a generic card.
  • It is possible to integrate a dependency that is not available on wordpress.org with the Plugin Dependencies feature. This requires hooking into the plugins_api_request filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. and returning a valid plugins_api() response. This type of code was added to the 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 a composer dependency with afragen/add-plugin-dependency-api, and a filter to the endpoint returning valid plugins_api() response for the Git Updater plugin. 
Plugin > Add New page

Instructions for Reporting Issues

Please leave feedback in the comments below this post.

If you find an issue:

Thanks for testing! Testing should be completed by December 1, 2022.

Thanks @costdev and @ironprogrammer for assistance.

+make.wordpress.org/test/

#call-for-testing, #core, #feature-plugins, #feature-projects

An Update on Preferred Languages

5 years after announcing the Preferred Languages feature project and implementing the first prototype, it’s time for a long overdue update on where things currently stand.

More than half of all WordPress sites in the world use a language other than US English. For these sites and users, the options to change the site and user language are great. But when there’s no translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. for a given 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, WordPress falls back to US English. That’s a poor user experience for many non-English speakers.

The Preferred Languages plugin solves this issue by doing the same thing operating systems, browsers, and other types of software have been doing for years. It lets you select multiple preferred languages in your settings. WordPress then tries to load the translations for the first language that’s available, falling back to the next language in your list.

The Preferred Languages UIUI User interface

Recent New Features

After stabilizing the initial prototype, the feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. has lived a mostly dormant life, with only irregular updates here and there. Adding support for JavaScript i18n introduced in WordPress 5.0 was the biggest enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.. With the plugin being stable and used on thousands of sites without issues, there was simply no need for any other change. Yet, the plugin was far from feature complete.

Over the past year, I blew the dust off and made significant improvements to the plugin:

  • Bringing UI and code up-to-date with latest WordPress version
  • Improved 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 support, bringing Preferred Languages to Networknetwork (versus site, blog) settings
  • Site Health integration
  • Increased test coverage
  • Improved compatibility with other plugins, especially those accessing the locale user 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.
  • Added an option to merge incomplete translations to avoid fallbacks to US English

The latter is actually a pretty cool enhancement and can be enabled using a 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.. Here’s what it does:

Let’s say your preferred languages are es_CR, es_MX, es_ES, en_US (in this order). With this feature, if some of the translations are incomplete, your site will be displayed in es_CR, with missing strings taken from es_MX, es_ES etc. Without this feature, missing strings would simply be displayed in US English straight away. Merging translations this way makes for a much better user experience.

What’s Still Missing / Open Questions

Textdomain Registry

Since the Preferred Languages feature plugin also needs to work well when switching locales, #39210 has been a missing feature for a long time. While the plugin has its own implementation of a textdomain registry originally created (but then reverted) in that ticketticket Created for both bug reports and feature development on the bug tracker., it is required for this change to finally land in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

My hope is that this can be implemented in WordPress 6.1+.

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

The initial version of the Preferred Languages plugin was built in a pre-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/ era, using jQuery and jQuery UI Sortable. It doesn’t make much sense to potentially merge such a new UI component into core that is built with those technologies.

Rather, some time should be spent to rebuild the client-side code. There are two possible options here:

  1. Rewrite in vanilla JavaScript, replacing jQuery with modern Web APIs. This is most feasible when removing the capability to sort languages using drag & drop, for which jQuery UI Sortable is currently used.

    If we’re okay with dropping drag & drop functionality, then this would be a straightforward change.
  2. Rewrite everything in ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/.. A prototype of this actually exists, so it’s mostly a matter of finishing it up & perhaps submitting some upstream PRs to Gutenberg for any missing features.
    Using React would be more in line with current best practices and expansion of Gutenberg throughout WordPress adminadmin (and super admin). Such a rewrite would also facilitate potential use of the component directly within a Gutenberg context.
    On the other hand, it would significantly increase overall code size and thus maintenance burden, for little immediate benefit.

While I am currently heavily leaning towards the first option, inputs are always welcome!

Of course, if we are okay with keeping jQuery & jQuery UI Sortable, then no change is needed at all.

The Next Steps

The Preferred Languages feature plugin can always use help with development and testing. Right now resolving the two open questions is the main priority before proposing merging this functionality into core.

Active development is taking place on GitHub. If you want to get involved, check out open issues and join the #core-i18n channel on Slack.

#feature-plugins, #feature-projects, #i18n, #polyglots, #preferred-languages

Version 1.0.0 of the Performance Lab plugin published

The first stable version 1.0.0 of the Performance Lab pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party has been released. You can download it from the WordPress plugin repository or via GitHub.

The stable release means that the Performance Lab plugin’s infrastructure is now out of betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. testing stage. The plugin’s primary purpose remains to facilitate beta testing for future WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. performance features and enhancements, as outlined in the original plugin announcement post. The initial beta phase for the plugin was primarily to allow the performance team to discover early infrastructure bugs and fix them before the stable launch.

Included modules

The following modules are included in the 1.0.0 release:

  • WebP Uploads: Creates WebP versions for new JPEG image uploads if supported by the server. View related GitHub issues
  • WebP Support: Adds a WebP support check in Site Health status. View related GitHub issues
  • Persistent Object Cache Health Check: Adds a persistent object cache check for sites with non-trivial amounts of data in Site Health status. View related GitHub issues
  • Audit Autoloaded Options (experimental): Adds a check for autoloaded options in Site Health status. View related GitHub issues
  • Audit Enqueued Assets (experimental): Adds a CSSCSS Cascading Style Sheets. and JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. resource check in Site Health status. View related GitHub issues

Next steps

The performance team is going to continue enhancing the existing modules and evaluating additional modules to add in the future. The cadence and versioning strategy for upcoming releases is currently up for discussion. Please provide your feedback on plugin versioning in this issue if you are interested. There is an ongoing vote in that issue which is open until 2022-05-02 17:00 UTC.


Kudos to all the people that have contributed to and tested the Performance Lab plugin so far and made this first stable release possible! Let’s keep testing and iterating on the individual features to bring each of them closer to an eventual WordPress core merge.

Props to @mxbclang @adamsilverstein @jeffpaul for review and proofreading.

#feature-plugins, #feature-projects, #performance, #performance-lab

The Performance Lab plugin has been released

Introducing the Performance Lab pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party: After the WordPress performance team began work on it in November 2021, the first version of the plugin is finally here and ready for testing. You can download it or install it directly from your WordPress dashboard. Your testing and feedback will allow iterating towards adding future performance optimizations in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

What is the Performance Lab plugin?

The Performance Lab plugin is a set of modules that aim to improve performance in WordPress. While this may sound similar to the numerous other performance plugins in the WordPress ecosystem, the Performance Lab plugin exists for an entirely different purpose: It is a collection of performance-related “feature projects” for WordPress core.

Feature projects are intended to gather a group of people to explore potential ideas for WordPress core.

Feature Projects Overview

Historically, feature projects have usually been implemented as separate feature plugins. The Performance Lab plugin provides a centralized location for performance-related features which are intended to eventually be merged into WordPress core. Therefore, it should be considered a 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 plugin. The plugin’s performance modules can be individually enabled in the plugin’s settings screen, so that they can be tested in isolation or in combination. Being able to activate/deactivate modules is similar to activating individual plugins, but the Performance Lab approach comes with benefits: For both developers and end users, it removes the burden of keeping track of several plugins. For developers, it additionally reduces maintenance and encourages collaboration between developers.

Settings > Performance screen of the plugin with a list of modules that can be individually toggled on and off
The Performance Lab plugin’s settings screen

Another benefit of the single plugin approach taken with the Performance Lab plugin is that it provides room for experimentation. Some modules included in the plugin are explicitly marked as experimental, and while the entire plugin is for testing WordPress performance features, those modules are at a particularly early stage of exploration and therefore could lead to unexpected results This also leads to the clarification that all performance modules bundled in the Performance Lab plugin are at different stages of development. For example, some may already be official WordPress core feature projects, others may be proposed as feature projects in the near future. Some experimental modules may remain in exploration for a few months to come.

Because the Performance Lab plugin is a collection of potential WordPress core feature modules, the list of modules included may drastically change over time. New modules may be added regularly, while other modules may be removed in a future plugin version once they have landed in a WordPress core release. Also keep in mind that the Performance Lab plugin is not a full replacement for other WordPress performance plugins you may be using already.

Who develops the Performance Lab plugin?

The Performance Lab plugin is being actively worked on by the WordPress performance team, which was formed in late October 2021. The plugin is the primary project of the team where new performance features are being explored and implemented. It complements the direct contributions to WordPress core, which happen for smaller fixes or for features that already have seen significant testing in the plugin.

The modules included in the plugin are based on the priorities of the performance team contributors who meet weekly in the #performance Slack channel to discuss the ongoing efforts and priorities. The performance team takes into account the impact of different features while prioritizing work, and the modules included are also influenced by contributor interest. So far, over 250 people have joined the performance SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel, with many of them participating in the weekly chats and reporting issues on GitHub. While code contributions to the plugin so far have been limited to just slightly more than 10 contributors, the performance team is confident that the volume of code contributions will increase over time, especially as the plugin starts seeing increased usage.

Which features come with this initial Performance Lab plugin version?

This initial release of the Performance Lab plugin (1.0.0-beta.1) comes with the following modules:

  • WebP Uploads: Creates WebP versions for new JPEG image uploads if supported by the server. View related GitHub issues
  • WebP Support: Adds a WebP support check in Site Health status. View related GitHub issues
  • Persistent Object Cache Health Check: Adds a persistent object cache check for sites with non-trivial amounts of data in Site Health status. View related GitHub issues
  • Audit Enqueued Assets (experimental): Adds a CSSCSS Cascading Style Sheets. and JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. resource check in Site Health status. View related GitHub issues

To test the WebP Uploads module, upload some JPEG images to the Media Library, and the module should ensure that the sub-sized versions are also generated in WebP and then used in the front-end when embedding such uploaded images in a post.

To test the other three modules, visit the Site Health status tab, where each module adds a corresponding new check:

  • The Audit Enqueued Assets module monitors the amount of scripts and stylesheets enqueued on your homepage.
  • The WebP support module checks whether your server environment supports creating WebP images.
  • The Persistent Object Cache Health Check promotes usage of an external object cache depending on the amount of data on your site.

Remember that each module you would like to test has to be activated via the plugin’s settings screen at Settings > Performance. Non-experimental modules are enabled by default. If you want to test the modules individually in isolation, you can toggle them one by one.

To learn more about the modules, you can use the 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/ labels to follow along their development via the links from the list above. You can also review the full release changelog.

How can I support the Performance Lab plugin?

Since the Performance Lab plugin is a beta testing plugin, the most straightforward way of contributing is to use it! Test the individual modules, try to break them, explore edge-cases etc. Any feedback or 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. reports are welcome as GitHub issues or alternatively as wordpress.org support forum requests. If you have found a bug and already discovered a fix for it, you can submit a  pull request. You’re also invited to share your feedback in a review. Last but not least, share the news! Only with a solid number of regular testers can the features in this plugin mature over time.

If you would like to participate in developing or shaping the direction of the plugin, the performance team would be pleased to have you join the weekly chats in the #performance Slack channel! The next one will take place at March 8, 2022, at 16:00 UTC.

Another area to contribute to the plugin is localization. If you speak a language other than English, help make the Performance Lab plugin available in your 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. by contributing translations.


Many thanks to all the community volunteers that have contributed to the Performance Lab plugin and the overall efforts of the performance team so far! This beta release is a major milestone and just the beginning – let’s continue from here.

Props to @addyosmani @jonoaldersonwp @tweetythierry @mxbclang @adamsilverstein @clarkeemily @mitogh @dainemawer @justinahinon for review and proofreading.

#feature-plugins, #feature-projects, #performance, #performance-lab

Feature Project: Plugin Dependencies

Problem

This feature project began as part of Outcome 4 of Updating the Updaters.

Any 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 that requires another plugin (i.e., a dependency) is on its own to make sure admins install the dependency. After all, the plugin will not work without it. But with more than 55,000 plugins in the repository, that means there are potentially 55,000 plugins capable of resolving the dependency.

It would be a lot simpler for users and admins, and plugin developers, if there were a consistent way to handle dependencies in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Among other things, that approach would entail a clear method of determining when a plugin needs a dependency and what that dependency is.

Improving the plugin experience.

There’s a whole categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. of plugins that are designed from the ground up to add new abilities to other plugins. Think of shipping and other add-ons for commerce plugins, and one-click checkout for event plugins that sell tickets.

The situation there is a lot like the relationship between parent and child themes. Without their relationships to the bigger plugin, those dependent plugins can do very little. As noted above, every plugin developer is on their own to code a solution to resolve the issue. And, as noted above, the single most common example is WooCommerce, which is a dependency for hundreds, if not thousands, of WooCommerce add-on plugins. 

What’s more, this is not a new problem. Across the WordPress ecosystem, people have been looking at it for at least nine years—starting with #22316.

The original scope listed in #22316 was the following.

  • Plugins list WP.org slugs of their dependencies in their readme.txt, or perhaps better their plugin’s 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..
  • When you go to install a plugin via the plugin directory UIUI User interface in the adminadmin (and super admin) area, the WP.org 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. returns a list of dependencies along with the data about the plugin being installed. WP would say like “these following dependencies will also be installed”. This means it’s seamless to the user — they install a plugin and the other plugin(s) that are needed get installed too.
  • No versioning support. It’s too complicated and what if one plugin wants an older version of a dependency than another plugin does? If your plugin is listing another as a dependency, then it’s your job to make sure it stays compatible with the latest version of the dependency. On the flip side, hopefully plugins that get listed as dependencies are made to be forwards and backwards compatible.
  • Probably not allowing the disabling of plugins that are dependencies while their dependents are active. This seems better than disabling the dependents when the dependency is disabled (“why did Foo get disabled? I only disabled Bar!”).
  • On plugin re-activation or on activation of a plugin uploaded 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., make sure it’s dependencies are already installed. If not, offer to install them. If installed but disabled, just enable them for the user.

The last bullet point implies automatic installation and/or activation, after previous discussions, it was thought this should be discouraged in the name of preventing a very jarring user experience.

Fundamentally there should be a simple, clear method for identifying and installing plugin dependencies. Any plugin that requires a dependency should degrade gracefully if that dependency is not present. This is the responsibility of the plugin developer.

Design/Discovery

There are hundreds of comments, ideas, and decisions that have been discussed on #22316 and on some of the PRs below. I will attempt to summarize.

  • This is not an attempt to create a plugin package manager.
  • This is not an attempt to integrate Composer into WordPress or use Composer.
  • The agreed upon interface is via a plugin header, Requires Plugins, containing a comma-separated list of plugin slugs.
  • The most agreed upon UI for notifying users of a missing dependency requirement is via an admin notice.
  • There is no attempt at version controlversion control A version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories.. The current plugin version in the dot org repository will be used.
  • There is no automatic installation or activation of the dependent plugin.
  • If the dependency requirements are not met, the requiring plugin cannot be activated.
  • Dependencies outside of the dot org repository are not directly supported, but may be added by correct use of the plugins_api_result 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..
  • This is only for plugin dependencies that are required not recommended.
  • Plugin dependencies for themes is out of scope at this time.

Current Suggested Solutions

There are currently two approaches to handling plugin dependencies.

Similarities

  • Both use a plugin header, Requires Plugins, that contains the plugin dependencies within a comma-separated list of dot org plugin slugs.
  • Both show the user an admin notice if there are plugin dependencies should be installed.
  • Users must actively install and activate the dependencies.
  • Users will find they cannot delete or deactivate installed and activated plugin dependencies without deleting or deactivating the plugin that requires the dependency.
  • Relevant messaging in the dependency plugin row of the plugins page. (Formatting differs between approaches)
  • Neither approach makes any attempt at dependency version control. Most recent version of dependency from dot org is used.

Differences

The differences in the two approaches are subtle, but they do exist.

Current PRs

Approach 1

https://github.com/WordPress/wordpress-develop/pull/1547

  • Shows an admin notice for each plugin dependency to both inform the user of the dependency and lets the user install/activate with a click.
  • Plugins with unmet dependencies do not get activated; they go into an activation queue. Once dependencies are met the plugin is activated. 
  • Users can cancel activation requests for plugins with dependencies. Messaging added as an additional element to the plugin row.

Screenshots from PR

I hope the screenshots are representative of the PR. If not, it is entirely my fault (@afragen)

Approach 2

https://github.com/WordPress/wordpress-develop/pull/1724

  • A single admin notice alerts the user to unmet dependencies in any plugin. If multiple plugins have dependency problems, the notice compiles all the notices in one place. This notice persists until all dependencies have been installed. 
  • Adds dependencies using a new view/tab/filter on the plugins-install.php page.
  • On the plugin card, shows which plugins require which dependencies.
  • Once a particular dependency is installed, shows a list of plugins that require it at the end of the plugin’s description in the plugin row.
  • Adds relevant messaging to the plugin’s description.
  • Automatically deactivates any plugin that has unmet dependencies and informs the user in an admin notice. 
  • Lets the user deactivate or delete a dependency if the requiring plugin is not active.
  • Install the Plugin Dependencies Tab plugin as a possible feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins..

Some of the screenshots below may be slightly outdated.

Screenshots from PR

When attempting to activate a plugin with unmet dependencies.
Dependencies tab info

Further Discussion

Pertinent discussions about the best way to implement this are still needed. It doesn’t have to be one of the above approaches, but they are certainly starting points.

Thanks to @peterwilsoncc, @aristath, @audrasjb, @karmatosed, @costdev for assistance along the way. Thanks @marybaum, @bph for editing assistance.

Special thanks to @francina for the initial nudge.

#core, #feature-plugins, #feature-projects

Auto-updates feature weekly meeting agenda – July 28th, 2020

Next meeting is scheduled on Tuesday July 28, 2020 at 17:00 UTC and will take place on #core-auto-updates 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 with the following agenda:

  • Progress report on Docs
    • HelpHub end-user documentation
    • 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.
    • About page/communication
  • Remaining tickets:

Got something to propose for the agenda? Please leave a comment below.

#auto-update, #auto-updates, #core-auto-updates, #feature-plugins, #feature-projects, #feature-autoupdates