Media Upload Request Flow in WordPress 5.3

After a couple of questions from hosting companies about how to detect how well uploads are working at the server/request level, I thought further documentation would help.

Here is a walkthrough of the request flow for media uploads, both before and after WordPress 5.3. Hopefully this will help with troubleshooting and debugging uploads on your infrastructure or sites!

Before WordPress 5.3

Before WordPress 5.3, uploads had to complete during a single HTTP POST request to .../wp-admin/async-upload.php or to the REST API with the media endpoint (.../wp-json/wp/v2/media/).

The block editor uses the REST API to upload, while any uploads outside the block editor (or using the popup Media Modal) use async-upload.php.

When uploads failed, they would return whatever HTTP error the server is set up to give (usually in the 5xx range). This is usually due to timeout or resource exhaustion (like running out of memory) reasons.

WordPress 5.3+

In WordPress 5.3+, uploads have been decoupled from a single request to allow for resuming. Now, when an upload returns a 5xx error, there can be up to 5 followup requests.

This is accomplished differently depending on whether async-upload.php or the REST API are used.

Legacy Uploads

Outside of the REST API, the upload happens first with a request to async-upload.php, just like before 5.3.

If it fails, a request is made to admin-ajax.php with form-data containing action: media-create-image-subsizes and attachment_id: #### to attempt to complete the action.

If all retry attempts fail, the last request to admin-ajax.php has _wp_upload_failed_cleanup: true in form-data and attempts a cleanup. This deletes the the attachment post, the uploaded file, and any intermediate sizes that were created. Then, an error message is shown to users advising them to scale down the image and try uploading again.

REST API Uploads

When using the REST API, the initial request is to .../wp-json/wp/v2/media?_locale=user, and retry requests are to .../wp-json/wp/v2/media/####/post-process?_locale=user (where #### is the attachment post ID).

If all attempts to resume post-processing fail with HTTP 5xx errors, the last is a standard “delete attachment” request, sent to .../wp-json/wp/v2/media/####?force=true&_locale=user with X-HTTP-Method-Override: DELETE header. It performs the same cleanup as described for the admin-ajax.php upload method.

Hopefully this helps in understanding how uploads work! If you have any questions, please ask in the comments for clarification.

Thanks to @azaozz for helping write this post!

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

5.3 Release Cycle Post-mortem

By the Numbers

This cycle was longer, taking just over six months. The development (alpha) stage was 138 days, from May 8 to September 23. During that time there were 779 commits to 5.3 (trunk). Most active committers were @SergeyBiryukov with 426 (no surprises there), @pento 66, @afercia and @desrosj with 51 commits each.

The “beta” stage started on September 23 and lasted for 23 days. There were 274 commits. Most active committers were @SergeyBiryukov with 78, @afercia 42, @desrosj 34, and @whyisjake with 24 commits.

The “release candidate” stage started on October 16 and lasted for 27 days. There were 100 commits including documentation and build tools changes. Most active were @SergeyBiryukov with 39, @desrosj 20, and @johnbillion with 14 commits. There were 30 commits that were merged to the 5.3 branch after it was created on October 29.

In total the release cycle lasted for 188 days and there were 1,153 commits. Looking at the numbers, the busiest time was during beta with an average of nearly 12 commits per day. For comparison there were only about 5.5 commits per day during the “alpha” stage *.

Needed Improvements

There were also some irregularities during the 5.3 cycle.

  • Many “new” bugfixes were committed during beta. Generally these are added in alpha, and beta is reserved for testing and fixing any bugs introduced in alpha.
  • Several apparent enhancements were committed from partially related bugfix tickets: #34904, #47477, #47153, etc. Preferably there would be a discrete 1:1 relationship between tickets and changesets.
  • Some code that would be considered “alpha” (mostly untested and non-reviewed) was committed during beta. Preferably any code committed in beta is well-reviewed by multiple people with varied knowledge/experience with the existing code/areas of expertise.

A substantial departure from past releases was the inclusion of “global” CSS changes affecting all of the WordPress admin during beta. They were committed from unrelated or partially related tickets: [46241], [46360], [46244], and most of the other changesets marked as “Improve and modernize user interface controls”.

It would have been preferable for the changes to be separated in new tickets, tested, reviewed, and then committed. Separating these into individual tickets would also have let enhancements be isolated and prepared for the next major release.

