[wp-trac] [WordPress Trac] #47987: REST API: Add handling of PHP fatal errors while resizing images after upload

WordPress Trac noreply at wordpress.org
Thu Sep 26 20:44:56 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:  needs-patch      |     Focuses:
-----------------------------+--------------------------------

Comment (by azaozz):

 > I was thinking the request would be the normal POST but with an added
 header, something like `X-WP-UploadRef: randomReference`.

 Sure but... Why in the header? The upload ID/reference is still part of
 the data sent to the server. It is not that different than the rest of the
 data that the server needs in order to process the upload?

 > Instead of a separate endpoint for continuing, I think we need to have
 all of this done on the POST create_item() route, so that the
 WP_REST_Request object has all the expected data for the additional fields
 that are processed, and the *_insert actions.

 It's up to the API maintainers but having a separate "action" for post-
 processing seems to make sense?
 - The upload is complete by that point and the attachment post is already
 created (or at least is expected to have been created).
 - At this point we are just monitoring or triggering post-processing of
 the uploaded file. Eventually that can be used for other post-processing,
 not just image resizing.
 - None of the original fields are needed any more.
 - Re-sending the same original data is redundant or may potentially result
 in a duplicate?

 Actually I'm not entirely sure how uploads are supposed to work through a
 REST API. Streaming from js to an end-point has certain disadvantages (may
 require the whole file to be loaded in memory by the browser, then it
 fails for large files). "Direct" POST from the browser usually works more
 reliably. Perhaps worth a look in the future :)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47987#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list