Call for volunteers: Release Model Working Group

The topic of the release cadence has been brought up multiple times over the past year:

  1. The original post about Major and Minor Version Release Cadence – February 27, 2019
  2. Recap of Devchat after the hour: November 20 – November 20, 2019
  3. Tentative Release Calendar 2020-2021 – November 21, 2019

There seems to be a strong will to increase the number of releases per year and some exploratory work has been already done by multiple sources. Now it’s time to put it all together and move forward with a plan of action.

What problem needs to be solved

WordPress releases involve quite a lot of manual labor and testing so the releases right now can’t be more than 3, 4 per year. Core contributors are eager to move to a more frequent cadence.

Scope of the Working Group

To evaluate what is needed to change the Core release model in terms of procedures, cadence, resources and produce a report that will:

  1. Document the existing release process
  2. Evaluate the technical changes needed to speed up the release process
  3. Evaluate if those changes are doable with the existing resources and tools

What has been done so far

A few people have already done some research and told their experience during dev chats or in the above-mentioned posts, including in the comments.

In particular, some blockers have been identified and the working group aims to document all of them and find reasonable and feasible solutions. Here is a nonexhaustive list of things that have been mentioned:

  • scoping the release
  • putting together a release team
  • the process itself: automated, semi-automated, manual tasks
  • supporting fewer PHP versions
  • supporting fewer WP versions (for security and other things)
  • better E2E tests and vuln tests
  • Tide support
  • writing the announcements
  • writing the dev notes
  • writing the field guide


The team needs people with different skills and levels of expertise

  • A project manager/coordinator to make sure work gets done
  • People with commit and mission control experience to document the process of the release itself
  • People able to write E2E and vuln tests
  • People that worked in previous released and are familiar with the coordination part: from scope to release.
  • Historians! People that have been contributing for a while and are able to provide some background and context.
  • Anyone who is willing to help 🙂

Time commitment and frame

Between 2 and 3 hours a week, more if you want to!

By the end of 5.4 release the group should produce:

  1. A research of the various steps of the release
  2. An evaluation of the technical changes needed
  3. A draft of the feasible proposed changes

Communication and project management

I propose the group meets weekly in #Core and adopts a project management tool for the research phase – Trello would be my suggestion. Once it moves to build solutions (hopefully!) Trac or GitHub can be used.

Who is in?

Please drop your name, and Slack username in the comments if you are interested and how you think you can help.

Deadline: January 5. Hopefully, work will start on January 7th or 8th

Dev Chat Agenda for January 8, 2020

Here is the agenda for the weekly meeting happening later today: Wednesday, January 8, 2020, at 09:00 PM UTC.


Upcoming Release – 5.4

Highlighted Blog Posts

Components Check-in

Open Floor

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #core, #devchat

Filtering nested REST response _fields in WP 5.3

WordPress 4.9.8 introduced the ability to limit the fields included in the JSON objects returned from the REST API, for example specifying


