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.
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.
Dev notesdev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.
Site security is an integral part of modern websites. Keeping sites up to date by running the latest versions of WordPress, PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher, and any installed plugins or themes is highly recommended as an easy way to keep a site safe from any known security vulnerabilities.
By default, WordPress itself is configured to automatically update when new minor versions become available. While the code to auto-update plugins and themes has been in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. for just as long, it’s seldom used by site owners because it requires the use of 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.
This past February, a feature plugin was created in response to the 9 Projects for 2019/2020 to explore introducing a user interface that allows site administrators to easily manage 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 and theme auto-updates right from the dashboard. After 5 months of development on the GitHub repository, user feedback (the plugin was available on the WordPress.org plugin directory), testing (which includes over 1,000 active installs), and iterating by the contributors of the #core-auto-updates team, this feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. was merged into Core in [47835] and will be released in WordPress 5.5.
A screenshot of a site’s Plugins page in the dashboard with the new “Automatic Updates” column (click to open this image in a new tab).
These new controls will allow website owners to keep their sites up-to-date and secure with less time and effort.
Note: Plugin and theme auto-updates are disabled by default. Administrators and site owners need to enable this feature to receive automatic plugin and theme updates. However, language packs for plugins and themes have always auto-updated when new updates are available. The new interface will not adjust language pack updates.
By default, all users with the update_plugins and update_themes capabilities are able to toggle auto-updates for plugins and themes respectively. On 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 installations, only networknetwork(versus site, blog) administrators have this capability, and only when in the context of the network dashboard.
A number of hooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. are included for plugin authors and WordPress developers to customize the new feature to fit their needs. Let’s have a look at the available functions and hooks and how they can be used to tailor the plugin and theme auto-update experience.
New function: wp_is_auto_update_enabled_for_type()
This function indicates whether auto-updates are enabled for a given type. The two types accepted are theme and plugin.
// Check if auto-updates are enabled for plugins.
$plugin_auto_updates_enabled = wp_is_auto_update_enabled_for_type( 'plugin' );
Disable the auto-update user interface elements
It is possible to disable the new interface elements if desired. Returning false to the plugins_auto_update_enabled and themes_auto_update_enabled filters will disable the user interface elements for plugins and themes respectively. By default, these are enabled (true).
Note: This does not enable or disable auto-updates. It controls whether to show the user interface elements.
The following snippet will disable the plugin and theme auto-update UIUIUser interface elements:
Sometimes, a plugin or theme may want to manage updates on their own. This is common when they are not hosted on the 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/ directories. For these instances, there are filters in place so plugin and theme authors can modify the auto-update related HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. output in certain locations.
Plugins screen: single site and multisite
With the plugin_auto_update_setting_html filter, it’s possible to filter auto-update column content, including the toggle links and time till next update attempt.
This filter pass the default generated HTML content of the auto-updates column for a plugin, with two additional parameters:
$plugin_file: The path to the main plugin file relative to the plugins directory.
$plugin_data: An array of plugin data.
For example, let’s say the “My plugin” plugin wants to prevent auto-updates from being toggled and its path relative to the plugins directory is my-plugin/my-plugin.php. The following example will change what is displayed within the auto-update column for that plugin:
function myplugin_auto_update_setting_html( $html, $plugin_file, $plugin_data ) {
if ( 'my-plugin/my-plugin.php' === $plugin_file ) {
$html = __( 'Auto-updates are not available for this plugin.', 'my-plugin' );
}
return $html;
}
add_filter( 'plugin_auto_update_setting_html', 'myplugin_auto_update_setting_html', 10, 3 );
Below is the result:
In the screenshot above, the default toggling action in the auto-updates column for one particular plugin has been modified using the previous example (click to open this image in a new tab).
For reference, here is the default HTML content:
<a href="…" class="toggle-auto-update" data-wp-action="…">
<span class="dashicons dashicons-update spin hidden" aria-hidden="true"></span>
<!-- The following text is replaced with "Disable auto-updates" when auto-updates are already enabled for this plugin -->
<span class="label">Enable auto-updates</span>
</a>
Themes screen: single site only
Filtering the auto-update HTML content for Themes screen is a bit more tricky since this screen is rendered with a 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/. template. However, it is possible to hook into this screen using the theme_auto_update_setting_template filter and returning a modified $template (the rendering template used for every theme on the Themes page).
Note: since this template is used for each theme on the page, using a conditional statement to check for the theme being targeted is highly recommended. This can be done by utilizing the data.idJSJSJavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. parameter (which contains the theme slug).
The following example will replace the text auto-update HTML content for the my-theme and twentytwenty themes:
function myplugin_auto_update_setting_template( $template ) {
$text = __( 'Auto-updates are not available for this theme.', 'my-plugin' );
return "<# if ( [ 'my-theme', 'twentytwenty' ].includes( data.id ) ) { #>
<p>$text</p>
<# } else { #>
$template
<# } #>";
}
add_filter( 'theme_auto_update_setting_template', 'myplugin_auto_update_setting_template' );
Below is the result:
In the screenshot above, the default toggling action for auto-updates has been modified using the previous example (click to open this image in a new tab).
For reference, here is the default template output:
On multisite installs, the Themes screen can be modified in a way similar to the Plugins screen detailed above. Using the theme_auto_update_setting_html filter, the auto-update column content can be filtered, including the toggle links and time till next update.
This filter is passed the default generated HTML content of the auto-updates column for a theme with two additional parameters:
$stylesheet: The directory name of the theme (or slug).
$theme: The full WP_Theme object.
For example, let’s say the network administrator of a multisite network wants to disallow auto-updates for the Twenty Twenty theme. The following example will change what is displayed within the auto-update column for that theme:
function myplugin_theme_auto_update_setting_html( $html, $stylesheet, $theme ) {
if ( 'twentytwenty' === $stylesheet ) {
$html = __( 'Auto-updates are not available for this theme.', 'my-plugin' );
}
return $html;
}
add_filter( 'theme_auto_update_setting_html', 'myplugin_theme_auto_update_setting_html', 10, 3 );
Blanket auto-update opt-in
If a developer wants to enable auto-updates for all plugins and/or themes (including any that are installed in the future), the auto_update_plugin/auto_update_theme filters can be used.
// Enable all plugin auto-updates.
add_filter( 'auto_update_plugin', '__return_true' );
// Enable all theme auto-updates.
add_filter( 'auto_update_theme', '__return_true' );
Note:Any value returned using these filters will override all auto-update settings selected in the adminadmin(and super admin). Changes made using these filters also will not be reflected to the user in the interface. It is highly recommended to use these filters in combination with the hooks detailed above to inform the user of the auto-update policy being enforced.
This approach will not be appropriate for all sites. It’s recommended to use the new UI to manage auto-updates unless you’re sure blanket opting-in is right for your site.
Also note: This filter was added to the codebase in WordPress 3.7.0 and is likely being used to blanket enable auto-updates for plugins and themes on sites today. If it appears the new UI elements are not changing the auto-update behavior for plugins or themes on your site, this may be why. #50662 has been opened to notify site owners that this filter is being used in Site Health.
For information, refer to the following tickets on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.: #50052, #50280.
This post is the first part of the plugins and themes auto-updates dev notesdev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. for WordPress 5.5.
Thanks @desrosj and @pbiron for technical review and proofreading.
These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday July 14, 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.
Reminder: WP Auto-updates Feature has been merged into WordPress Core so bugs reports and enhancements requests should now happen on Core Trac.
Dev notedev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. for WordPress 5.5
@audrasjb drafted a dev note focused on hooking the plugins and themes auto-updates UIUIUser interface controls. @pbiron, @desrosj and @azaozz started to review this proposal.
It was previously decided to split the auto-updates dev note into several Posts. @audrasjb also drafted a dev note for email notifications. @pbiron pointed out that a dev note will be necessary for Site health screen hooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. and functions. It will probably be added to the second dev note about email notifications. The first dev note will be published on Wednesday or Thursday.
Update on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
#50350: A couple weeks ago, the team agreed to add the version updated TO to the emails for 5.5 and possibly add the version updated FROM in 5.6. @audrasjb is working on a patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. for this.
Concerning #50512, items 1, 2 and 4 of the ticketticketCreated for both bug reports and feature development on the bug tracker. are already fixed. Item 3 will be discussed on Friday by 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.
@johnbillion pointed out that #50437 needs some more discussion. This ticket will probably be moved to milestone 5.6.
Concerning #50623, It’s probably too late to address this ticket before 5.5 is released, but @audrasjb proposed to comment with few links to previous decisions (especially design decisions, as the design team already reviewed the interface) made by the team.
@apedog asked for review on ticket #32101, but given it’s not directly related to plugins and themes auto-updates, it’s probably better to raise this ticket during core team dev chat meeting.
These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday June 16, 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.
Reminder: WP Auto-updates Feature has been merged into WordPress Core so bugs reports and enhancements requests should now happen on Core Trac.
Update on TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
#50215 – Help Tabs implementation. This ticketticketCreated for both bug reports and feature development on the bug tracker. was discussed by the team and the patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. was merged by @whyisjake during the meeting.
#50268 – Auto-update email notifications. @desrosj is working on a new patch.
#50350 – Provide 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 and theme versions informations in auto-updates email notifications. This ticket still needs a patch. @audrasjb is working on it.
#49771 – Double “Updated!” text blocks when updating theme. This one still needs a patch.
#50280 – Enable auto-updates shows for plugins with no support. This ticket is now very close to be ready for commit. @azaozz and @pbiron are on it.
#41910 – Scheduled maintenance message. This ticket was raised by @paaljoachim. As it is outside the auto-updates feature scope, the best way to move forward on this proposal is to point it out in core devchat.
HelpHub documentation
@audrasjb touched bases with the Docs team last meeting on Monday. @milana_cap is available to review it.
It should be done ahead of the release date so localized versions of HepHub have time to translate it before WordPress 5.5 release. @audrasjb is going to open 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. Trac ticket to follow this task.
Dev notedev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. for WordPress 5.5
@audrasjb proposed the following structure for the dev note:
Introduction
How to hook into the general auto-updates interface
Disable the whole auto-updates UIUIUser interface
Plugins screen (single and multisites)
Themes screen (multisites)
Themes screen (single sites)
Update screen
How to hook into auto-updates email notifications
Success notifications
Failure notifications
Mixed notifications
WP-Cron & plugins/themes auto-updates
Auto-updates Help Tabs
Feel free to comment below or to get in touch in core-auto-updates Slack Channel if you have any suggestion for this dev note.
This proposal seeks to integrate basic, extensibleExtensibleThis is the ability to add additional functionality to the code. Plugins extend the WordPress core software. XML sitemaps functionality into WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
While web crawlers are able to discover pages from links within the site and from other sites, sitemaps supplement this approach by allowing crawlers to quickly and comprehensively identify all URLs included in the sitemap and learn other signals about those URLs using the associated metadata.
Purpose & Goals
Sitemaps help WordPress sites become more discoverable by providing search engines with a map of content that should be indexed. The Sitemaps protocol is a URLURLA specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org inclusion protocol and complements robots.txt, a URL exclusion protocol.
A Sitemap is an XML file that lists the URLs for a site. Sitemaps can optionally include information about each URL: when it was last updated, how often it changes, and how important it is in relation to other URLs of the site. This allows search engines to crawl the site more effectively and to discover every public URL the site has made available.
This core sitemaps feature aims to provide the base required functionality for the Sitemaps protocol for core WordPress objects, then enables developers to extend this functionality with a robust and consistent set of filters. For example, developers can control which object types (posts, taxonomies, authors) or object subtypes (post types, taxonomies) are included, exclude specific entries, or extend sitemaps to add optional fields. See below for the full list.
Project Background
The idea of adding sitemaps to core was originally proposed in June 2019. Since then, development has been ongoing in 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/, and weekly meetings in the #core-sitemaps channel started this year to push development forward. Several versions of the feature plugin have been released on the 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/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 repository, with the latest 0.4.1 representing the state that is considered ready to merge into core. The team is currently working on preparing the final patch to include on the Trac ticket.
Implementation Details
XML Sitemaps will be enabled by default making the following object types indexable:
Homepage
Posts page
Core post types (i.e. pages and posts)
Custom post types
Core taxonomies (i.e. tags and categories)
Custom taxonomies
Author archives
Additionally, the robots.txt file exposed by WordPress will reference the sitemap index.
A crucial feature of the sitemap plugin is the sitemap index. This is the main XML file that contains the listing of all the sitemap pages exposed by a WordPress site. By default, the plugin creates a sitemap index at /wp-sitemap.xml which includes sitemaps for all supported content, separated into groups by type. Each sitemap file contains a maximum of 2,000 URLs per sitemap, when that threshold is reached a new sitemap file is added.
By default, sitemaps are created for all public post types and taxonomies, as well as for author archives. Several filters exist to tweak this behavior, for example to include or exclude certain entries. Also, there are plenty of available hooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. for plugins to integrate with this feature if they want to, or to disable it completely if they wish to roll their own version.
Contributors and Feedback
The following people have contributed to this project in some form or another:
If you update the WordPress settings to discourage search engines from indexing your site, sitemaps will be disabled. Alternatively, use the wp_sitemaps_is_enabledfilterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., or use remove_action( 'init', 'wp_sitemaps_get_server' ); to disable initialization of any sitemap functionality.
How can I disable sitemaps for a certain object type or exclude a certain item?
Does this support lastmod, changefreq, or priority attributes for sitemaps?
By default, no. Those are optional fields in the sitemaps protocol and not typically consumed by search engines. Developers can still add those fields if they want to using the filters referred to above.
lastmod in particular has not been implemented due to the added complexity of calculating the last modified dates for all object types and sitemaps with reasonable performance. For a common website with less frequent updates, lastmod does not offer additional benefits. For sites that are updated very frequently and want to use lastmod, it is recommended to use a plugin to add this functionality.
What about image/video/news sitemaps?
These sitemap extensions were declared a non-goal when the project was initially proposed, and as such are not covered by this feature. In future versions of WordPress, filters and hooks may be added to enable plugins to add such functionality.
Are there any UIUIUser interface controls to exclude posts or pages from sitemaps?
No. User-facing changes were declared a non-goal when the project was initially proposed, since simply omitting a given post from a sitemap is not a guarantee that it won’t get crawled or indexed by search engines. In the spirit of “Decisions, not options”, any logic to exclude posts from sitemaps is better handled by dedicated plugins (i.e. SEO plugins). Plugins that implement a UI for relevant areas can use the new filters to enforce their settings, for example to only query content that has not been flagged with a “noindex” option.
Are there any privacy implications of listing users in sitemaps?
The sitemaps only surface the site’s author archives, and do not include any information that isn’t already publicly available on a site.
Are there any performance implications by adding this feature?
The addition of this feature does not impact regular website visitors, but only users who access the sitemap directly. Benchmarks during development of this feature showed that sitemap generation is generally very fast even for sites with thousands of posts. Thus, no additional caching for sitemaps was put in place.
If you want to optimize the sitemap generation, for example by optimizing queries or even short-circuiting any database queries, use the filters mentioned above.
What about sites with existing sitemap plugins?
Many sites already have a plugin active that implements sitemaps. For most of them, that will no longer be necessary, as the feature in WordPress core suffices. However, there is no harm in keeping them. The core sitemaps feature was built in a robust and easily extensible way. If for some reason two sitemaps are exposed on a website (one by core, one by a plugin), this does not result in any negative consequences for the site’s discoverability.
You must be logged in to post a comment.