Upgrade/Install Component meeting summary – February 9, 2021

These are the weekly notes for the Updates/Install component meeting that happened on Tuesday February 9, 2020. You can read the full transcript on the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-auto-updates SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.

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

Contribute to the Rollback Failure Update feature plugin

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

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

Quick recap of the feature plugin goals

This is a feature plugin based on the Pull Request proposed in the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #51857. The assumption is that most of the errors in large plugins/themes occur during the copy_dir() part of WP_Upgrader::install_package(). Trac ticket #52342 brought more error reporting to copy_dir() and Trac ticket #52831 provides a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. hook in order to do the actual rollback in the event of a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/theme update failure. As of WordPress 5.7-beta1 both of these tickets are in core.

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

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

Next steps

  • The Upgrade/Install team will publish a Feature Plugin proposal on Make/Core;
  • The feature plugin will be released on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ plugins repository;
  • A MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. ticket will be opened on the Meta Trac in order to ask the meta team to create a new GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ project in the WordPress.org GitHub account. @afragen will lead this projet on the WordPress GitHub account;
  • Provide visibility to the feature plugin;
  • Test, learn, iterate.

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

Core major versions auto-updates UI changes in WordPress 5.6 – Correction

WordPress 5.6 introduces a new UIUI User 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 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. phase of WordPress 5.6. This dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change 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 CoreCore Core 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 filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output..

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:

  1. By default, auto-updates for major versions are:
    • Disabled for existing WordPress installations.
    • Disabled if a version controlversion control A version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories. system is detected on the WordPress installation.
    • Enabled for fresh new installations.
  2. 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.
  3. If WP_AUTO_UPDATE_CORE constant returns truebeta, or rc, auto-updates are enabled. If the constant returns falseminor or is not defined, auto-updates are disabled. If this constant is set, it overrides the above parameters.
  4. 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:

add_filter( 'allow_major_auto_core_updates', '__return_false' );

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 );

Props @cbringmann, @planningwrite and @poena for proof-reading.

#5-6, #auto-updates, #core-auto-updates, #dev-notes, #feature-autoupdates

Upgrade/Install Component meeting summary – November 10, 2020

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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-auto-updates SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.

The meeting was focused on the component’s major project for 5.6: an UIUI User 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 ticketticket Created 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 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 4 scheduled on Thursday:

  • Enabling auto-updates by default for fresh installs is a small patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., 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.
    • @helen and @karmatosed to iterate on the design/copy.

@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.

#auto-updates, #core-auto-updates, #upgrade-install

WP5.6 | Auto-Update Implementation Change

Hey Core contributorsCore Contributors Core 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 SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. there was a lively (and lengthy) discussion on the auto-updates UIUI User 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 coreCore Core 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.6.1: Revisit the UI to revise based on feedback.
  • WP5.7Add a nudge on the Site Health screen for anyone opted out of major updates.
  • WP5.7Add auto-updates opt-in to installation flow.

Future Release Suggestions

  1. WP5.x: Add a nudge to opt-in on the updates page and a path to opt-out on Site Health.
  2. 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!

#5-6, #auto-updates

WordPress 5.6 Beta 4 delayed from November 10th to November 12th, 2020

During the November 4th core chat, some questions were raised about the readiness of the CoreCore Core 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 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 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. 🙂

#5-6, #auto-updates, #core-auto-updates

Introducing auto-updates interface for Core major versions in WordPress 5.6

Update: this dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change 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 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. cycle. Please read the new dev note published for this feature:

WordPress 5.6 introduces a new UIUI User 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 ticketticket Created for both bug reports and feature development on the bug tracker. #50907.

How does it look?

The coreCore Core 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 filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output..

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:

  1. By default, the checkbox is unchecked.
  2. 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.
  3. 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.
  4. 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:

add_filter( 'allow_major_auto_core_updates', '_return_false' );

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:

function my_plugin_after_core_auto_updates_settings_fields( $auto_update_settings ) {
	if ( isset( $_POST['core-auto-updates-settings'] ) && wp_verify_nonce( $_POST['set_core_auto_updates_settings'], 'core-auto-updates-nonce' ) ) {
		if ( isset( $_POST['my-plugin-core-auto-updates-minor'] ) && 1 === (int) $_POST['my-plugin-core-auto-updates-minor'] ) {
			update_site_option( 'my_plugin_auto_update_core_minor', 1 );
		} else {
			update_site_option( 'my_plugin_auto_update_core_minor', 0 );
		}
	}
	$minor_auto_updates_settings = get_site_option( 'my_plugin_auto_update_core_minor' );
	?>
	<p>
		<input type="checkbox" name="my-plugin-core-auto-updates-minor" id="my-plugin-core-auto-updates-minor" value="1" <?php checked( $minor_auto_updates_settings, 1 ); ?> />
		<label for="my-plugin-core-auto-updates-minor">
			<?php _e( 'Automatically keep this site up-to-date with minor updates.', 'my-plugin' ); ?>
		</label>
	</p>
	<?php
}
add_action( 'after_core_auto_updates_settings_fields', 'my_plugin_after_core_auto_updates_settings_fields', 10, 1 );

This snippet adds a new option right after the major releases option:

Props @sarahricker and @jeffmatson for proofreading this dev note.

#5-6, #auto-updates, #core-auto-updates, #dev-notes

Upgrade/Install Component meeting summary – October 13, 2020

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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-auto-updates SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.

The meeting was focused on the component’s major project for 5.6: an UIUI User interface for opting in to core auto-updates: #50907.

@audrasjb sent a first patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or by using the existing hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. or PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 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 accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) would need to be tested and reviewed. It doesn’t look realistic for WP 5.6 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 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:

#auto-updates, #core-auto-updates, #upgrade-install

Core auto-updates meeting summary – August 18, 2020

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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-auto-updates SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.

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 (Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site Themes screen)

@pbiron is working on this ticketticket Created 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/theme.
  • 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 patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. 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}’ filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. checks

This small enhancementenhancement Enhancements 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.

#auto-updates, #core-auto-updates, #feature-autoupdates

Recommended usage of the Updates API to support the auto-updates UI for Plugins and Themes in WordPress 5.5

This is an addendum to Controlling Plugin and Theme auto-updates UI in WordPress 5.5.

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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Updates APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. (available since version 3.7.0) is supported.

All plugins that are hosted in the WordPress Plugin Directory and themes that are hosted in the WordPress Theme Directory already fully support the Updates API and require no changes.

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 UIUI User interface to work for their plugins.

Filtering the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party update transient

The responses received from querying the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ 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.

Props @desrosj and @audrasjb for review prior to publishing.

#5-5, #auto-update, #auto-updates, #dev-notes, #feature-autoupdates

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

Next meeting is scheduled on Tuesday July 28, 2020 at 17:00 UTC and will take place on #core-auto-updates SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel with the following agenda:

  • Progress report on Docs
    • HelpHub end-user documentation
    • Dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.
    • About page/communication
  • Remaining tickets:

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

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