Dev Chat summary – February 5, 2020 (5.4 week 4)

The chat was facilitated by @davidbaumwald on this agenda.

Full meeting transcript on Slack

This devchat marked week 4 of the 5.4 release cycle.

Highlighted posts

Upcoming Releases – 5.4

We are currently in week 4 since WordPress 5.4 kick-off.

Further informations:

@audrasjb pointed out that it would be good to add more 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. scrubs to help ticketticket Created for both bug reports and feature development on the bug tracker. triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. and punting when necessary, to help contributors to focus on tickets that are realistically going to land in 5.4.

In addition to the scrub he scheduled for early Friday morning and Monday, @davidbaumwald will host another on Sunday.

Reminder: 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 is the deadline for Feature Requestfeature request A feature request should generally begin the process in the ideas forum, on a mailing list, as a plugin, or brought to the attention of the core team, such as through scope meetings held for each major release. Unsolicited tickets of this variety are typically, therefore, discouraged. and Enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. type tickets. The full list of such tickets can be found with this Trac query.

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

@noisysocks noted that including this block in the release could generate confusion for end users, as it will appear as a standalone block without any of the accompanying features (Full Site Editing and a new nav-menu.php page) that will make this block actually useful. He felts unsure if we want to remove this block from the 5.4 scope or not.

@jorgefilipecosta agreed with the concerns being raised by Robert. He said he was operating under the assumption that the navigation block needed to be part of 5.4. But from his side, he think we can change that assumption. He also think the navigation block by itself without Full Site Editing is not very useful for most users.

Note: the Navigation Block was officially removed from the release scope two days after the dev chat.

Plugins & Themes Automatic Updates

For reference, see the two related TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets: #48850 and #49199.

@audrasjb updated the current work on the related tickets:

  • Technical aspects of the feature still need a lot of review from deeply experimented coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers
  • Design changes need to be validated by the design team

According to @audrasjb, there is a quite solid basis, but the Core team still needs to take some decisions about this feature, as we are approaching beta 1.

@desrosj made a deep review of the technical changes, and shared his concerns about the feature and also an alternative 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..

@mapk, @karmatosed and @audrasjb iterated on the user experience and their work is close to be finalized.

Email notifications are handled by @desrosj and will need copy review. @marybaum is available to help on that side.

The release Team will take the final decision about implementing automatic updates for Plugins & Themes in WordPress 5.4 before Beta 1 is released, and will publish a post on Make/Core to announce their progress on this specific topic.

#5-4, #auto-update, #gutenberg

Follow-up Discussion on Major Auto Updates

Last week’s proposal to automatically upgrade old sites to 4.7 has garnered a lot of feedback, which has been very helpful in refining the idea and getting a sense of how different parts of the community feel about it.

To follow up on that, I’d like to have a meeting in #core on Tuesday, August 20, 2019, 2100 UTC to continue the discussion. No decisions will be made during the meeting, but I hope that we can have a productive conversation and move closer to some kind of resolution.

To join the meeting, you’ll need an account on the Making WordPress Slack. If you’re not able to attend, but would like to give feedback, please leave a comment on the proposal.

#auto-update, #security

Dev Chat Summary: August 14

After the close of our every-two-weeks new contributor chat, the weekly coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. chat started at 2000 UTC, give or take a few minutes. (backscroll)


Next Minor: 5.2.3

Next Major: 5.3

  • All but two focus lead type people are settled. An update post is upcoming (and will be shared by the end of the week regardless of whether those final two are settled or not).

Open Floor

To Do List from this Chat

  • First 5.2.3 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 Thursday, August 15 @ 1700 UTC
  • If you want to help with the 5.2.3 minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. and weren’t mentioned above, you can indicate your interest in the comments of this post.

#summary #5-2-3 #5-3 #rest-api #auto-update

Proposal: Auto-Update Old Versions to 4.7

Foreword: To help anchor some of the main concerns from the comments, I’d like to highlight a few important points in this post. – Josepha

  • This post contains a careful roll out plan. This would not be be a sudden and un-communicated change.
  • There will be options for site admins to opt-out of the update with clear instructions starting 30 days prior.
  • This would apply to small segments of each version sequentially, not all at once. This helps us check the updates in batches and limit the risk of breaking sites irrevocably.

Based on the ideas in last week’s discussion, I’d like to propose a new policy regarding backporting security fixes to old versions, and a plan to implement it.


Note: This has been edited since it was published, to incorporate feedback from the comments.

Apply security updates to the latest 6 versions, and slowly auto-update insecure sites to the oldest secure version.

That would mean that the currently secured versions would be 4.7 - 5.2, and the 3.7 - 4.6 branches would eventually be auto-updated to 4.7.

In practice, that’d provide roughly 2 years of security fixes for each branchbranch A 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"., and roughly 10% of current sites would eventually be auto-updated to 4.7. Security fixes would not be guaranteed for any specific length of time, though. Once 5.3 is released, 4.8 would become the oldest secured version.

