Uploading new media to existing posts/pages backdates file location

[gaelgwp]

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!

[SergeyBiryukov]

Introduced in [9663] / [9675].

[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.

[gaelgwp]

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

[desrosj]

I'm going to reopen this one because based on the feedback above, it's something that could be considered should someone choose to invest the time exploring what a solution would look like.

This PR aims to allow plugins to disable backdating for certain type of posts.

Trac ticket: https://core.trac.wordpress.org/ticket/47726

[antonvlasenko]

My PR aims to allow plugins to disable backdating for certain types of posts (default post types expect pages plus custom post types).
Should this be allowed for custom post types only or default post types as well?
What's your take on this?