Dev Chat meeting Summary – March 31, 2021

This is the weekly meetings summary of the WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team. The facilitator for this week’s chats was @markparnell at 05:00 UTC and @francina at 20:00 UTC. Here is the meeting agenda.

Link to 05:00 UTC devchat meeting on the core channel on Slack

Link to 20:00 UTC devchat meeting on the core channel on Slack

Announcements & News

Upcoming releases

WordPress 5.7.1

In line with the trial for consistent minor release leads for each major branch, all the 5.7.x point releases will be led by @peterwilsoncc, with @audrasjb as deputy.

Here is the expected 5.7.1 release schedule:

  • Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).: Wednesday 7 April, 2021 around 23:00 UTC
  • Final release: Wednesday 14 April, 2021 around 23:00 UTC

There are 33 tickets in the milestone:

  • 10 are already closed as fixed
  • 3 are fixed and reopened for proper backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch.

@audrasjb announced a new bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrub right after the devchat, and will run another one on Tuesday April 6, 2021 at 20:00 UTC.

Note: At the time this meeting recap is published, there are now 31 tickets in the milestone. 12 are fixed, 4 are reopened. The ticketticket Created for both bug reports and feature development on the bug tracker. with the higher priority was fixed (#52822).

Please note that this WordPress 5.7 board is the one to watch for GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ updates that will need to land in this release.

WordPress 5.8

@francina shared some blogposts worth reading, where a new, experimental, release cycle is proposed, and the early bug scrubs schedule is now available.

Core related blogblog (versus network, site) posts

Some thoughts were shared about the last item (Add a testing template to TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.). People are invited to comment in the blog post.

@francina suggested to follow make.wordpress.org/updates as this blog has updates from Make teams + project leadership.

Component maintainers updates

Build/Test Tools (@sergeybiryukov): Work has continued on backporting recent build and test tool improvements to the older branches still receiving security updates. See ticket #52653 for more details.

Date/Time (@sergeybiryukov): No major news this week.

General (@sergeybiryukov): No major news this week.

Internationalization (@sergeybiryukov): No major news this week.

Permalinks (@sergeybiryukov): No major news this week.

Menus (@audrasjb): JB did some Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. last week.

Widgets (@audrasjb): no major news this week.

Upgrade/Install (@audrasjb / @afragen): The team is still looking for feedback concerning the feature plugin. @francina asked if it would be useful to organize a test scrub. I would be a nice idea, and @afragen answered there’s a simple way to force the rollback for testing. The Upgrade/Install team will discuss this during the next #core-auto-updates weekly meeting on Tuesday April 6, 2021 at 18:00 UTC.

Toolbar (@sabernhardt): no triage planned this week, but @sabernhardt will probably will have another session in a few weeks.

Open floor

@chanthaboune noted that there are listening hours next week with her and Matt.

@annezazu dropped in a call out to help with the latest call for testing for the Full Site Editing Outreach Experiment: FSE Program Testing 4 – Building a restaurant themed header.

@chanthaboune shared that the recent Slack outage caused some additional things to break, so if folks see things that usually work but aren’t now, please feel free to let her know.

#5-7-1, #5-8, #dev-chat, #summary

Upgrade/Install Component meeting summary – February 9, 2021

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

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

Contribute to the Rollback Failure Update feature plugin

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

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

Quick recap of the feature plugin goals

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

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

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

Next steps

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

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

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, 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 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

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, 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 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

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, 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.
    • 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

Dev Chat Summary, July 15th, 2020

@whyisjake hosted this agenda and @audrasjb edited.

Highlighted Blogblog (versus network, site) Posts

  • The wp-notify Next Steps project is looking for feedback on initial requirements and wanting to kick-off the project
  • GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ team published “What’s new in Gutenberg” last week

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, 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 were not discussed but referenced for people to review at their own time:

Upcoming Releases

  • WordPress 5.5 is slated for release August 11th, 2020
    • @marybaum added that the “About” page has a draft layout on Figma two weeks before RC1. Might change but it is now there. The best way to provide feedback on the “About” page copy is to enter it in the comments section on the ticketticket Created for both bug reports and feature development on the bug tracker. #50416
    • @abhanonstopnewsuk said they are also working on FAQs and would appreciate input on these (they have been messaging them).
  • 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. 2 was released yesterday
    • Since Beta 1, over 40 tickets plus Gutenberg have been closed, however there are still a bunch to go through.
  • Gutenberg bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes for Beta releases
    • @nrqsnchz said #core-accessibility would like some clarification around how Gutenberg bug fixes that need to make it through to betas should be handled and the process around it.
    • @whyisjake said when changes are needed in Gutenberg there is a “Back to WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) that is applied. These are bundled into a release like this: #23905 Backport more fixes to WordPress 5.5 beta2. Additional docs are also available: docs/contributor/release docs
    • @youknowriad confirmed that when an issue is created, they triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. issues and if it’s considered as an issue that needs to be fixed in the next Beta/RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta)., it gets added to the “WordPress 5.5 Must Have” project. “They” being anyone with triage permissions on the repository.
    • @afercia is not sure opening issues on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ has the same effect of ensuring the highest visibility. He is uncomfortable with the process and doesn’t think it is equivalent to the way it works on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..
    • @desrosj challenged this:
      • In Trac, anyone with bug gardener capabilities is trusted to appropriately milestone issues using good judgement.
      • On GitHub, anyone with triage permissions is trusted to milestone and tag issues appropriately using good judgement.
      • The only difference is that GitHub issues and PRs are not filtered through 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/., and there is an additional step of importing changes made on GitHub into trunktrunk A 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.. Release and project leads always have the final say if there are unreasonable disagreements about what should/should not be fixed (or should/should not make it into beta)
    • @afercia highlighted that its the composition of the triage teams with deep disagreements between the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team and the Editor team.
    • @desrosj asked if deeper discussions were needed about specific issues as nothing has been escalated and it is each team’s responsibility to communicate with each other.
    • in the interest of moving the agenda forward, it was agreed that this discussion would continue after the dev-chat.
  • Beta 3 is coming next Tuesday July 21st, 2020. Bug Scrub #6 is tomorrow July 16th, 2020.