A set number of versions creates a consistent limit on the amount of work required to 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. security fixes. Auto-updating insecure versions allows us to continue protecting older sites, rather than seeing them fall into the hands of spammers and criminals.

Implementation Plan

Auto-updating major versions is already a relatively safe process, because of WordPress’ commitment to backwards-compatibility, and the robust safety checks and rollback feature included in the auto-update system. However, this should still be done cautiously, to avoid breaking any sites.

A small subset of sites would be tested first, so that any problems can be identified and corrected before the majority of sites are updated. Sites would be updated one version at a time, to minimize the number of things that could go wrong.

Auto-updates of old branches would be done at a different time than new releases, to avoid a situation where there could be multiple problems to troubleshoot at once.

The process for auto-updating insecure versions would look like this:

Note: This has been edited since it was published, to incorporate feedback from the comments.

  1. Publish a post on, to inform the wider world about the upcoming updates as far in advance as possible. A specific date for updates will not be known at this point, but it will be at least 6 weeks in the future.
  2. Release 3.7.30 - 4.6.15, which will:
    1. Allow admins to opt-out of major auto updates by clicking a simple button.
    2. Email all site admins/editors to ask them to upgrade to the latest version, and inform them that their site will be auto-updated to 3.8 in the near future if they don’t opt-out. It will link to some documentation with more details, and include a link that they can click to opt-out. They’ll be warned about the security implications of opting-out. Editors won’t be able to directly install the update, but they can reach out to admins who can.
    3. Add an adminadmin (and super admin) notice within wp-admin, containing similar information as the email. The notice will be visible to all site users.
    4. If users opt out, they will no longer get the emails asking them to update, but will continue seeing the wp-admin notices.
  3. Test auto-updating 3.7 to 3.8 against test sites, and make any necessary improvements to the auto-update system.
    1. One necessary modification would be to email the site owner if the auto-update fails and is rolled back to 3.7. The email should be a strongly-worded warning, letting them know that their site could not be upgraded to a secure version, and that they should manually update immediately. If they don’t update, it’s almost guaranteed that their site will be hackedhacked eventually.
    2. Similarly, if the auto-update fails and the user is stuck on an insecure version, an admin notice should be displayed in wp-admin with a warning similar to the email above. This would replace the pre-release banner from 3.7.30 described above.
    3. We could potentially look into ways to make an educated guess about the chance of an undetectable error, and abort the update on those sites, to minimize the risk of breaking something. For example, if a known incompatible 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 Plugin Directory or can be cost-based plugin from a third-party is installed. In those cases, we’d want to send the admin the same warning email & admin notice, letting them know that they’re stuck on an insecure version, and need to manually update immediately.
  4. Update the Core handbook with details on the new process, so that everyone knows how to deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. major auto-updates.
  5. Publish a document on 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. explicitly stating a support policy, to avoid confusion.
    1. Only the latest major version is officially supported and guaranteed to receive security updates.
    2. There are no LTS releases, and all releases older than the current release are EOL.
    3. We make an effort to backport security fixes to the previous 5 major releases, but no guarantee is made, as sometimes it is not feasible or practical.
    4. Everyone is strongly recommended to always run the latest major version.
  6. T-30 days: Release 3.7.31, which will:
    1. Send all site admins and editors a 2nd email, similar to the 1st, letting them know that their site will be auto-updated to 3.8 in 30-45 days, and include instructions to opt-out, etc.
    2. Update the 3.7.30 wp-admin notice to include the date range of the impending update.
    3. Include any necessary improvements to the auto-update system, as described in step 3.
  7. Deploy the auto-updates in phases:
    1. The general process would be to deploy to a subset of 3.7 sites, then wait 1 week to see if any issues are reported. If anything unexpected happens, the process can be paused in order to fix those issues, and then restarted.
    2. T-0 days: Deploy to 2% of 3.7 sites, selected randomly to get a representative sample.
    3. T+7 days: Deploy to another 18%.
    4. T+14 days: Deploy to the remaining 80%.
  8. If all goes well, the process can be repeated to update 3.8 sites to 3.9, and so on until all sites are running 4.7. Some of the steps can be automated to make the process easier in the future.


  • Overall, would you like to move forward with the general approach of this policy/plan?
  • Would you make any tweaks to improve it?

Update: The policy and implementation plan have been updated to clarify some miscommunications that were revealed in the comments:

CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s official policy has always been to only support the latest version, and this proposal does not intend to change that. It only means to impact the number of versions that we backport to, and to start auto-updating very old versions to a more recent version.

This is consistent with — and moving towards — the Core team’s pre-existing long-term plan of getting to the point where all WordPress sites are running the latest version automatically and transparently, similar to how Chrome and other modern software work.

Older versions are not guaranteed to receive all security updates, since that is not always possible. The versions that receive updates would not be considered LTS versions; they would only receive the security updates that are feasible to backport. Everyone should always run the latest version.

This proposal is not intended to become permanent. It seems like a prudent action for the current situation, but like everything else, it should be re-evaluated in the future, as the situation changes.

#auto-update, #security