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

WordPress Trac noreply at wordpress.org
Mon Oct 28 21:42:53 UTC 2019


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

Comment (by ianmjones):

 Replying to [comment:1 azaozz]:
 > 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?

 I should clarify the problem here, it's not so much that the
 `wp_update_attachment_metadata` is used for knowing when an upload is
 complete, it is more used to know when the image and its sub-sizes have
 potentially changed.

 So initially yes, on a new upload we (WP Offload Media) use it as a signal
 that an image has been uploaded and all of its thumbnails are present and
 correct and ready to be sent on their merry way to a storage provider.

 However, if thumbnails are regenerated, or an image optimizer plugin batch
 job processes the image and updates the thumbnails, they too generally
 call `wp_update_attachment_metadata` when they are done with the Media
 Library item. And again, that means plugins like WP Offload Media can re-
 offload the images to S3/GCS/DO Spaces etc.

 The problem with the new setup is that it fires
 `wp_update_attachment_metadata` a lot, and with partial metadata (e.g. no
 sizes array initially). Which is very different to how it has been.

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


More information about the wp-trac mailing list