Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix handling of HTTP 500 errors while uploading images #17474
The main reason an image upload would fail is the server running out of resources while post-processing (creating sub-sizes). In WP 5.3 the resizing of images after upload was updated/fixed and it is now possible to retry creating the sub-sizes, even after an upload request ends with a server "crash" (timeout or out-of-memory fatal error).
On the client side an unique "upload ID" is sent with each image upload request. Then if the original request ends with HTTP 500 error, the client does another request including the same upload ID so the server (PHP) can try to create any missing image sub-sizes. This can be repeated several times.
Then, if all attempts fail, the client sends a "cleanup" request so the server can delete any orphaned sub-sizes, etc. The client should also show appropriate error message, something like:
Post-processing of the image failed. If this is a photo or a large image, please scale it down to 2500 pixels and upload it again.
This is already implemented in the Media modal and on the Media Library screen, see https://core.trac.wordpress.org/ticket/47872 and https://core.trac.wordpress.org/changeset/45934. The actual "old style" js is quite straightforward and is mostly here: https://core.trac.wordpress.org/browser/trunk/src/js/_enqueues/vendor/plupload/wp-plupload.js?rev=45934#L110.
It reuses the Plupload
Related: https://core.trac.wordpress.org/ticket/47987#comment:1 for adding an API endpoint for the retry requests.
Sorry for the delay in responding. Some problems with how that was working needed fixing.
A custom header with the
When an upload request ends with a HTTP 500 error, the client should look for that header and get the attachment ID.
Then, if there's an ID, do another request to resume creation of image sub-sizes. That request should be to the same "create attachment/upload" end point but should have another custom header (as this is considered "request meta" in REST). This can be repeated 2-3 times if the response is still HTTP 500. Finally if it is still HTTP 500 the last request should be to delete the new attachment.
It should "just work" as previous versions won't have the custom header with the attachment ID in HTTP 500 responses.
Good question :) It should be able to look at the "raw" responses from the API and access the HTTP response headers. Can probably be part (or exception) of the general error handling.
I've been adding a
https://core.trac.wordpress.org/ticket/47872#comment:1 also has testing instructions that will get you closer to the real behavior.
Best way is to tweak php.ini on the test server, find and change
I've also made a small testing plugin: https://gist.github.com/azaozz/91101d686127137b0f5b850f0d269972. It is mostly to show the attachment meta on the Media Library list view, but also adds a lot of image sub-sizes in order to overload the server (tweak the code at the top as needed).
Of course a filter on