Individually, none of the irregularities listed above are a big problem, but when taken all together it introduced avoidable complexity. In this particular case, many small styling bugs were introduced during beta, which is far too late in the release cycle. Again, individually they were fixable, but their late introduction and lack of discrete ticketing left folks without enough time to find and fix them all.

Moving Forward

There are few steps that can be taken to avoid such irregularities in the future:

  • Add some “Release Cycle 101” to the developer documentation. This will ensure that people without prior experience are on the same page. Generally during alpha anything goes. Trunk can be broken and fixed every day as the contributors iterate on enhancements and bugfixes. Beta is for testing by the users and to fix the bugs that were introduced in alpha. RC is “we think it’s ready, find the edge cases!” 
  • Add a requirement for a code review for all changes committed during beta. Generally this has been the case for most commits during both alpha and beta. Requiring a review before merging works very well in Gutenberg. It’s about time to make it “official” on Trac too.
  • Remove the “(blessed)” part from the “task” ticket type on Trac. It seems it gives the wrong impression that a ticket can be “blessed” by anybody to allow it to bypass the release cycle rules.
  • Restrict use of the “task” ticket type on Trac only to the project leadership. Bypassing (our own) release cycle rules is not something that can be done lightly and carries a lot of responsibilities. Also, perhaps add a requirement for at least two reviews for each commit/code change in this case.
  • Perhaps extend the section on creating and using Trac tickets to specifically disallow unrelated or partially related changes to be made. This may be somewhat hard to determine, but when in doubt, better to create a new ticket instead of exponentially extending an existing ticket. In 5.3 there are several examples of such “run-away” tickets: #47477, #47153, #34904, etc.

* The slower commit pace during alpha is partially due to new features being developed, and not committed until deemed “ready”. Another reason is perhaps that complex enhancements and bug fixes need more research, reviews and testing before committing. Yet another reason is that perhaps most contributors focus more on the new features, enhancements and more complex bug fixes leaving the “easy” bugs for later.

#5-3, #retrospective

WordPress 5.3.2 Maintenance release schedule

Shortly after WordPress 5.3.1 was released, a couple of high severity Trac tickets were opened. The Core team immediately scheduled two bug scrubs to help these tickets moving forward.

Main tickets addressed in 5.3.2:

  • Date/Time component: #48957 – Call to a member function format() on boolean in wp-includes/feed.php
  • Upload component: #48975 – Fix unhandled upper/lower case change in wp_unique_filename()
  • Media component: #48960 – Failed to open dir: No such file or directory in Windows
  • Build/Test tools component: #48145 – Random PHP test failures
  • Administration component: #49003 – Permalink buttons lack color contrast in most alternate color schemes

For reference, see the full 5.3.2 report on Trac.

@azaozz @sergeybiryukov and @audrasjb will take care of this maintenance release as 5.3.2 is coming very shortly after 5.3.1 was released.

Expected schedule for 5.3.2:

  • Release Candidate 1: Tuesday December 17, 2019 around 20:00 UTC (start of the release process)
  • Final release: Wednesday December 18, 2019 right before or after the devchat weekly meeting

#5-3, #minor-releases

WordPress 5.3 Retrospective Recap and Next Steps

The week of WP 5.3 release I posted a call for feedback for the development workflow.

Thank you to everyone that left their comments! Reflecting on what worked and what didn’t is a great way to move forward together and steer the wheel if and when needed.

Some comments didn’t follow the proposed format of start/stop/continue so it wasn’t very clear where they fit: I tried to put them in one of the categories. I also rephrased some feedback that was sometimes given as a positive statement (continue doing A instead of B) and sometimes a negative statement (stop doing B and do A). Finally, I added feedback I collected from the focus leads or from anonymous sources.

If something doesn’t feel right let me know and I will amend the post.

Read on for everyone’s feedback!

Continue reading

#5-3, #summary

Dev Chat Summary: November 20, 2019

Here’s a summary of the November 20 Dev Chat (agenda / Slack archive).


The 5.3 Retrospective – Call for Feedback post.

@clorith asked, “Would it be an idea to also allow for an anonymous form to submit to that? I know some folks may not be comfortable with the potential for conflict, and may feel safer giving an honest feedback if it wasn’t all public under their name? Then the feedback could be provided by the leads under a followup post, with no relation to individuals.”