Component check-in and status updates

  • @azaozz mentioned Updating jQuery version shipped with WordPress. There is a Trac ticket #50668: jquery-migrate.js in latest beta version 5.5 gone? asking the same questions.
  • @marybaum gave a shoutout to @estelaris @abhanonstopnewsuk @yvettesonneveld and @ryelle for the work they’ve done with great guidance from @melchoyce
  • @audrasjb #core-auto-updates team is going to publish the first 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, 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 this feature.
    • It introduces the new functions and 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. and can be used to control auto-updates-UIUI User interface.
    • There will be another one to handle Site Health and email notifications.
    • They are also going to start work on the HelpHub Docs page (end user documentation)

Open Floor

  • @pbiron has a potential proposal related to dev-notes. Dev notes are rightly targeted at developers however there are often changes in the WP adminadmin (and super admin) that users need to be made aware of. Would it be more appropriate to have a new user-note where a “heads-up” about these changes can be made?
    • @joyously thought it should go in the Field GuideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page.. @azaozz said seconded it. Make WordPress Core it seems to slowly shift towards a wider audience now, not just developers
    • @desrosj said the Field Guide is a collection of dev notes. It is still developer focused and he think it should be in HelpHub. @audrasjb seconded the use of HelpHub for end user documentation but suggested that maybe we publish a recap of all new HelpHub pages on w.org/news. @desrosj said the HelpHub could also be. more work needed
    • @sergeybiryukov mentioned that there is also a pointers 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. in the admin for new features but he doesn’t think its been used in recent releases.
    • @audrasjb seconded the use of HelpHub for end user documentation but has no blog to follow the news. He suggested that maybe we publish a recap of all new HelpHub pages on w.org/news. @desrosj said the HelpHub could also be linked to in the release post (provided it is published and ready on release day). @pbiron questioned whether it was appropriate to publish things in HelpHub before a release (like dev notes are).
    • @azaozz suggested maybe having a new/separate place for user targeted “what’s up and coming”
    • @pbiron will source some examples where user-focused things were coered in dev notes and present a proposal at the next weeklly dev-chat
    • @marybaum @yvettesonneveld @abhanonstopnewsuk think using wp.org/news is a good way to drum up excitement about new releases and aligns with the goal to use /news to connect with a wider audience and meetups.
  • @collinsmbaka is working on the embed blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. documentation and would like someone to look at the following issues:
  • @whyisjake asked him to share it in #core-editor and cc @youknowriad and @ella