[wp-trac] [WordPress Trac] #48451: Regression: wp_update_attachment_metadata filter now fires very often and without compete metadata

[WordPress Trac]

#48451: Regression: wp_update_attachment_metadata filter now fires very often and
without compete metadata
-------------------------------------+---------------------
 Reporter:  ianmjones                |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  5.3
Component:  Media                    |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-patch 2nd-opinion  |     Focuses:
-------------------------------------+---------------------
Changes (by azaozz):

 * keywords:   => needs-patch 2nd-opinion
 * milestone:  Awaiting Review => 5.3


Comment:

 Moving to 5.3 for consideration.

 At first look:

  A common pattern throughout WP5.2 (and still in WP5.3) is as follows...
  `wp_update_attachment_metadata( $id, wp_generate_attachment_metadata(
 $id, $file ) );`

 Right, but `wp_update_attachment_metadata()` is also used in quite a few
 other cases. For example when editing an attachment post, in
 `wp_ajax_crop_image()`, to update the ID3 data for audio files in
 `wp_ajax_save_attachment()`, when editing an image (crop, rotate, ...),
 for custom background and header images, etc.

 Seems using the same filter to detect when images have been uploaded
 successfully is problematic?

 Until now the `wp_generate_attachment_metadata` filter was the (de facto)
 "upload is successful" hook. This is still the case in n 5.3, however when
 the initial upload request fails and the client makes another request to
 finish image post-processing `wp_generate_attachment_metadata` is not
 fired. There is a proposed "action" in (the new)
 `wp_update_image_subsizes()`, see
 https://core.trac.wordpress.org/attachment/ticket/47872/47872.3.diff.

 Thinking that adding an `$unfiltered` param to
 `wp_update_attachment_metadata()` and avoid filtering would be wrong.
 Other plugins may be using that filter for other purposes, for example
 moving/updating/fixing the paths to the image sub-sizes.

 It's also possible that the image attachment meta data is stored
 temporarily "somewhere" while image sub-sizes are being created (another
 post meta?), then "moved" to the proper place. At first look not liking
 much that workaround.

 Any other ideas and/or possible fixes? :)

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