WordPress.org

Make WordPress Core

Opened 5 months ago

Last modified 5 months ago

#47726 new enhancement

Uploading new media to existing posts/pages backdates file location

Reported by: gaelgwp Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 2.7
Component: Media Keywords: needs-patch
Focuses: Cc:
PR Number:

Description (last modified by SergeyBiryukov)

This is a follow-up to #10752.

Hello,

I just want to know, who thought this was a great idea? This causes so many media managing problems.. Why can't we just simply get to the July folder to get our images uploaded in July?

And about the [41964] : Good fix and at the same time it's bad, it only fixes it for pages! And it's not like pages are that different from posts or custom posts, they can serve the same purpose, so why would it be different?

Hoping to get a fix soon!

Change History (4)

#1 @SergeyBiryukov
5 months ago

  • Description modified (diff)

#2 @SergeyBiryukov
5 months ago

  • Version changed from 5.2.2 to 2.7

Introduced in [9663] / [9675].

#3 follow-up: @pento
5 months ago

  • Milestone changed from Awaiting Review to Future Release

Thank you for this report, @gaelgwp!

The exception for pages is intentional, as described in [41964]: pages will often be created when the site is first made, and then will be updated at various intervals. For example, a company may have an "About Us" page that lists their employees with photos, and is updated when someone joins or leaves the company. So, the photo uses the upload date, as that's more relevant than the date of when the page was created.

Going back to the original behaviour introduced in [9663], posts are a much more time-based medium, so attachments to a post should have a matching date.

Looking at [9663] in particular, this was introduced long before custom post types existed, so didn't need to take this use case into account.

So, I think there's a reasonable case to match the page behaviour for CPTs that live for a long time, where the publication date has little relevance. Unfortunately, there currently isn't a flag for clearly identifying these post types.

If someone wants to explore what such a flag would look like, we can look at committing it.

#4 in reply to: ↑ 3 @gaelgwp
5 months ago

Replying to pento:

Thank you for this report, @gaelgwp!

The exception for pages is intentional, as described in [41964]: pages will often be created when the site is first made, and then will be updated at various intervals. For example, a company may have an "About Us" page that lists their employees with photos, and is updated when someone joins or leaves the company. So, the photo uses the upload date, as that's more relevant than the date of when the page was created.

Going back to the original behaviour introduced in [9663], posts are a much more time-based medium, so attachments to a post should have a matching date.

Looking at [9663] in particular, this was introduced long before custom post types existed, so didn't need to take this use case into account.

So, I think there's a reasonable case to match the page behaviour for CPTs that live for a long time, where the publication date has little relevance. Unfortunately, there currently isn't a flag for clearly identifying these post types.

If someone wants to explore what such a flag would look like, we can look at committing it.

Hello @pento ,

Thanks a lot for replying, yes it seems it was introduced 10 years ago and people probably didn't get that it functions like this or didn't bother to discover why.
Well you could test if post_type is not equal to post to exclude custom post types, but then again I would still have a problem with the posts themselves :(

Do you think there's a way to safely remove this "feature" in a plugin or a theme so I could remove this function from my wordpress websites and it will continue to exist / not produce any bugs through Wordpress updates?

Regards,
Gael

Note: See TracTickets for help on using tickets.