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

[solarissmoke]

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.

[stephencronin]

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.

[solarissmoke]

Related: #16687

[SergeyBiryukov]

#23166 was marked as a duplicate.

[SergeyBiryukov]

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.

[ocean90]

#23300 was marked as a duplicate.

[markoheijnen]

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

[markoheijnen]

#23300 was marked as a duplicate.

[SergeyBiryukov]

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.

[SergeyBiryukov]

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

[markoheijnen]

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.

[SergeyBiryukov]

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

[moraleida.me]

Exact same patch from SergeyBiryukov, reapplied to current codebase

[moraleida.me]

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%/

[markjaquith]

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.

[Ipstenu]

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%/

[digiscience]

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

[SergeyBiryukov]

Related: #15665, #24612.

[jeremyfelt]

#27297 was marked as a duplicate.

[SergeyBiryukov]

#28900 was marked as a duplicate.

[datta.parad]

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

[SergeyBiryukov]

#28960 was marked as a duplicate.

[MikeHansenMe]

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

[MikeHansenMe]

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

[SergeyBiryukov]

#31704 was marked as a duplicate.

[SergeyBiryukov]

#32426 was marked as a duplicate.

[SergeyBiryukov]

#32795 was marked as a duplicate.

[SergeyBiryukov]

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

[helen]

#23166 was marked as a duplicate.

[helen]

#23166 was marked as a duplicate.

[SergeyBiryukov]

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.

[SergeyBiryukov]

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

[anonymized_14169293]

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

[wonderboymusic]

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

[ericlewis]

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.

[ericlewis]

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.

[SergeyBiryukov]

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.

[ericlewis]

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.

[ericlewis]

@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().

[Reiniepress]

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

[ocean90]

#38005 was marked as a duplicate.

[peterwilsoncc]

#38022 was marked as a duplicate.

[mdgl]

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.

[SergeyBiryukov]

#41848 was marked as a duplicate.

[SergeyBiryukov]

#52214 was marked as a duplicate.

[SergeyBiryukov]

#54031 was marked as a duplicate.

[SergeyBiryukov]

#55209 was marked as a duplicate.

[wpmarkuk]

I found this issue today too. Creating a page and a post with the same slug results in the post being inaccessible. This seems to be because both have the same slug and the page always wins.

If the permalinks are set to /%postname%/ the I am assuming that posts and pages are using the same "namespace".

I think the solution here, is that if the permalink structure is set like this, when WordPress saves the post slug, it needs to check both posts and pages for others with the same slug. I assume this it is only checking posts at this time. This was probably a legacy as to when permalinks didn't allow /%postname%/.

I don't know what happens when the slug is set, but I assume that there is a check for other posts with the same slug (maybe a query). If pages were included in this check it could solve the problem.

[peterwilsoncc]

This was discussed in the ​dev-chat in Slack earlier. In an earlier comment additional conflicts are mentioned so it would be good to have each of these investigated too so the bug is fixed rather than half a bug.

There are a number of ​structure tags available on the permalinks screen, some notes on collisions for each would be valuable:

• content slugs matching a custom post type's slug
• pages with an apparent date structure: /2022/some-page (also consider months, days, etc)
• including uncommon components such as author, category

Setting up a pull requests with some initially broken tests would be most helpful. If it's decided that some items aren't in scope, then follow up tickets can be created.

Any changes would need to be made to the function wp_unique_post_slug()

[wpmarkuk]

I am not sure how to to this:

Setting up a pull requests with some initially broken tests would be most helpful.

Therefore, hopefully someone else can assist here.

[webcommsat]

I think this post by @desrosj might help @wpmarkuk ​https://make.wordpress.org/core/2020/02/21/working-on-trac-tickets-using-github-pull-requests/

[Updated] Thanks for being involved to help move this issue forward.
Replying to wpmarkuk:

I am not sure how to to this:

Setting up a pull requests with some initially broken tests would be most helpful.

