Generate UUID for media slugs if attachment pages are inactive.

[peterwilsoncc]

For hierarchical post types, WordPress compares slugs with those used by attachments to avoid collisions. The effect of this is that a page can not have the same slug as an uploaded image. Source code.

This remains the case now that attachment pages have been disabled by default.

As the attachment pages slugs are now largely meaningless on new WordPress installs, the media slugs should not reserve nice names and prevent pages from using them. For example, a media file with the name about-us.png should not prevent the page about-us from existing.

Steps to reproduce above:

1. Install WordPress 6.4 or later
2. Go to Dashboard > Media > Add new media file
3. Upload the file about-us.png
4. Go to Dashboard > Pages > Add new page
5. Title the page About Us and publish
6. Observe the page's slug is about-us-2

If the attachment pages are disabled, the URLs for the media pages (as opposed to the image) can use wp_generate_uuid4() for the slug to avoid reserving nice names and preventing their use on available permalinks.

[oglekler]

And what will happen if attachment pages were disabled and then this condition is changed?

Personally, I had a lot of troubles with images and page names because I am always naming images describing what is there, like: white-t-shirt.png or our-team.jpg and ended up just adding "-image" to the end of all images I am uploading.

It looks like this tickets is already a candidate for 6.7.

[peterwilsoncc]

Replying to oglekler:

And what will happen if attachment pages were disabled and then this condition is changed?

The attachment pages would work but the URL would use the name assigned at image attachment, for example /my-page/11223344-5566-7788-99AA-BBCCDDEEFF00. While it's not impossible that it will happen, as the pages need to be re-enabled via a plugin or a WP-CLI command It's safe enough to consider this an edge case.

As an implementation detail, it's possible that WP could use the pre_wp_unique_post_slug hook to allow plugins to remove the feature without enabling attachment pages.

Personally, I had a lot of troubles with images and page names because I am always naming images describing what is there, like: white-t-shirt.png or our-team.jpg and ended up just adding "-image" to the end of all images I am uploading.

This is what I'm hoping to avoid the need for. There's few things worse than having a page show as /our-team-2 because the photo on the page is called our-team.jpg and claimed the slug our-team as a result.

Do you have a preferred approach to the very ugly URLs to handle the edge case when attachment pages are inactive? I'm happy to consider alternatives and rename the ticket accordingly.

[antpb]

With beta approaching I am going to move this to 6.7 to more accurately give us an idea of what can be finished in the 6.6 milestone. Currently without a patch this one seems like itll need another cycle for investigation and writing a patch.

[junaidbhura]

@peterwilsoncc Would something simpler like post ID work, instead of UUID?

Trac Ticket: Core-60569

## Problem Statement:

• In WordPress, slugs for attachments have historically been compared with slugs used by hierarchical post types, preventing pages from having the same slug as uploaded media files. Despite attachment pages being disabled by default in recent versions, this restriction persists. This means that a page with a slug like "about-us" cannot coexist with an uploaded image named "about-us.png".

## Solution:

• This change modifies the way slugs are generated for attachments. Now, the file extension is appended after the attachment title to create its slug. If no extension is found, the attachment post type is appended instead. This adjustment ensures that pages can use slugs without being blocked by media file names, thereby preserving meaningful and intuitive URLs for pages.

## Details:

• Updated slug generation for attachments to append the file extension or attachment post type when no extension is present.
• Ensured compatibility with existing WordPress behavior regarding slug uniqueness and hierarchical post types.

## Testing:

• Tested the modification with hierarchical post types and uploaded media files to verify correct slug generation.
• Checked compatibility with various configurations of WordPress installations, including default and custom setups.

## Impact:

• Resolves a longstanding limitation where slugs for attachment files could block pages from using the same name.
• Allows pages to freely use slugs without being obstructed by media file names.
• Promotes better usability and flexibility for WordPress site administrators.
• Enables more intuitive URL structures and improved content management.
• Aligns with modern expectations of slug management in hierarchical post types and media attachments within WordPress.

[debarghyabanerjee]

Replying to junaidbhura:

@peterwilsoncc Would something simpler like post ID work, instead of UUID?

Post ID won't work because the slug is getting generated before inserting the post.

[peterwilsoncc]

Replying to debarghyabanerjee:

Post ID won't work because the slug is getting generated before inserting the post.

Thanks for that, I wasn't sure of the order of operations.

I also suspect post ID could "steal" helpful slugs, eg episode/20 for a podcast.

[debarghyabanerjee]

Replying to peterwilsoncc:

Replying to debarghyabanerjee:

Post ID won't work because the slug is getting generated before inserting the post.

Thanks for that, I wasn't sure of the order of operations.

I also suspect post ID could "steal" helpful slugs, eg episode/20 for a podcast.

I gave it a thought and tried appending the extensions after the post_name to generate the slug, but after further considerations, I don't think that would be a good choice either, so I will be switching to your idea of using UUID for slugs.

I will make the necessary changes and will push the code by today. Thanks :-)

[peterwilsoncc]

Replying to debarghyabanerjee:

I gave it a thought and tried appending the extensions after the post_name to generate the slug, but after further considerations, I don't think that would be a good choice either, so I will be switching to your idea of using UUID for slugs.

I will make the necessary changes and will push the code by today. Thanks :-)

Thanks for the pull request, it's always good to get other's ideas.

Let me know if you need assistance with the unit tests. I've subscribed to your pull request so will get any notifications of comments, commits, etc.