to return a list of posts with only id, title & author fields in situations where we don’t need all of the data contained in other fields like content or media (see #38131). Since 4.9.8 we’ve made further improvements to skip computing fields we did not explicitly request when _fields is present, saving time on the server in addition to slimming down the JSON response object.

In WordPress 5.3 we are adding the ability to filter by nested fields. Previously we could only request top-level properties like content or meta, which would return the full content object (with raw and rendered properties when using an edit context) or the object containing all meta values. We can now specify a nested path such as content.raw and the REST API will skip computing the rendered content, a useful performance boost for applications like Gutenberg which only require that underlying raw post content.

Now that we can register complex array or object meta, we may similarly ask for only a few of many registered meta fields, or certain properties within a complex object, using a query such as this:


(Note that this specific meta example depends on bugfix #48266, which will ship as part of RC1.)

Thank you @timothyblynjacobs, @dlh, @danielbachhuber, and @rmccue for assisting with the development of this useful feature!

#5-3, #dev-notes, #rest-api

Editor Chat Agenda: 8 January, 2020

Note taker: @pbrocks

This is the agenda for the weekly editor chat scheduled for 2020-01-08 14:00 UTC.

This meeting is held in the #core-editor channel in the Making WordPress Slack.

  • Gutenberg 7.2.0
  • Weekly Priorities
  • Task Coordination
  • Open Floor

If you have anything to share for the Task Coordination section, please leave it as a comment on this post.

If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.


Tentative Release Calendar 2020-2021

During the 5.3 release cycle I heard that the uncertainty of next release date was a concern for many.

I am happy to introduce you to a tentative release calendar for the next two years. But first…

Tentative why?

  • Because the exact dates will be confirmed only when the release cycle kicks off to be sure that there is enough time to work on the issues and features that are planned
  • Because I don’t know if there is going to be a major change or shift in technology, especially from third parties, so being cautious is natural.
  • Because there is also another sentiment going around the WordPress community, that the project can handle more frequent releases, so there might be some changes in the way things are done.

From 5.4 to 6.0

Major Version Potential Release Date
5.4 2020/03/31
5.5 2020/08/11
5.6 2020/12/08
5.7 2021/03/09
5.8 2021/06/08
5.9 2021/09/14
6.0 2021/12/07

Major religious holidays for multiple faiths and Federal US holidays were taken into consideration. If you spot a date that is a big no, please comment below before December 4th.

Dev Chat summary: December 18, 2019

Please note Dev Chat is suspended on December 24th and January 1st 2020. It will be back on January 8th 2020, same time, same place!

The chat was facilitated by @francina on this agenda.

All the discussions can be found in Core channel on Slack here.

Announcements and highlighted posts

@audrasjb gave an update about 5.3.1 version that was released on December 13. Right after, a couple of high severity issues were raised on Core Trac. The release team then planned and held two bug scrubs and released a provisional schedule for 5.3.2.

The first Release Candidate for 5.3.2 was released on December 17, with the 5 main issues fixed.

Update: WordPress 5.3.2 went live later yesterday after the devchat.

@francina gave a quick update of WordPress 5.4, which is ETA is still March 31 as initially planned. She is currently collecting feedback from component maintainers and the release could eventually be shortened if there are no big features planned to ship into the version.

Components Check-in

@johnbillion precised that component maintainership doesn’t mean having to fix all the bugs, and that it’s more a shepherding role. So, anyone interested in maintaining a component or just wanting to know more is welcome to ping a committer or release lead.

@imath called for attention on #33717 from the Comments component to which he proposed a patch.

@francina then manifested her desire to see the Comments components as one of the focus for 5.4, since it has been abandoned for a while.

An interesting discussion about components and components maintainers then took place. @francina asked about how the Core team can help with the recruitment of maintainers.

@karmatosed suggested a few steps that would basically consist in

  • Clarifying what component maintainers do.
  • Being ok with people going in and out of that role, almost encouraging it to spread good people around.
  • Looking at what is a focus for this coming year.

@garrett-eclipse suggested we do on Make/Core on seeking maintainers. He also proposed we can see who the regular contributors are in the component and reach out to them specifically.

@mikerbg said that a good step would be to identify individuals that are willing and able to provide some assistance to the marketing team to publicize recruitment opportunities and needs.

@jeremyfelt reminded this discussion from a chat in May, that it might worth looking at.

The full transcript of the discussions about components and components maintainers can be found here.

#devchat, #summary

Updates to Image Processing in WordPress 5.3

WordPress 5.3 includes several enhancements to how images are used and post-processed after upload.

When an image is uploaded to WordPress, alternate smaller sizes are automatically created. Some of these “intermediate” sizes are defined by core, and others by themes or plugins. These are used both for art direction uses, like alternate crops, and automatically by core for responsive images if they are the same aspect ratio.

Resizing images is very resource intensive. As average image sizes have increased over time, this has only increased the chances that requests may time out or run out of memory. WordPress 5.3 includes several enhancements to help more uploads succeed, and to aid users in recovery when they do not. These changes also enable WordPress to generate two new, higher resolution default sizes, to help user images look their best.

Saving of image metadata while creating intermediate sizes

Before 5.3, WordPress would first generate all intermediate sizes before saving proof of their existence in the database in meta.

This meant that if an upload failed in the middle, there could be many sizes that had completed successfully stored, but this wouldn’t be reflected in the database. A user’s only recourse was to re-upload over and over again in the hope that their server was less busy and all of the sizes would be generated.

In 5.3, this problem is fixed through saving metadata for each size as it is created in the database. This means more database writes, but allows WordPress to use the sizes generated earlier, and to resume failed uploads.

To make this possible, a new method make_subsize() was introduced in the WP_Image_Editor_GD and WP_Image_Editor_Imagick classes. It returns the new sub-size image path and dimensions ready to be added to the image meta’s sizes array. See #40439.

Additional changes:

  • Introduces wp_get_missing_image_subsizes() and wp_update_image_subsizes() to generate image sub-sizes that are missing or were not created after the upload.
  • Adds a way to display errors that happened while creating sub-sizes.
  • Introduces wp_create_image_subsizes() intended for use after an image was uploaded. It saves/updates the image metadata immediately after each sub-size is created.

With that in place it became possible to attempt to finish post-processing of images after upload if the server runs out of resources while creating intermediate image sizes (the dreaded “HTTP Error” message). See #47872.

“BIG image” enhancements

Until now it was possible to use the originally uploaded images on the front-end even when they are were not “web ready”. In WordPress 5.3 when a large image is uploaded it is stored in the uploads directory but is not used on the web site. A new scaled down image is created and used as the largest available size. This scaled down image is usually much more suitable for web use, the file size is up to ten times smaller than the original. See #47873.

Additional changes:

  • Introduces wp_get_original_image_path() that retrieves the path to the originally uploaded image in all cases.
  • Introduces big_image_size_threshold filter to set the pixel value above which images will be scaled. The same value is used as max-width and max-height when scaling the original.

These enhancements also made it possible to automatically rotate uploaded photos according to the EXIF data, and to add two additional default image sizes to better support high-density displays. See #14459 and #43524.

Thanks @mikeschroder for helping to write this post.

#5-3, #dev-notes, #media, #upload

Editor Chat Agenda: 18 December, 2019

Note taker: @andraganescu

This is the agenda for the weekly editor chat scheduled for 2019-12-18 14:00 UTC.

This meeting is held in the #core-editor channel in the Making WordPress Slack.

  • Core Editor meetings and Gutenberg releases during the holidays
  • Weekly Priorities
  • Task Coordination
  • Open Floor

If you have anything to share for the Task Coordination section, please leave it as a comment on this post.

If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.


5.3 Retrospective – Call for feedback

5.3 “Kirk” was released on November 12, 2019. It was twelve weeks in the making, it had a big team behind it and the highest number of contributors ever. Congratulations to everyone!

In order to prepare a retrospective post, I would like to ask everyone to leave some comments below with things they would like to bring up. To help, here are some questions to ask yourself:

  • What should WordPress start doing as a part of the development process?
  • What should WordPress stop doing as a part of the development process?
  • What should WordPress continue doing as a part of the development process?

Please share your thoughts in the comments below! Remember when commenting to keep the discussion professional and focused on ways the process of creating WordPress is either already working great or can be improved.

Edited to Add: if you rather not give your feedback in a public space, please reach out to the following people on Slack. They are available to collect your feedback in a safe space, with no judgement and use it in the retrospective in an anonymous form:

#5-3, #retrospective

Admin form controls height and alignment standardization in WordPress 5.3.1

WordPress 5.3 introduced some notable Admin CSS changes to improve administration accessibility and consistency with the block editor.

These changes made more obvious that form controls heights and alignments were not consistent across WP Admin.

Before WordPress 5.3, there were already some inconsistencies between form controls. For reference, WordPress 5.2 form controls various alignments and heights are grouped in the screenshot below:

Form controls alignment and height inconsistencies in WordPress 5.2

WordPress 5.3 Admin CSS changes brought more attention to those general inconsistencies on form controls. And several users and contributors reported these inconsistencies as regressions from 5.3.

Example of form controls inconsistencies in WordPress 5.3

Although these inconsistencies cannot be considered as regressions from 5.3 since they existed before 5.3 Admin CSS changes, WordPress 5.3.1 introduces some fixes on heights and alignments.


WordPress 5.3.1 changes include:

  • Standardized height basis of 30px for all form controls
  • Consistent line height basis of 30px across the interface
  • 14px font size basis for select controls option text
  • Remove various top/bottom margin and padding

These changes are part of a continuous effort to improve styling and consistency of all form controls in the WordPress admin pages. In general, plugin authors and WordPress developers are encouraged to:

  • remove any fixed height: flexible heights are now the WordPress recommended standard to allow form controls to better scale with text zoom
  • remove any custom top and bottom padding values
  • remove any custom line-height value
  • remove any custom min-height value
  • update custom focus/hover styles on custom UI components to match the new WordPress focus/hover styles

For full details about these changes, see the related changeset on WordPress Trac. WordPress developers and plugin authors may also want to visit the related Trac ticket: #48420

#5-3-1, #core-css, #dev-notes