[wp-trac] [WordPress Trac] #10752: Uploading new media to existing posts/pages backdates file location

[WordPress Trac]

#10752: Uploading new media to existing posts/pages backdates file location
--------------------------+---------------------
 Reporter:  dpie          |       Owner:  pento
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:  4.9
Component:  Media         |     Version:  2.8.4
 Severity:  minor         |  Resolution:  fixed
 Keywords:                |     Focuses:
--------------------------+---------------------

Comment (by simonrcodrington):

 I've just come across this now and wanted to flag my use case in case
 anyone else runs into this in the future.

 The issue I've come across is that when you use the
 **wp_generate_attachment_metadata** hook (that's called when the
 attachment metadata is being generated, e.g for intermediate image sizes),
 it creates some confusing situations about the relative file paths of
 attachments. Both **$metadata** and **attachmentId** are passed for the
 media item.

 If you're using the **wp_generate_attachment_metadata** hook to do
 something on the intermediate images (e.g remove them because you've
 offloaded them to the cloud) you would try and find the relative file
 paths and you would normally use **wp_upload_dir** to get the directory
 and append the file for each of the intermediate sizes.

 When using the **wp_upload_dir** function, it returns back the an array of
 where your WP uploads are stored. The useful parts here are:

 * **path** - relative path to the WP uploads directory including the
 logical month / date format if enabled e.g /mywebsite/wp-
 content/uploads/2018/05
 * **basedir** - relative path to the WP uploads directory  e.g /mywebsite
 /wp-content/uploads/

 The issue I've found here is that if you go into a content type (e.g posts
 / custom post type) and select a featured image and upload a new image,
 it's file name will use the year/month of the post type content and not
 todays date. e.g if you edit an old article from 2017/12, the media
 attached will have it's path changed to use the 2017/12 directory.

 While that might make sense (since the article is from that date). What
 doesn't make sense is now there's no real way to get the relative file
 path top the intermediate images.

 Beforehand if you wanted to get the thumbnail relative image, you could do
 the following

 {{{
 //build relative path to thumbnail image
 $file = wp_upload_dir()['path'] . '/' . $metadata['thumbnail']['file'];
 }}}

 That would generate a path such as /mywebsite/wp-
 content/uploads/2018/05/myimage.jpg, which is perfectly fine if used in
 the 'media library' as all new images added to the gallery use today's
 date for their upload structure.

 However, if you're in a content type and editing an article from months
 ago, the path that is generated will be incorrect (it will be pointing to
 2018/05 instead of the year/month the article was published on).

 The only real way to generate the path now (since you can't rely on
 **wp_upload_dir()[path]** is to use **wp_upload_dir()[basedir]** to get
 you /mywebsite/wp-content/uploads and then manually determine the year and
 month by looking at the **$metadata[file]** element to get the name of the
 file (which will contain the year, month and name of the file).

 From here you can regex the year and month and form the correct URL path.
 E.g


 {{{
 //Get the year/month directory structure for the given metadata
 $yearMonthFolder = '';
 preg_match("#[0-9]{4}/[0-9]{2}#", $metadata['file'], $yearMonthFolder);
 $thumbnailRelative = sprintf("%s/%s/%s", $wpDir['basedir'],
 $yearMonthFolder[0], $metadata['thumbnail']['file']) :

 }}}

 I'm not sure if there's any way to change this, but this issue was causing
 me issues as images would upload and work as expected in the media gallery
 but would generate errors when used in post types (because of the
 directory path)

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