@francina said she’d change the post to mention that anyone who’d like to give feedback privately is welcome to do so. 5.3 release leads @davidbaumwald, @youknowriad, @justinahinon, @audrasjb also committed to offering the same.

Upcoming Releases


@whyisjake offered the current list of tickets in the milestone at

After a quick discussion of potential release dates, December 11, 2019 came out a potential winner. It’s pretty soon, but it still gives us time to triage 5.3 regressions and bugfixes. That decision is not final – it’s pending more discussion in the comments.

Got thoughts on timing? Please leave them in the comments – the sooner the better.

While we see how those conversations shake out, @audrasjb graciously offered to lead the first 5.3.1 bug scrub on Thursday November 21, 2019 18:00 UTC

Next up: a call for volunteers to lead the release.

@sergeybiryukov, @audrasjb, @amykamala, @marybaum, and @whyisjake all raised their hands. Everyone expressed great confidence in the potential candidates.

Want to be part of the 5.3.1 release squad? Please leave a comment.

Open floor

@youknowriad brought up a discrepancy in the release cadence between WordPress Core and Gutenberg:

By December 11, the date proposed for a 5.3.12 release, Gutenberg will be ahead of Core with about 5 releases and this is a problem. 12 Gutenberg releases shipped into 5.3 . This is too much for a single WordPress release and with the current schedule, it’s seems like this is going to be similar for 5.4. This is not tenable for the future. It’s hard to stabilize and ship, it’s hard to summarize the changes for third-party [developers] and users, it’s more scary to ship and people were recommending the plugin to be installed for their clients (and it’s risky since the plugin is a development plugin). So how to reduce that gap is a big issue that needs solving IMO.Ideally I do think a shorter release cycle for majors is better. (Why not just a 5.4 in like end of January). [O]therwise we’ll have to include enhancements in minors.

This generated a long discussion that continued well past the end of the Dev Chat. See the full conversation starting here.

@davidbaumwald led the chat and wrote these notes. @marybaum did some editing.

#5-3, #devchat, #summary

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

Dev Chat Summary: November 13, 2019

@francina led this week’s dev chat – the last one of the 5.3 release cycle – see the agenda here.

For the full transcript, see the Slack archive here.

Your faithful reporter: @amykamala. Let’s get going!


@francina opened Announcements with the release of WordPress 5.3, which went live on November 12, 2019!

She congratulated everyone, NOT just the folks active in the chat, on an amazing job. Several Core committers were especially pleased that 5.3 came in on schedule (🎉) with the biggest group of contributors ever.

Here are a few statistics:

  • 12 weeks of development
  • A release squad with nine focus leads, covering every relevant component that got an update
  • 645 contributors
  • 658 bugfixes
  • A new default theme, Twenty Twenty
  • Lots of fun and new friends made
  • And much, much more!

Before release the squad counted at least 153 user-experience enhancements.

Highlighted Posts

The annual WordPress survey is open! Your feedback is not just appreciated – it’s vital to the future of WordPress. So please fill it out and share it everywhere you can think of.

Tanking the floor for a moment, @chanthaboune told the group this survey is new – not the same as last year – and is broader. Whether you’re a contributor, designers, developers, users or hosts, please participate!

Again, please share the survey with anyone who touches WordPress in any way.

5.3 Housekeeping

Big thanks to everyone who has helped with testing so far! If that includes you, please keep testing and report any issues, concerns or enhancement ideas in a comment on Trac.

That’s how WordPress gets better and you get to shepherd your best ideas through the process.

Need a refresher on how it works? Here’s an outline of the post-release process.

@francina wrapped the discussion with a note that in the next few weeks the release leads will open a call for retrospective. Want to share some honest, constructive feedback? That’ll be your chance!

5.3 Housekeeping Calls from component maintainers

@francina opened the floor for component maintainers to bring up topics for discussion. These are the components.

@marybaum said “I love that we have a #core-css channel. Does that mean Core CSS is a component?”

@peterwilsoncc replied, “it’s closer to a focus than a component. Tickets can still be assigned to the affected component, eg Admin, Themes, etc. “

@sergey asked “If we have a `javascript` focus, should we add one for CSS as well? 

After a few more comments from folks, @francina reminded all 30,000-plus potential attendees that we don’t make final decisions in devchat.

