[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