WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#32795 closed defect (bug) (duplicate)

Duplicate permalinks when using /%postname%/

Reported by: j.conti Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.1
Component: Permalinks Keywords:
Focuses: Cc:

Description (last modified by SergeyBiryukov)

Hi,

More problems with this this ticket #18962

Fist, you need the permanlinks set to /%postname%/.

Then, you can add a new page with the title Slug Test, the permanlink will be slug-test (added by WordPress) after that, add a new post with the Title Slug Test, and WordPress will add the same permanlink slug-test

Both permanlinks are created by WordPress, but only one works because only one slug-test can exist. http://example.com/slug-test/

This is a very big problem...

Change History (7)

#1 @boonebgorges
5 years ago

  • Keywords needs-patch needs-unit-tests added
  • Milestone changed from Awaiting Review to Future Release
  • Summary changed from Duplicate permanlinks to Duplicate permalinks when using /%postname%/
  • Version changed from 4.2.2 to 4.1

The same question comes up in https://core.trac.wordpress.org/ticket/18962#comment:2 and https://core.trac.wordpress.org/ticket/18962#comment:10. It was not addressed in [30158], the changeset that ultimately resolved #18962.

There are three options here:

  1. Do nothing. If this happens to someone, it's their fault for using /%postname%/.
  2. In wp_unique_post_slug(), change the duplicate slug check based on the permalink structure. If it's /%postname%/, and $post_type = 'post', dupe checks should include pages as well as posts.
  3. In wp_unique_post_slug(), have a special case for 'post' that never allows it to share a slug with a page.

IMO, 1 is not acceptable. 2 and 3 are similar. 2 is less restrictive. It only forces uniqueness when it's really required based on the current permastruct. But it will cause problems when someone has permastruct /%year%/%postname%/, creates a post and a page with slug foo, and then changes to /%postname%/. Choice 3, while unnecessarily restrictive in many cases, is more foolproof. 3 seems like the right way to go.

Needs a patch and unit tests.

#2 follow-up: @MattyRob
5 years ago

+1 for choice 3.

There are no circumstances where a post should share a slug name with any other published content IMO - whether that be a page or an image / attachment.

#3 in reply to: ↑ 2 ; follow-up: @boonebgorges
5 years ago

Replying to MattyRob:

+1 for choice 3.

There are no circumstances where a post should share a slug name with any other published content IMO - whether that be a page or an image / attachment.

Well, it seemed to be the consensus in #18962 that there's no reason for WP to place undue restrictions on duplicate slugs for different kinds of content. The problem in this ticket is specific to permalink clashes, but other post types (like attachments) can never have permalinks like example.com/foo/, so they're not forbidden from having duplicate slugs. If you would like to enforce a stricter sense of uniqueness on your sites, there's a filter for that :)

#4 in reply to: ↑ 3 @MattyRob
5 years ago

Replying to boonebgorges:

Well, it seemed to be the consensus in #18962 that there's no reason for WP to place undue restrictions on duplicate slugs for different kinds of content. The problem in this ticket is specific to permalink clashes, but other post types (like attachments) can never have permalinks like example.com/foo/, so they're not forbidden from having duplicate slugs. If you would like to enforce a stricter sense of uniqueness on your sites, there's a filter for that :)

Understand that fully - still don't agree with it :)

The scalability of WordPress is going to run the risk of future edge cases where we realise that duplicate slug names are not a good idea. Avoid this forever and ASAP by ensuring that future content is not allowed a duplicate slug name would be way to achieve this.

#5 @SergeyBiryukov
5 years ago

  • Description modified (diff)

#6 @SergeyBiryukov
5 years ago

  • Keywords needs-patch needs-unit-tests removed
  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #13459.

This ticket was mentioned in Slack in #core by sergey. View the logs.


5 years ago

Note: See TracTickets for help on using tickets.