She asked the folks talking about CSS to follow this process:

  • Make a proposal on the Core blog
  • Discuss
  • Come to a conclusion
  • Act

Here are the reports from other component maintainers:

@williampatton: “Themes component is looking good. Prepping for next release.” 

@peterwilsoncc: “From the security team, now we have a Travis CI account that allows for private repos, we have the security tests running regularly. It should make it easier to find out if they’re passing during the release process.” and went on to ask @sergey if it was possible to add it to Trac.

@garret-eclipse: “In the privacy component @rogierlankhorst has started work on a consent api.

Open Floor

@mensmaximus asked whether “we ever change the user management screen to a tabbed interface. What is the current state and what do core devs think?”

@williampatton started with a general reply: “There are lots of thoughts on redesign for user management, but lots of ideas mean lots of decisions [making it] hard to reach agreement.”

A lively discussion followed. Hopefully the WordPress world will see some new ideas for an even more usable Admin experience!

(Ed. note: The UX discussion and the conversation below, about jQuery, happened at the same time, and you’ll see the comments jump from one to the other. Still, imo, both are worth your time and effort to decipher!)

@enrico.sorcinelli has “noticed that Juery’s `$` is no longer globally defined in admin.” That’s made some of their client sites cause issues with users’ code.

@clorith answered, “The jQuery `$` being globally available was a bug.” That bug got fixed in one of the JS updates in 5.3.

“Although it’s not ideal, reports of issues are fewer than expected, and the code errors would be within the plugin code,” @clorith continued, adding, “I tend to lean towards leaving it being the right thing.” 

Here’s the ticket they’re talking about and the full discussion, including some observations on the future of jQuery.

@clorith noticed two items leading the pack of recurring issues, 24 hours in:

  • The update to add_submenu_page gives doing-it-wrong errors. We knew this, but devs weren’t prepared for users to have debugging enabled. 
  • The change to spread operators had plugins breaking, because things like custom walkers had dependencies on the previous operators.

See the full discussion starting at the link above. (Ed. note: this highlighted test is the same link.)

@pbiron asked if anyone had reported problems with the new big-images or rotate-on-upload features. 

@clorith and others noted very few issues.

#5-3, #devchat, #meeting-notes

WordPress 5.3 RC 5

The fifth release candidate for WordPress 5.3 is now available for testing.

WordPress 5.3 is currently scheduled to be released on November 12 2019.

There are two ways to test WordPress 5.3 release candidate 5:

For details about what to expect in WordPress 5.3, please see the first,  secondthird and fourth release candidate posts.

Release Candidate 5 contains some bug fixes for the new default theme, Twenty Twenty – for reference, see #48557 – and addresses the following tickets:

  • #47708 – 5.3 about page
  • #48312 – Fix a typo in an inline comment
  • #48542 – In wp_default_packages_inline_scripts(), make sure the root URL middleware is registered before using the media middleware
  • #48543 – Comments: check if comment form element exists before adding a key handler to detect the cmd/ctrl-enter key press.
  • #48517 – Bundled themes: several changes to ensure consistency and accuracy for default theme headers
  • #48518 – Upload: When an image was scaled because it is larger than the big image threshold, use the originally uploaded image’s dimensions in wp_get_missing_image_subsizes(). Fixes an edge case/inconsistent behaviour when a registered image sub-size is also larger than the big image threshold.

Plugin and Theme Developers

Please test your plugins and themes against WordPress 5.3 and update the Tested up to version in the readme to 5.3. If you find compatibility problems, please be sure to post to the support forums so we can figure those out before the final release.

The WordPress 5.3 Field Guide has also been published, which details the major changes.

How to Help

Do you speak a language other than English? Help us translate WordPress into more than 100 languages!

If you think you’ve found a bug, you can post to the Alpha/Beta area in the support forums. We’d love to hear from you! If you’re comfortable writing a reproducible bug report, file one on WordPress Trac, where you can also find a list of known bugs.

#5-3, #testing

Dev Chat Summary: November 6, 2019 (5.3 week 12)

This post summarizes the weekly dev chat meeting from November 6th 2019 (agenda / Slack archive).


WordPress version 5.3 Release Candidate 4 was released on Tuesday 5th. Everyone please help by testing out the RC.

Upcoming Releases – 5.3

@joyously asked where to look to see how translations are going for WordPress 5.3. @mapk shared the link to the project summary on Translate.

