The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA 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.?Create a ticket in the bug tracker.
Since the last update on the Preferred Languages feature plugin, a lot of work has been accomplished both on the pluginPluginA 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 coreCoreCore 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:
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 translationtranslationThe process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. merging and localeLocaleA 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 testCode 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 i18ni18nInternationalization, 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 UIUIUser interface itself. The whole JavaScriptJavaScriptJavaScript 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 ReactReactReact 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 blockBlockBlock 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 accessibilityAccessibilityAccessibility (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 PluginA 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.
We are seeking basic workflow feedback for the Plugin Dependencies feature. Testing should be very straightforward.
The testing pluginPluginA 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 PluginsheaderHeaderThe 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.
Install and activate The Events Calendar CategoryCategoryThe '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.
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:
BlockBlockBlock 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 CustomizerCustomizerTool 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 WidgetWidgetA 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 PHPPHPThe 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 APIAPIAn 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 SlackSlackSlack 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.
WP CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.CommittercommitterA 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 AccessibilityAccessibilityAccessibility (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
Started holding meetings back when Freenode IRCIRCInternet 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 metaMetaMeta 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)
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
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 ReactReactReact 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 HTMLHTMLHyperText 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-CLIWP-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 APIThe 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 iOSiOSThe 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
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
This feature allows pluginPluginA 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” headerHeaderThe 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.
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.orgThe 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 APIAPIAn 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 GitGitGit 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:
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:
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_requestfilterFilterFilters 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 PluginA 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.
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 translationtranslationThe process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. for a given pluginPluginA 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 UIUIUser interface
Recent New Features
After stabilizing the initial prototype, the feature pluginFeature PluginA 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 enhancementenhancementEnhancements 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 MultisitemultisiteUsed 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 metaMetaMeta 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 filterFilterFilters 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 ticketticketCreated for both bug reports and feature development on the bug tracker., it is required for this change to finally land in coreCoreCore 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+.
JavaScriptJavaScriptJavaScript 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-GutenbergGutenbergThe 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:
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.
Rewrite everything in ReactReactReact 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.
The first stable version 1.0.0 of the Performance Lab pluginPluginA 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 betaBetaA 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 coreCoreCore 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
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 CSSCSSCascading Style Sheets. and JSJSJavaScript, 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.
Introducing the Performance Lab pluginPluginA 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 coreCoreCore 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.
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 betaBetaA 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.
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 SlackSlackSlack 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
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 CSSCSSCascading Style Sheets. and JSJSJavaScript, 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 GitHubGitHubGitHub 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 bugbugA 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 localeLocaleA 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.
Any pluginPluginA 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 CoreCoreCore 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 categoryCategoryThe '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 headerHeaderThe 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 UIUIUser interface in the adminadmin(and super admin) area, the WP.org APIAPIAn 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 FTPFTPFTP 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 controlA 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_resultfilterFilterFilters 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.
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 PluginA 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.
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 coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.-auto-updatesSlackSlackSlack 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 UpdateFeature PluginFeature PluginA 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 TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.ticketticketCreated 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 filterFilterFilters 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 pluginPluginA 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.orgThe 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 MetaMetaMeta 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 GitHubGitHubGitHub 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;
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 GitHubGitHubGitHub 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.
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 SlackSlackSlack 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.
You must be logged in to post a comment.