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

[WordPress Trac]

#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                                       |
-------------------------------------------------+-------------------------

Comment (by azaozz):

 Replying to [comment:19 TimothyBlynJacobs]:

 Thanks for the patch!

 > I'm also not really a fan of how the control flow works here.

 Yeah, the "weakness" is probably because creation of the attachment post
 and uploading of the file is mixed up/mashed together. These are two
 distinct actions, should be fairly separate. I understand that until now
 "upload post-processing" was brute-forced while creating the attachment
 meta data, but now it requires additional steps.

 It is a three step "process". The upload ref is always present in all
 upload requests for images (could potentially be present in all upload
 requests regardless of file type, but is not currently used for non-image
 files).

 **Step one**
 On the initial request the file is uploaded and attachment post created.
 Then the upload ref is saved in a transient and the request continues as
 before.

 Looking at the code perhaps `do_action( 'rest_insert_attachment',
 $attachment, $request, true );` should run then, as soon as the attachment
 post is created. This will be consistent with other WP actions and filters
 that run at the time an attachment post is created. I'm not sure what is
 the intended purpose of that action but it seems it is related to the
 attachment post and not to the uploaded file.

 **Step two**
 If the step one request fails (with HTTP 500 error), the client does
 another request still including the same upload ref. This is a "retry"
 request and needs to be marked as such (another custom header perhaps?).
 There is no file included in that request, just the upload ref and a
 "retry" flag (and a nonce, etc.).

 When the server sees this request it doesn't try to create another
 attachment post but instead tries to find the just created post using the
 upload ref. If found, it makes a call to `wp_update_image_subsizes(
 $attachment_id );`. If not, returns error as the upload has failed.

 Step two can run several times if the response is still HTTP 500. If it
 succeeds in creating all image sub-sizes, it should return the standard
 response as in step one.

 **Step three**
 If all step two requests fail, the final request should do a "cleanup" and
 delete the attachment post. This still includes the upload ref so the
 server can find the attachment_id. It should also include another flag
 similarly to step two to tell the server that it is a cleanup.

 On success in any step the transient made from the upload ref is deleted.

 I'll try to update the patch and include the above.

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