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

Call for Testing: Plugin Dependencies UX

We are seeking basic workflow feedback for the Plugin Dependencies feature. Testing should be very straightforward.

The testing 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 was chosen because it fulfilled the following criteria:

  • Plugin is in the plugin repository.
  • Plugin has the required 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. for Plugin Dependencies.

How to Test

  1. Install and activate the Plugin Dependencies feature plugin.
  2. Install and activate The Events Calendar CategoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. Colors plugin.

The goal is to see how intuitive the process is or might become.

Feedback

  • What did you do?
  • Did you get stuck? Where?
    • Were you able to figure out the path forward?
    • What did you do?
  • Did the experience feel “natural” to WordPress?

Thanks for testing. Testing should last for 3 weeks.

Please add your feedback in the comments.

+make.wordpress.org/test/

#call-for-testing, #feature-plugins

Fields API Kick-off Chat Summary: January 5th, 2023

It’s been over 4 years since the Fields API project has been active and many things have changed for WordPress in that period.

Since then, many things were introduced into WordPress itself including things like:

  • 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
  • Full Site Editing has replaced the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. (which is now only used for classic themes)
  • New Navigation editing
  • Widgets are now legacy and have been replaced with new blocks and a new WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. editor
  • Newer PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher compatibility (testing still in progress for PHP 8.0+) and talks of upping the minimum PHP version

All of that has led to @joedolson approaching me to determine if it’s worth bringing Fields 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. back with a new vision.

After some initial discussion, the passion reignited within me to get this going again and we ended up having our first kick-off meeting today to discuss where we’ve been, where we’re at, and where we want to go in 2023. This and future work will be organized through our 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 #core-fields

Read below for what we discussed and here’s a link to watch the video from our initial meeting.

Video recording

The kick-off discussion

Meeting notes

Introductions

  • @sc0ttkclark – Scott Kingsley Clark
    • Senior Software Engineer at Pagely / GoDaddy
    • Lead Developer of the Pods Framework
    • Previously Co-Lead of the Fields API project from 2013-2016 with @ericlewis and then Lead Developer from 2016-2017
  • @borkweb – Matthew Batchelder
    • Been working with WordPress since ~2004
    • Worked with The Events Calendar and now Director of Engineering at StellarWP overseeing their products and initiatives
  • @joedolson – Joe Dolson
    • Contributing to WordPress since about 2006
    • WP CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component.
    • Working on the 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) team
    • Reached out to Scott about Fields API from the perspective of improving accessibility for the Settings page
  • @jason_the_adams – Jason Adams
    • Manager of Development at GiveWP
    • Matt and him want to get together about how to help create unified libraries for multiple projects across StellarWP and other companies
    • GiveWP has it’s own Field API that it’s been pushing forward as well
  • @peteringersoll – Peter Ingersoll
    • Worked with WP for about 10 years
    • Not a developer but a user/self-titled user advocate
    • Coming at this as a perspective as a user who is interested in how this will work

Overview of Fields API – where we started

  • Started work in November 2013 with @ericlewis as lead and @sc0ttkclark as co-lead
  • Started holding meetings back when Freenode IRCIRC Internet Relay Chat, a network where users can have conversations online. IRC channels are used widely by open source projects, and by WordPress. The primary WordPress channels are #wordpress and #wordpress-dev, on irc.freenode.net. was being used before Slack
  • Initial focus was around Post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. fields and meta boxes in the Post Editor
  • Expanded over time to cover a generalized API to work with
    • Post meta boxes and their fields
    • Settings fields (replacing the Settings API)
    • User profile fields (edit profile, add new user)
    • Term fields (add term, edit term)
    • Comment fields (add comment on frontend, edit comment in dashboard)
    • Media fields (modal)
    • Customizer (allowing the Customizer to see Fields API configurations)
  • We built 3 different prototypes over time
  • Hundred of plugins in WP have their own Fields API and lots of devs have their own preference on code structure so there were lots of voices with different opinions for what the Fields API should look like
  • WP Core team (committers and contributors) were somewhat receptive but we couldn’t gain momentum
  • The block editor and other projects started up which reduced priority for getting Fields API into WP especially since it wasn’t just one small part of WP
  • @sc0ttkclark reached out for anyone else to take over the project as lead (while Scott supported) but couldn’t find anyone so the project became inactive

Rebooting Fields API – where we’re at

  • @joedolson approached @courane01 and @sc0ttkclark to see if we wanted to tackle Accessibility as a goal for a smaller reboot of the Fields API
  • The GitHub repository has been unarchived and is ready to start the next steps of getting things going again
  • Lots of test coverage for the API itself
  • A number of examples of how to work with the API
  • Implementations that were covered at the time (in WP 4.5)
  • Things that were in progress at the time (in WP 4.5)
  • @jason_the_adams gave a demo of the GiveWP Fields API
    • Uses a mid-level API to register the configurations
    • Implementations handle rendering those
    • The primary implementation is a Block Editor powered form editing experience
    • @borkweb and @sc0ttkclark provided positive feedback about the PHP side of things