@collet raised some issues discovered on Twenty Twenty:

  • One issue related to nested rules in full-width Group & Cover blocks: 965.
  • Four issues related to column block: 960, 961, 962 and 963.
  • One issue related to nested blocks on starter content: #959
  • Also mentioned a pull request (701) that would be a worth inclusion in 5.3

@johnbillion answered Twenty Twenty can be updated independently of core. It’s ultimately up to the team behind the theme to decide if any of these bugs need to go into Twenty Twenty before 5.3 is released, or whether they can wait until a patch release of the theme.

@anlino will take a look at fixes for the columns issues today and tomorrow. Hopefully he can get those fixes before 5.3 final release. If there isn’t time to get them tested and merged properly, at least we’ll have the fixes good to go post-release.

The issues will be discussed in Twenty Twenty GitHub repository and in the core-themes and core-editor Slack channels to see what can land in time for final release of 5.3.

@collet also mentioned an issue related to the About page. In the about page. it’s said that “Heading blocks now offer controls for text and background color”. However, there is no control to change the background color inside the editor. It doesn’t appear to be related to Twenty Twenty. It needs to be updated in the About page.

Finally, @mikeschroder asked for more testing concerning a recent post published on Make/Core: Use of the “wp_update_attachment_metadata” filter as “upload is complete” hook

Open floor

@isabel_brison asked if a core-css channel could be created on Make WordPress Slack team to discuss CSS stuff. Given the amount of positive reactions, the Slack channel was immediately created by @peterwilsoncc 💥🕺💃

@mpcube asked for a review on ticket #48506. Discussion to continue in the proper ticket.

Move Dev chat meeting time (end of daylight saving time)

@audrasjb asked for a final decision about moving the dev chat meeting time with end of daylight savings time (DST). The meeting attendees agreed to move it from 20:00 UTC to 21:00 UTC starting on Wednesday 13th November. The New Contributor Meeting will also move from 19:00 UTC to 20:00 UTC.

These notes were taken by @audrasjb and proofread by @davidbaumwald

#5-3, #css, #devchat, #twentytwenty

Dev Chat Summary: October 30th 2019

This post summarizes the weekly dev chat meeting from October 30th 2019 (agenda / Slack Archive).


WordPress version 5.3 Release Candidate 3 was released on Tuesday. Everyone please help by testing out the RC.

Core editor team released Gutenberg version 6.8.

Dev chat meeting time

Like every year, with end of DST (daylight saving time), the meeting time should be moved from 20:00 UTC to 21:00 UTC.

Two options are proposed:

  • Moving on Wednesday November 13th (the day after WP 5.3 is going to be released)
  • Moving on Wednesday November 20th (one week later)

Please share your thoughts in this post’s comments.

WordCamp US Contributor Day

WordCamp US’s contributor day is planned for Sunday 3rd November.

5.3 was branched last week, so contributors will be able to work on WordPress 5.4 milestone since trunk is now version 5.4-alpha.

@earnjam and @wpscholar will be leading the core table, Helping people get set up, learn how to get started, find places to focus on work, etc. They also should have several component leads present that can split off and focus on their areas for people who are interested.

Upcoming Releases

WordPress 5.3 Release Candidate 4 is scheduled next Tuesday if needed.

There is still 7 tickets open in the milestone.

@azaozz regrets that things weren’t reported much earlier, during beta. By the way, two tickets have patches already, one is almost there, and one may be a candidate for 5.3.1. As 5.3 was branched, all fixes are probably going to be committed to trunk (5.4-alpha) but hold on on merging to 5.3 for couple of days to allow easier testing and review. All are (possible) regressions with the way some plugins use particular hooks around image post-processing and image meta updates.

@joyously reported a feedback found in Alpha/Beta support forum. It was already merged to Gutenberg and looks fixed in 5.3 block editor code. @youknowriad was pinged as Editor focus lead for WP 5.3.

Open floor

@joyously asked about backporting security fixes to old versions request’s status.

@clorith and @audrasjb noted there will be a panel session at WordCamp US. For those who are not attending WordCamp US, questions can be sent via Twitter.

@desrosj added that there was a very large amount of feedback. @chanthaboune and others are working to compile all that feedback so that all of it can receive proper consideration.

#5-3, #contributor-day, #wcus