WordPress.org

Make WordPress Core

Opened 9 years ago

Closed 7 months ago

Last modified 10 days ago

#10752 closed defect (bug) (fixed)

Uploading new media to existing posts/pages backdates file location

Reported by: dpie Owned by: pento
Milestone: 4.9 Priority: normal
Severity: minor Version: 2.8.4
Component: Media Keywords:
Focuses: Cc:

Description

Using WP 2.8.4, when uploading new media files to a page or post that has already been published, the new file is added in the /UPLOAD_DIR/year/month/ directory that corresponds to the original page/post publication date, rather than the file upload date.

Also, the correct file-upload-date-based directory is created (if it does not already exist), but the file is still placed in the older incorrect directory.

Example: Assume the following...

On /wp-admin/options-misc.php:

  • "Store uploads in this folder" (referred to above as UPLOAD_DIR) is set to "wp-content/uploads" or any other location, such as "files"
  • "Organize my uploads into month- and year-based folders" is checked

On an existing Page:

  • Page has a published date of 3/1/2008
  • File a_test_file.jpg is uploaded on 9/1/2009
  • UPLOAD_DIR is set to "wp-content/uploads", has 777 permissions, and contains no subdirectories or files

WordPress 2.6.x and below would have created the following:

  • /wp-content/uploads/2009/09/a_test_file.jpg

However, WP 2.8.4 is creating:

  • /wp-content/uploads/2008/03/a_test_file.jpg
  • /wp-content/uploads/2009/09

This issue was previously mentioned on the wordpress.org forums as being a known issue with WP 2.7.1: http://wordpress.org/support/topic/254786

Change History (14)

#1 follow-up: @azaozz
9 years ago

This is actually a "feature" (can't find the ticket at the moment). Attachments are stored by the parent post date.

#2 @scribu
9 years ago

  • Keywords 2nd-opinion added; media file upload removed

#3 in reply to: ↑ 1 ; follow-up: @dpie
9 years ago

Replying to azaozz:

This is actually a "feature" (can't find the ticket at the moment). Attachments are stored by the parent post date.

Even if this is the new standard WP attachment behavior, the upload should not be creating an empty directory for the current year+month.

Using the publication date rather than the file upload date might make sense for a timestamped Post, but it doesn't make sense for years-old Pages (in which the pub date is largely irrelevant).

#4 @nacin
8 years ago

  • Milestone changed from Unassigned to 3.1

#5 @nacin
8 years ago

  • Keywords needs-patch added; 2nd-opinion removed
  • Milestone changed from Awaiting Triage to Future Release

the upload should not be creating an empty directory for the current year+month.

needs-patch

#6 in reply to: ↑ 3 @cathlaura
6 years ago

  • Cc cathlaura added

Replying to dpie:

Even if this is the new standard WP attachment behavior, the upload should not be creating an empty directory for the current year+month.

Using the publication date rather than the file upload date might make sense for a timestamped Post, but it doesn't make sense for years-old Pages (in which the pub date is largely irrelevant).

Could this be turned into 2 tickets? One is a bug - the empty directory being created. Two is a feature request - it'd be great if under Media Settings you could choose whether you wanted media uploads backdated to the publication date of the post/page they're attached to. Could separate out the options, so that you could e.g. backdate on posts but not on pages.

#7 @scribu
6 years ago

"choose whether you wanted media uploads backdated to the publication date of the post/page they're attached to"

That sounds like a very arcane option that most users won't care about. Let's not do that.

#8 @wonderboymusic
4 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

No one has touched this in almost 2 years. I can't imagine this being a widely requested feature.

This ticket was mentioned in Slack in #core by sergey. View the logs.


22 months ago

#10 @pento
7 months ago

  • Keywords needs-patch removed
  • Milestone set to 4.9
  • Resolution wontfix deleted
  • Status changed from closed to reopened

#11 @pento
7 months ago

  • Owner set to pento
  • Status changed from reopened to assigned

#12 @pento
7 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 41964:

Media: Don't backdate media uploaded to pages.

When media is uploaded to a post, the upload directory is set according to the date of the post, so that the media URLs in the post match when the post was published.

A page is a slightly different beast, pages often live for years, and are regularly updated to stay relevant. This change causes media uploaded to pages to use the upload date to determine the upload directory.

Fixes #10752.

#13 @afercia
7 months ago

Worth considering a dev-note post for this change?

#14 @simonrcodrington
10 days ago

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 to 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)

Last edited 10 days ago by simonrcodrington (previous) (diff)
Note: See TracTickets for help on using tickets.