Where we’re going

  • @sc0ttkclark What PHP version should we target?
    • PHP 5.6 is the current minimum and we’ll stick to that unless progress is made on upping the minimum WP version
    • If the minimum version is upped, we can revisit this and adjust our code to follow suit
  • @borkweb How we approach things in WP now is much different than back when the Fields API started
    • Is there merit in separation of data and output like what GiveWP is doing versus what the very coupled approach that the Fields API has right now
  • @joedolson Whether this can be potentially be used for the Block Editor may have a big impact on whether it has traction, though there are plenty places where it could be useful
  • @sc0ttkclark
    • Content areas like Posts and Terms, we’ll likely see more expansion of the Block Editor
    • There are a few places in WP that may not make sense to be in the block editor itself
      • Settings
      • User profile
      • Maybe others?
    • Those areas may eventually 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/. components to render but won’t live in the “Block Editor” that we know of today
    • We could separate the Fields API focus into specific component implementations, not unlike what we had before but with the goal being that we are registering structure – whether or not that is the same exact input used for each screen (some screens will need their own form implementations for their inputs that may not be HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. renders)
    • If we wanted to implement Fields API for the Block Editor, it could help register Components for the Inspector Panel for Blocks, which is currently an area with high copy/paste
      • Fields API could register Inspector Panel sections and components
    • PHP has grown up and it may be better to use objects than straight PHP arrays especially since that can work with IDEs and help with autocomplete for a better developer experience
    • With the Fields API, I want to make possible the idea that you can interact with the configuration of a form and add/change fields by registering new fields or adjusting their configurations
    • Knowing what the structure of a page is (outside of just basic actions that people use now to render HTML) gives devs the ability to take those configurations and consume them through 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/, the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/., and PHP for custom implementations like the WordPress iOSiOS The operating system used on iPhones and iPads. app and many other apps that need to represent the various edit screens
  • @borkweb So the Fields API project would morph into a data layer and one or more rendering implementations to consume that
  • @sc0ttkclark
    • We can focus on Settings page at first and go from there into the User profile, but leave everything else out until we gain traction and get something into Core
    • Don’t focus on legacy things like the Classic Editor or Customizer or the Widget forms
  • @joedolson Getting this built out and implemented is a challenge but I’m game
  • @sc0ttkclark We should figure out what we want to structure the Fields API off of, but use object oriented as much as possible and make the focus on better developer experience so we can help level up working with WP
    • We could look at the structure of GiveWP’s Fields API and other modern Fields APIs from other plugins/libraries
    • Avoid looking back at older/legacy plugins and libraries
    • Find a consensus on what makes sense that most people will be familiar with based on what’s popular/modern
    • The current Fields API is based on the Customizer API which has become antiquated already

Next steps

  • Meetings: Figure out the frequency of meetings and when our next meeting is
  • Viability: Get a gut-check from WP core dev team in the core meeting and through responses to this post on direction and our focus
  • Spec: Look at modern Fields APIs in modern plugins/libraries and figure out how we want that structure to look like through a new spec doc
  • Code: Start with a Settings API implementation collaborating with @joedolson and the Accessibility team to ensure that side is accessible
  • Testing: Ensure the API is well tested with unit tests
#feature-plugins, #fields-api, #options-meta, #summary

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

Upgrade/Install Component meeting summary – February 9, 2021

These are the weekly notes for the Updates/Install component meeting that happened on Tuesday February 9, 2020. You can read the full transcript on the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-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.

This meeting was focused on the Rollback Failure Update Feature PluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins., which is a project led by @afragen.

Contribute to the Rollback Failure Update feature plugin

For now, this feature plugin is located on @afragen’s GitHub account: https://github.com/afragen/rollback-update-failure.

Everyone is welcome to contribute. Please feel free to get in touch with the #core-auto-updates team on Slack.

Quick recap of the feature plugin goals

This is a feature plugin based on the Pull Request proposed in the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #51857. The assumption is that most of the errors in large plugins/themes occur during the copy_dir() part of WP_Upgrader::install_package(). Trac ticket #52342 brought more error reporting to copy_dir() and Trac ticket #52831 provides 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. hook in order to do the actual rollback in the event of a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/theme update failure. As of WordPress 5.7-beta1 both of these tickets are in core.

There was much discussion regarding the thought that adding additional IO processes for the zip and unzip process could result in server timeout issues on resource starved shared hosts.

Activating the feature plugin will result in the creation of a ZIP file of the installed plugin/theme being updated every time an update is performed. The unzip process only occurs during testing or a WP_Error resulting from WP_Upgrader::install_package().

Next steps

  • The Upgrade/Install team will publish a Feature Plugin proposal on Make/Core;
  • The feature plugin will be released 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/ plugins repository;
  • A 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. ticket will be opened on the Meta Trac in order to ask the meta team to create a new 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/ project in the WordPress.org GitHub account. @afragen will lead this projet on the WordPress GitHub account;
  • Provide visibility to the feature plugin;
  • Test, learn, iterate.

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

Outcomes from the last WP Notify feedback post

A month ago I posted an update post for WP Notify, in order to start planning for the next phase of this project.

This post includes a short review of the feedback from that post, as well as the outcomes/next steps.

Feedback

  • Generally the feedback on the post and the requirements document was good. It was also pleasing that more new contributors were made aware of the project, and left their comments on the document.
  • It was generally agreed that 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/ repository makes the most sense as a central location for all work to be done.
  • There was no general consensus around the weekly meetings.

Outcomes

The GitHub repository has been created. We need to decide if we’re going to start building using existing code, or completely from scratch.

We also need to start designing the user interfaces. There are already designs from @hedgefield on the original trac ticket, but those designs may need a refresh based on our current requirements document.

And finally, I’ll be resurrecting the weekly meetings in the #feature-notifications channel in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. These meetings will however switch to an office hours format, without an informal agenda. These office hours will take place on Mondays at 14:00 UTC. Due to time constraints on my side, the first open office hours will be on Monday, August 17, 2020, 14:00 UTC.

I invite all interested parties to join me in our first office hours on the 17th of August 2020, as we start implementing the project we’ve all been planning for the past year.

#feature-plugins, #feature-notifications, #team-update