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.
In November 2020, I posted about an initiative to update the updaters. It took a bit longer than expected to research the issue and an efficient way to manage the project, but here we are.
Context
The WordPress updaters are a set of PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher classes that assures that users can safely upgrade WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., plugins, themes, and translations.
The ability to manually update WordPress from the adminadmin(and super admin) area, and to install and update plugins and themes, has existed since 2.3 in 2007. Auto-update features were added in WordPress 3.7 (for minor releases), extended in 5.5 (as opt-in for plugins and themes), and 5.6 (major releases). To make the user experience of auto-updates even better, and build trust with users and extenders, it’s important that this mechanism works well and provides all the failsafe checks needed.
The WordPress Core update has proven to be generally reliable, but it doesn’t actually have many tests nor is well documented. There are also some reliability concerns around adding new files and the overall number of changed files, which is the reason WordPress currently tries to keep the number of changed files in minor releases to a minimum.
Plugins and themes updaters are older: in general, all of them can be improved.
Goal
The project goal is to review the existing state of the updaters and propose ways to improve them.
Create a unified JSONJSONJSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. convention for requirements and dependencies.
Outcome 1 – Make sure the zip uploads and unpacking are safe
With the introduction of auto-updates, these processes run more frequently.. So relatively small issues get triggered more often, and with that become a bigger problem. They also now more often run unattended: an auto-update that breaks could lead to quite problematic results.
The goal here is to address most of the known issues related to:
downloading and extracting update packages
copying files and directories
improving documentation for updates
adding some automated tests
making the update process more reliable in general
Related TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
#51823 Native auto updater caused plugin update to fail and disappears plugin from directory (Should be fixed with Rollback Update FailurepluginPluginA 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)
Outcome 2 – Create a mechanism to upgrade and rollback.
When a core auto-update fails, core has long had the ability to automatically attempt a “rollback” to the latest stable release (in the branchbranchA directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". that the site is running). Note: for core auto-updates, “rollback” is not attempted for certain failures (e.g. “disk full”, etc).
This capability should be extended to be available for plugin and theme updates. Work on some of these issues is already undergoing as part the rollback update feature.
If we had a unified process for data migrations in core, WordPress would be able to run the latest available migrationMigrationMoving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. after an update or rollback:
without the need to store anything about the previous state
without requiring anything from the plugin author, apart from adding a “migrations” folder
@afragen has written a lightweight library, wp-dependency-installer, that takes a JSON config file and can install a suggested or required plugin dependency. He mentions this as a lighter-weight solution to something like the TGMPA library. This makes it possible to solve many of the issues above.
How to contribute
Familiarize yourself with the existing classes, listed above.
Update your local WordPress SVN (use svn up) or Git repo (use git pull) to the latest version of WordPress trunktrunkA directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision..
Pick a ticketticketCreated for both bug reports and feature development on the bug tracker. from the above list, review its history, refresh it if needed or make a new 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..
Upload your patch to the Trac ticket you created, and add the keywords has-patch and needs-testing
If during the exploration of the above goals you can think of other enhancements, please create a new ticket and assign it to the Update/Install component
Keeping Discussions Focused
Any discussion about the specifics of a patch itself should happen on Trac. Any discussion about the broader scope of what this feature project is about should take place during the weekly chat in the #core-auto-updateSlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
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;
WordPress 5.6 introduces a new UIUIUser interface to allow website administrators to opt-in to major versions of automatic updates. As noted in a previous dev note, this feature follows the plugins and themes auto-updates user interface, which was shipped in WordPress 5.5. Both are part of the Nine WordPress Core projects for 2019-2020.
The scope of the feature changed during the 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. phase of WordPress 5.6. This 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. cancels and replaces the preceding one.
As announced by Executive Director @chanthaboune (see the related post below), the initial scope of CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. auto-updates has moved to:
Provide some updates to the design of the UI.
For existing installations, the behavior will remain the same as it is today: opted-in to minor updates by default, but a user must opt-in to major updates (constants and filters that are already in use by hosts or agencies will still take precedence).
For new installations, the default behavior will change: opted-in to minor updates by default and opted-in to major updates by default.
For more details about this decision and the roadmap for the next releases, please check the related post on Make/Core:
Major Core auto-updates UI changes in WordPress 5.6
How does it look?
The core auto-updates feature already exists for years in WordPress. WP 5.6 only introduces a new user interface to make it easier to opt-in to automatic updates for major versions.
By default, WordPress auto-updates itself, but only for minor releases. Developers can already opt-in to major releases auto-updates by setting up the existing WP_AUTO_UPDATE_CORE constant to true or by using the allow_major_auto_core_updates existing 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..
With WordPress 5.6, it’s possible for website administrators to opt-in/out to automatic updates for major versions, using a specific interface located on the Updates screen:
When the administrator clicks on the “Enable automatic updates for all new versions of WordPress” link, auto-updates for WordPress Core major versions are enabled:
It’s then possible to opt-out for major versions auto-updates by clicking the “Switch to automatic updates for maintenance and security releases only” link.
How to override the default settings using constants and filters?
This settings section adds some links to allow administrators to opt-in to major core auto-updates. But it also checks for any existing constant or filter and even to see whether the option should be available or not by default and whether it should be set up to enabled or disabled state, using the following order:
By default, auto-updates for major versions are:
Disabled for existing WordPress installations.
Disabled if a 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. system is detected on the WordPress installation.
Enabled for fresh new installations.
If get_site_option( ‘auto_update_core_major’ ) returns true or enabled, auto-updates are enabled. Otherwise, they are disabled. This option is the one stored in the database when the UI is triggered. If this option is set, it overrides the above use cases.
If WP_AUTO_UPDATE_CORE constant returns true, beta, or rc, auto-updates are enabled. If the constant returns false, minor or is not defined, auto-updates are disabled. If this constant is set, it overrides the above parameters.
If allow_major_auto_core_updates filter returns true or enabled, auto-updates are enabled. If the filter returns false or is not used, auto-updates are disabled. If this filter is used, it overrides the above parameters.
To disable auto-updates for major versions by default, developers can set the WP_AUTO_UPDATE_CORE to false (to disable all auto-updates) or minor (to enable only minor core auto-updates, which is the default behavior). It has to be done using the wp-config.php file.
Developers can alternatively use the allow_major_auto_core_updates filter to set up core major versions auto-updates to true or false by default. Example:
In the following screenshot, auto-updates for major versions have been enabled programmatically using a filter or a constant:
In the following screenshot, auto-updates for major versions have been disabled programmatically using a filter or a constant:
How to extend the core auto-updates UI?
There is an action hook running right at the end of this settings section to add some options if needed. Using the after_core_auto_updates_settings action hook, developers can add other settings or texts.
For example, the following snippet adds a link to WordPress documentation about auto-updates.
function my_plugin_after_core_auto_updates_settings( $auto_update_settings ) {
?>
<p class="auto-update-status">
<?php _e( 'For more details about Core auto-updates, see <a href="https://wordpress.org/support/article/configuring-automatic-background-updates/">WordPress documentation</a>', 'my-plugin' ); ?>
</p>
<?php
}
add_action( 'after_core_auto_updates_settings', 'my_plugin_after_core_auto_updates_settings', 10, 1 );
These are the weekly notes for the Updates/Install component meeting that happened on Tuesday November 10, 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.
The meeting was focused on the component’s major project for 5.6: an UIUIUser interface for opting in to core auto-updates. The feature was merged into core at the end of the alpha cycle of WordPress 5.6, when ticketticketCreated for both bug reports and feature development on the bug tracker.#50907 was committed.
As per the post previously published by @chanthaboune on Make/Core, there will be some changes in core auto-updates scope for WordPress 5.6.
Here is our goals for WP 5.6:
Provide some updates to the design of the UI.
For existing installations, the behavior will remain the same as it is today: opted-in to minor updates by default, but a user must opt-in to major updates (constants and filters that are already in use by hosts or agencies will still take precedence).
For new installations, default behavior will change: opted-in to minor updates by default and opted-in to major updates by default.
On Monday 9, @audrasjb opened two tickets/patchs to handle those changes:
#51742: Make sure constants and filters are disabling the major auto-updates option
#51743: Auto-updates for major version is set by default to true for fresh installations
Both tickets can be merged independently. For the moment, ticket #51742 doesn’t address any UI change.
During the last devchat, @helen shared some concerns about the UI overload caused by the changes introduced in #50907. @karmatosed worked on some mockups to simplify the current interface. The intention is to get rid of the auto-updates section and to replace it with an action link when auto-updates are already activated:
After discussing those changes, the team agreed to consider using action links for both enable and disable actions, for better consistency. Indeed, it wouldn’t be great to have a full auto-updates section with a checkbox for enabling the feature, and a simple action link moved to the top of the screen to disable it. Replacing the section with a simple action link could also eases the burden caused by the multiple buttons on this screen.
Next steps until WP 5.6 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. 4 scheduled on Thursday:
Enabling auto-updates by default for fresh installs is a small 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., and it’s ready to be committed in ticket #51743
Taking into account constants/filters was already done in ticket #51743, but not committed yet.
[TODO] UI changes:
@audrasjb to update the patch in ticket #51743 to transform the form/checkbox interface to action links located in the main section on the top of the update-core screen.
@pbiron also raised ticket #50870 and @hellofromtonya provided some feedback after the office hour to help this ticket to move forward. The ticket is now marked as ready for commit.
Hey Core contributorsCore ContributorsCore contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org.! Last week 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/. there was a lively (and lengthy) discussion on the auto-updates UIUIUser interface (transcript). This post summarizes the discussion and most reasonable options for moving forward, considering timing, availability, and level of effort for suggested changes.
Summarized Concerns
Is this implementation aligned with our long term goals: to have auto-updates widely available in order to increase the collective health of all WordPress sites, minimize the maintenance burden for users, and have greater security across the entire ecosystem.
Is this implementation aligned with our short term goals: to continue our existing progress around auto-updates for minor releases, plugins, and themes.
A desire to avoid reverting elements of the UI and auto-updates after the release.
There were a vast array of concerns around the implementation.
Path Forward
One of the clearest things that came up in the conversation during coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. chat is that this is a complex technical task, and there will be a need for some long term, dedicated time to keep driving this work forward. Specifically, there is a shared concern that there is a technically non-trivial combination of reassurance and repair features that need to be defined and executed on and will need a dedicated product owner (transcript).
This Release and Next
WP5.6: Provide some updates to the design of the UI.
WP5.6: For existing installations, the behavior will remain the same as it is today: opted-in to minor updates by default, but a user must opt-in to major updates (constants and filters that are already in use by hosts or agencies will still take precedence).
WP5.6: For new installations, default behavior will change: opted-in to minor updates by default and opted-in to major updates by default.
WP5.x: In a future release, have a renewal flow after a certain period of time.
Planning for the Future
The subject of auto-updates has resulted in many complicated discussions. As I reminded the release squad, decisions like these require us to remember that we’re contributing to over 30% of the web, and we have to balance our immediate needs with long term planning.
It’s important that whatever we implement isn’t taking us further away from our long term goals of having seamless, auto-updates across the project. Auto-updates can help us have a more secure WordPress ecosystem, and in turn can help change the public perception of WordPress being an unsecure choice for users of any skill level.
To provide some clarification on the nine project goals set out in 2019, the wording there is specific about implementing “opt-in to automatic updates of major Core releases”. However, the long term goal (for Matt as well as many of the contributors to WP3.7) was to have all installations opted-in to auto-updates of WordPress core by default, and that is still the long term goal.
Props to the WordPress 5.6 release squad for bringing such care to this discussion, and to @helen for helping me on the implementation wording. Special thanks to @audrasjb and @davidbaumwald for editing, and @andreamiddleton, @daisyo, and @cbringmann for proofreading!
During the November 4th core chat, some questions were raised about the readiness of the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. auto-update feature, scheduled to land in WordPress 5.6. Questions ranged from the implementation of it to the scope of the output desired. A separate post is coming with more information on that discussion and the planned next steps.
In order to allow some more time to refine the work done so far, WordPress 5.6 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. 4 will be delayed from today, November 10th, to Thursday, November 12th, 2020.
At this moment, no delay is expected on the release: everyone is working to make WordPress 5.6 available on December 8th.
Thank you to @francina who helped me craft this draft. 🙂
Update: this 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. is no longer relevant as the scope of the feature changed during WordPress 5.6 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. cycle. Please read the new dev note published for this feature:
WordPress 5.6 introduces a new UIUIUser interface to allow website administrators to opt-in to major versions automatic updates.
This feature follows plugins and themes auto-updates user interface which was shipped in WordPress 5.5. Both are part of the 9 WordPress Core projects for 2019-2020.
For reference, see ticketticketCreated for both bug reports and feature development on the bug tracker.#50907.
How does it look?
The coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. auto-updates feature already exists for years in WordPress. WP 5.6 only introduces a new user interface to make it easier to opt-in to automatic updates for major versions.
By default, WordPress auto-updates itself, but only for minor releases. Developers can already opt-in to major releases auto-updates by setting up the existing WP_AUTO_UPDATE_CORE constant to true or by using the allow_major_auto_core_updates existing 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..
With WordPress 5.6, it’s possible for website administrators to opt-in/out to automatic updates for major versions, using a specific interface located on the Updates screen:
Core Major Versions auto-updates user interface in WordPress 5.6
How does it work?
This settings section basically adds a checkbox to allow administrators to opt-in to major core auto-updates. But it also checks for any existing constant or filter to see if the checkbox should be checked or not by default, using the following order:
By default, the checkbox is unchecked.
If get_site_option( 'auto_update_core_major' ) returns true, the checkbox is checked. Otherwise it’s unchecked. This option is the one stored in the database when the checkbox value is changed.
If WP_AUTO_UPDATE_CORE constant returns true, beta or rc, the checkbox is checked. If the constant returns false, minor or is not defined, the checkbox is unchecked. If this constant is set, it overrides the above parameters.
If allow_major_auto_core_updates filter returns true, the checkbox is checked. If the filter returns false or is not used, the checkbox is unchecked. If this filter is used, it overrides the above parameters.
To disable the checkbox by default, developers can set the WP_AUTO_UPDATE_CORE to false (to disable all auto-updates) or minor (to enable only minor core auto-updates, which is the default behavior). It has to be done using the wp-config.php file.
Developers can alternatively use the allow_major_auto_core_updates filter to set up core major versions auto-updates to true or false by default. Example:
How to extend core major versions auto-updates feature?
The feature also checks for dev (development versions of WordPress) and for minor updates. There is an action hook running right before the submit button of that settings section to add some options if needed. Using the after_core_auto_updates_settings_fields action hook, developers can add other settings or texts.
For example, the following snippet adds an option to opt-in/out for minor releases auto-updates:
These are the weekly notes for the Updates/Install component meeting that happened on Tuesday October 13, 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.
The meeting was focused on the component’s major project for 5.6: an UIUIUser interface for opting in to core auto-updates: #50907.
@audrasjb sent a first 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 feature and shared a screenshot of the first workaround:
This approach adds two checkboxes, to provide the ability to enable/disable auto-updates for both minor and major auto-updates.
@pbiron pointed out that disabling auto-updates for minor releases was already discussed during previous meetings, and the decision is that it is not an option the Core team wants to provide to end-users. It needs to be disabled by 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 or by using the existing 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. or PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher constants. @audrasjb will update his patch accordingly, so there will be only one available option: opt-in for major releases auto-update.
@estelaris added that there is already 4 buttons on this screen. It would be nice to avoid adding a new one. She added that we should use a toggle button instead of a checkbox + a submit button. @audrasjb answered that there is no existing toggle component in WordPress Core for now. This eventual new component also would need to be designed, developed, and its 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) would need to be tested and reviewed. It doesn’t look realistic for WP 5.6 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. 1.
@paaljoachim proposed to move the auto-updates opt-in to General Settings. @pbiron and @audrasjb are not enthusiastic about this proposal as for now, the Updates screen seems to be the more natural place to find Core auto-updates settings.
@karmatosed pointed out that this screen is already a very dense interface. She will share some alternative designs this week on this Figma file, to help design decisions. @audrasjb will work on the patch implementation at the end of the week.
For beta 1, the team agreed that a robust technical implementation is needed, so we have a UI basis for this new feature. Then, the team will focus on phrasing and on polishing the interface elements.
@estelaris asked for documentation about plugins and themes auto-updates. The team shared all the existing documentation:
Technical documentation (WordPress 5.5 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.):
These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday August 18, 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.
During this meeting, the core-auto-updates team looked at the tickets currently milestoned to the next minor (5.5.1) and major (5.6) versions of WordPress.
#50280: Enable auto-updates shows for plugins with no support (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 Themes screen)
@pbiron is working on this ticketticketCreated for both bug reports and feature development on the bug tracker..
#50988: Provide option to disable emails about auto-updates
As commented by @johnbillion, “We don’t want to discourage users from using the auto-updates feature for plugins and themes just because the emails are annoying”. The team discussed several options to fix the issue:
Leave it as it is currently.
Add a new interface item to disable emails: not realistic for 5.5.1 and maybe not suitable even for the next major, as per the “Decision not option” WordPress rule.
Send only weekly digests emails: not the best option as a digest potentially a week later a failed update is not useful. If users want to receive email notifications, they want to receive it right after the update occured.
Email only when an update failed: a successful update doesn’t ensure users that nothing was broken by 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/theme.
Reduce the auto update frequency to once a week: it will need to be able to distinguish major and minor updates, and also security updates. Not realistic for 5.5.1.
A core plugin maintained by the WP team for tweaking these emails specifically: the team agreed this is something to consider, eventually before 5.5.1. @pbiron, @audrasjb and @ronalfy expressed interest to work on this solution.
Don’t send emails for 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. releases (x.x.1 bumps): the problem is that plugin authors don’t massively use proper versioning.
Add more complete filters so plugin authors can manage email notification better if they know what plugin/theme failed to update: this is the chosen option for 5.5.1. @audrasjb added a patch for this in ticket #50988.
#50875: Introduce a wrapper for the ‘auto_update_{$type}’ 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. checks
This small enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. is milestoned for WP 5.6. Needs patch.
#50848: Clarify the usage of null for “auto_update_{$type}” filter
Milestoned to WP 5.5.1. @audrasjb added a patch in the ticket.
#50907: Add a method to opt-in to core auto-updates
This ticket was opened to handle Core auto-updates which is one of the key projects for WordPress 5.6.
Edit 8/05/2020: An error in the example of populating no_updates for plugins has been corrected: in site_transient_update_plugins the value of response and no_update are arrays of objects; whereas in site_transient_update_themes, they are arrays of arrays. props @afragen. @pbiron
By default, the enable and disable auto-updates action links for plugins (detailed in the previous developer note) will only appear when the WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Updates 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. (available since version 3.7.0) is supported.
Plugins and themes that are hosted elsewhere (such as premium or “private” plugins) can also support the Updates API with a little bit of code.
Though there is currently no one “official” way for such plugins to support the Updates API, this note offers recommendations for how developers can provide enough support for the auto-updates UIUIUser interface to work for their plugins.
Filtering 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 update transient
The responses received from querying 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/ Updates API are stored in the update_plugins site transient. There are several existing filters that developers can use to add information about the availability or lack of available updates for a specific plugin that is not hosted in the WordPress Plugin Directory to that transient. The most common are:
Using pre_set_site_transient_update_plugins, for example, developers can do:
<?php
function myplugin_pre_set_site_transient_update_plugins( $transient ) {
// Query premium/private repo for updates.
$update = myplugin_check_for_updates( 'my-plugin' );
if ( $update ) {
// Update is available.
// $update should be an array containing all of the fields in $item below.
$transient->response['my-plugin/my-plugin.php'] = $update;
} else {
// No update is available.
$item = (object) array(
'id' => 'my-plugin/my-plugin.php',
'slug' => 'my-plugin',
'plugin' => 'my-plugin/my-plugin.php',
'new_version' => $myplugin_current_version,
'url' => '',
'package' => '',
'icons' => array(),
'banners' => array(),
'banners_rtl' => array(),
'tested' => '',
'requires_php' => '',
'compatibility' => new stdClass(),
);
// Adding the "mock" item to the `no_update` property is required
// for the enable/disable auto-updates links to correctly appear in UI.
$transient->no_update['my-plugin/my-plugin.php'] = $item;
}
return $transient;
}
add_filter( 'pre_set_site_transient_update_plugins', 'myplugin_pre_set_site_transient_update_plugins' );
Developers that have already been using the Updates API to offer updates for their plugins that are not hosted in the WordPress Plugins Directory have already been populating the response property for their plugin.
The no_update property is a requirement for the auto-update UI to work correctly for externally hosted plugins.
Some are already populating the no_update for their plugin. Any that are not should update their code accordingly for the best user experience.
Filtering the theme update transient
For themes, the responses received from querying the WordPress.org Updates API are stored in the update_themes site transient. The filters used to modify the values of these transients are similar to the ones used for plugins but slightly different:
Using pre_set_site_transient_update_themes, for example, developers of a theme hosted in a different location can do:
<?php
function mytheme_pre_set_site_transient_update_themes( $transient ) {
// Query premium/private repo for updates.
$update = mytheme_check_for_updates( 'my-theme' );
if ( $update ) {
// Update is available.
// $update should be an array containing all of the fields in $item below.
$transient->response['my-theme'] = $update;
} else {
// No update is available.
$item = array(
'theme' => 'my-theme',
'new_version' => $mytheme_current_version,
'url' => '',
'package' => '',
'requires' => '',
'requires_php' => '',
);
// Adding the "mock" item to the `no_update` property is required
// for the enable/disable auto-updates links to correctly appear in UI.
$transient->no_update['my-theme'] = $item;
}
return $transient;
}
add_filter( 'pre_set_site_transient_update_themes', 'mytheme_pre_set_site_transient_update_themes' );
The no_update property was only recently added to API responses for theme update queries, and like plugins, the no_update property is a requirement for the auto-update UI to work correctly for externally hosted themes.
You must be logged in to post a comment.