[wp-trac] [WordPress Trac] #47987: REST API: Add handling of PHP fatal errors while resizing images after upload
WordPress Trac
noreply at wordpress.org
Sat Oct 5 18:00:55 UTC 2019
#47987: REST API: Add handling of PHP fatal errors while resizing images after
upload
-------------------------------------------------+-------------------------
Reporter: azaozz | Owner:
| TimothyBlynJacobs
Type: task (blessed) | Status: accepted
Priority: highest omg bbq | Milestone: 5.3
Component: REST API | Version:
Severity: normal | Resolution:
Keywords: has-patch needs-unit-tests dev- | Focuses:
feedback commit |
-------------------------------------------------+-------------------------
Comment (by TimothyBlynJacobs):
> The only thing I'm a bit unsure about is including the header only on
the first upload request.
I included it pending #48200. If it's decided not to use that patch, then
we could remove it.
But it would be here to only send when someone is making an HTTP request
to `/wp-json` not when someone is doing `rest_do_request()`.
-----
To summarize the current flow.
1. `POST /wp/v2/media`
2. If the upload failed, look for a response header with `X-WP-Upload-
Attachment-ID` header that contains the newly created attachment ID.
3. `POST` /wp/v2/media/{id}/post-process` with `{ "action": "create-image-
subsizes" }`. This request may still fail, but it will save its progress.
4. On continued failure, `DELETE /wp/v2/media/{id}` to give up on the
upload and instruct the user to resize their image before uploading.
------
Separately, to try and summarize the changes and conversation between
@azaozz and myself.
The latest patch moves `wp_generate_attachment_metadata` to the very end
of the upload process. The saving of additional fields and the
`rest_after_insert_attachment` hook would now happen _before_ that
metadata is persisted. Generating a subset of that attachment data, and
excluding the subsizes generation was explored, but didn't look possible
because there are a number of places where WP expects that the "sizes"
array is valid. This would've allowed us to ensure that `POST
/wp/v2/media` wouldn't fail.
Secondly, a separate RPC-like REST route was introduced `/wp/v2/media/{id
}/post-process`. This endpoint will perform post processing actions,
starting with `create-image-subsizes`. This is not very RESTful, but I
think a separate RPC endpoint makes sense here.
1. I think we'd end up with a more unintuitive interface if we tried to
represent this as a state transfer, instead of a command to perform an
action.
2. Additionally, these action commands may fail midway with internal
server errors. This would make performing other updates on the `PUT
/wp/v2/media/{id}` endpoint unsafe.
3. For the same reason, we also wouldn't be able to guarantee that
`rest_after_insert_attachment` would fire.
So to me, it makes sense to consolidate these "unsafe" operations into an
RPC-like endpoint.
We also removed the ability to resume an upload using the same `POST`
request by setting a custom request header with an attachment ref or id.
This means that if a plugin was adding response data only on the initial
create item response, that code may no longer work ( if the initial
request failed ).
For example:
{{{#!php
<?php
add_filter( 'rest_prepare_attachment', function ( WP_REST_Response
$response, WP_Post $attachment, WP_REST_Request $request ) {
if ( $request->get_method() === 'POST' && $request->get_route() ===
'/wp/v2/media' ) {
$response->data['custom_field'] = 'only on create';
}
return $response;
} );
}}}
This code would have an upgrade path by looking for the `post-process`
route in the request.
CC: @kadamwhite, @joemcgill
--
Ticket URL: <https://core.trac.wordpress.org/ticket/47987#comment:34>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list