Therefore, hopefully someone else can assist here.

[bobbingwide]

I've documented my view of the problem at ​https://herbmiller.me/requirements-for-permalink-postname/

In the post I list several steps to reproduce the problem, what I believe to be the requirements to be satisfied and have tabulated some of the alternative permalink structures and the results obtained accessing duplicated entries.

I've briefly considered two different approaches to the problem. I'm coming to the conclusion that parse_request() needs to be changed. The logic associated with use_verbose_page_rules being the main sticking point when duplicates exist.

In my opinion any broken tests should cover the round trip, confirming that the post being requested is the one that's returned to the user.

If required I'll copy paste my post into this TRAC.

[SergeyBiryukov]

#55451 was marked as a duplicate.

[SergeyBiryukov]

#55472 was marked as a duplicate.

[bobbingwide]

I've written some round trip black box PHPUnit tests demonstrating two problems.

See ​https://github.com/bobbingwide/dupes where you'll find the tests and notes on how to run them. They rely on wp_remote_get() actually requesting the content for the permalink and then seeing if it got what it was asking for.

The tests currently produce two failures.

1. The original problem, where the duplicate page is returned instead of the post.
2. The inability to retrieve the post by its post ID, when there's a duplicate page.

There are other failing scenarios for which I've not yet written tests.

[thelmachido]

This bug was recently flagged on Gutenberg's Git Repo ​https://github.com/WordPress/gutenberg/issues/41720 after 6.0 was released.

We can reproduce the same when a test site is using the Classic Editor plugin which led us to believe that this might be core related.

[fidoboy]

Why not use a customizable base slug for unattached media items? Something like this:

www.domain.com/**media-item**/the-filename-here/

As far as I know, the biggest issue with this thing is specially on sites with thousands of media items and pages, it's very difficult or almost impossible to detect conflicts. Or may be that someone could develop a plugin to scan all library and pages to detect duplicates and alert.

The big problem with this is that is causing random 404 errors and the most of times it's very difficult to detect or to know that it's due to a duplicated permalink into the website structure. Most of times it's causing racing conditions and that's why sometimes a link work as expected and other times it didn't.

[audrasjb]

As per today's Old Ticket Triage session, @petitphp proposed to refresh the patch. Assiging him as ticket owner :)

[verygoode]

Still present in 6.2.

1. Spin up a new 6.2 site (no plugins, core theme)
2. Ensure permalink settings are set to Post name on wp-admin/options-permalink.php
3. Create a new page titled permalink-test
4. Create a new post titled permalink-test
5. Observe that the unique post IDs share the same slug and conflict

[SergeyBiryukov]

#59243 was marked as a duplicate.

[sabernhardt]

#60941 was marked as a duplicate.

[nikunj8866]

Patched to resolve duplicate post and page slug issues. Now, it will add '-2' if the post or page slug already exists.

[kadiwala]

#62668 was marked as a duplicate.

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

[sukhendu2002]

Hi @audrasjb, I've opened a PR to add some tests. Could you please take a look? Let me know if any improvements are needed. Thanks!

Adding on top of the PR #8257 submitted by @sukhendu2002, I've refactored a little of the code and added some extra tests, to check if the slug will adjust not only to the next slug but to subsequent slugs. I've also have removed all the redundant tests that were already been tested in previous unit-cases.

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

[SirLouen]

Test Report

Description

✅ This report validates that the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8257.diff

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Chrome 136.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ✅ Issue resolved with patch.
2. 🟠 Unit tests could be improved, check Notes

Additional Notes

• Patch tests provided by @sukhendu2002 look good, but they are testing things that are redundant (already being covered). I'm providing a new PR that aims to focus on this ticket report, taking his code as baseline
• @audrasjb @jorbin, 15 years later, ​this patch appears to be ready to go into next 6.8.2

[sabernhardt]

#63505 was marked as a duplicate.