Conflict between post and page slugs/permalinks when permalink setting is set to /%postname%/

[jamescollins]

If Dashboard -> Settings -> Permalinks is set to /%postname%/, it is possible to create both a page and a post with the same slug. When viewing via the frontend, the page is always displayed.

I would have thought that WordPress should prevent a post and a page from having the same permalink.

Steps to reproduce:

1. Create and publish a page with any slug. eg. ​http://domain.com/test/.
2. Create and publish a blog post with the same slug. Wordpress says the permalink for the blog post is ​http://domain.com/test/, but when you visit that URL it displays the page instead.

I can reproduce this on my 2.9.2 install, as well as 3.0 trunk. I'm guessing the bug is present in earlier versions of WordPress as well.

Possibly related: #11863

I feel like there is another ticket for this, but can't find it.

In any case, I can't see any easy way to fix this, because pages are allowed to have non-unique slugs across hierarchies. One possibility might be to check for this particular permalink structure and modify the unique slug generation accordingly to ensure that no pages have that slug - but it would only work for new/updated posts - old ones would still have a conflict. Bit flimsy.

This problem still occurs in 3.1.1.

It persists even after the Page is sent to Trash (the user gets a 404 instead of the Post), until the Page is emptied from the Trash.

The suggestion by solarissmoke is better than nothing. Ideally it would have to work both ways, ie if permalink is /%postname%/ then:

1) check that no posts have this slug when generating top level page slug
2) check that no top level pages have this slug when generating post slug

It may not cover everything:

a) it may not just be posts and pages we have to worry about (some people strip /category/ from URL for category pages for example);
b) there is a very small chance that /%category%/%postname%/ posts could clash with a second level page.

but they are real edge cases and as I said, it's better to do something than nothing.

Related: #16687

#23166 was marked as a duplicate.

Replying to stephencronin:

It persists even after the Page is sent to Trash (the user gets a 404 instead of the Post), until the Page is emptied from the Trash.

#21970 would fix that.

#23300 was marked as a duplicate.

Seriously, till now we never fixed this. That's quite a shame.

#23300 was marked as a duplicate.

wp_unique_post_slug() returns a unique slug within the given post type.

Seems like we have 3 options:

1. Always prevent posts, pages (and CPTs?) from having the same slug (require unique slugs across all post types). Since having the same slug is actually fine with most permalink structures, this sounds like an unnecessary restriction.
2. Only do the above for the /%postname%/ permalink structure. However, if the structure changes to /%postname%/ later (after the page and the post are created), we'll still end up with a conflict.
3. Leave this to a plugin, since wp_unique_post_slug() is filterable (#14111).

I personally think that the permalink conflict is to be expected in this case, so the 3rd option sounds acceptable to me.

Replying to SergeyBiryukov:

wp_unique_post_slug() returns a unique slug within the given post type.

Correction: As noted in comment:1, pages are allowed to have non-unique slugs across hierarchies:
​http://core.trac.wordpress.org/browser/tags/3.5/wp-includes/post.php#L3103

I disagree with leaving this to a plugin. The problem is only for post vs pages when the permalink structure is "/%postname%/".

It seems for me that the 2nd option is the way to go. Obviously changing to the structure will ending up with a conflict but that can be plugin territory.

13459.patch​ is an attempt to implement option 2.

Exact same patch from SergeyBiryukov, reapplied to current codebase

Simple unit test added to cover the case when the same title is used to create a post and a page AND permalinks are set to /%postname%/

Just checking for '/%postname%/' isn't going to cover it completely. Will at least need to standardize trailing slashes on that check. Let's take a look at this early in 3.7.

It appears this is no longer restricted to JUST using /%postname%/ as your permalink.

On 3.8 and 3.9-alpha I can make both a page and a post with the same slug. Using /%year%/%postname%/

For me this is a feature, not a bug. I can place pages into blog lists. Very useful, hope you'll never fix it.

Related: #15665, #24612.

#27297 was marked as a duplicate.

#28900 was marked as a duplicate.

Actually needs to change parameter of get_post_types function, currently it only return "page" Post type.

#28960 was marked as a duplicate.

It also depends which order the page/post is created. So we need to check the permalink structure in both hierarchical and non-hierarchical.

Added some tests to ensure it is working when different combinations of post/page are made.

#31704 was marked as a duplicate.

#32426 was marked as a duplicate.

#32795 was marked as a duplicate.

See comment:1:ticket:32795 for potential options.

#23166 was marked as a duplicate.

#23166 was marked as a duplicate.

Since [34690], attachments now have pretty permalinks too.

This increases the chances of clashing with post slugs, see #24612 and comment:8:ticket:24612.

We should make sure that attachments and posts cannot have duplicate slugs if /%postname%/ structure is used.

For reference, some of this functionality may (or may not) have changed in #18962.

Subdirectory multisite could clash also and may be related with 12002 (Closed and included in 4.4 next release).

@SergeyBiryukov the patch is exploding, do we need to do this in 4.4?

I've added a few changes in attachment:13459.3.diff​.

• Consolidate the checks into a single query rather than two. The extra check we want to perform is to confirm uniqueness across more post types, which we can do with an IN.
• Avoid post and attachment slug collisions as Sergey suggested.

In attachment:13459.4.diff​

• Moved the tests to wpUniquePostSlug.php
• Added tests for post slug/attachment slug collisions. A post slug can't collide with an attachment slug when the permalink structures are the same, but they can collide when the permalink structures are different.

Seems like '/%postname%/' === $wp_rewrite->permalink_structure won't catch a static prefix, e.g. '/blog/%postname%/'. Would that still cause a conflict if there's a 'Blog' page with subpages?

Perhaps the preg_match() check from [35679] could be used.

Seems like '/%postname%/' === $wp_rewrite->permalink_structure won't catch a static prefix, e.g. '/blog/%postname%/'. Would that still cause a conflict if there's a 'Blog' page with subpages?
Perhaps the preg_match() check from [35679] could be used.

We can drop this into our logic for looking up a unique slug for a post (post_type = post). This would be complex to use for page slugs, because that query ensures uniqueness is tied to diffferent post_parent levels / URL path hunks.

Do you think that's a must-fix use-case for this issue, or an edge case? This is not the only collision of this flavor we will see, e.g. %tax_base%/%tax_term% collisions with a subpage.

@SergeyBiryukov said:

Seems like '/%postname%/' === $wp_rewrite->permalink_structure won't catch a static prefix, e.g. '/blog/%postname%/'. Would that still cause a conflict if there's a 'Blog' page with subpages?

I've created a plugin to approach the problem in a more holistic way — ​Cool slugs. It uses the rewrite API to determine if a URL namespace is already occupied. This has the potential to avoid all problems of this nature. What do you think?

cc @boonebgorges, who also has a natural affinity to wp_unique_post_slug().

Can i use that "plugin" until someone decides to release the/a fix ?
(not sure I can ask here...)
Thanks.

#38005 was marked as a duplicate.

#38022 was marked as a duplicate.

See also #34972. Since the changes for #1914 were applied, slug/permalink conflicts are more likely between unattached media items and pages, regardless of the post permalink settings.