WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#14238 closed defect (bug) (duplicate)

WordPress prevents pages with numeric slugs

Reported by: vividvisions Owned by:
Milestone: Priority: normal
Severity: major Version: 3.0
Component: Permalinks Keywords: needs-patch
Focuses: Cc:

Description

Numeric slugs are prevented by a preg_match against the slug in Line 2,555 of wp-includes/post.php:

preg_match( '@^(page)?\d+$@', $slug )

If the slug is numeric only, a suffix is added.

Instead of just preventing numeric-only slugs, the function should check, if the permalink of the page is at odds with the configured permalink structure and only add the suffix if this is the case.

Change History (19)

comment:1 follow-up: @scribu5 years ago

the function should check, if the permalink of the page is at odds with the configured permalink structure

Doing that reliably is easier said than done, considering the permalink could be any combination of post ids, pagination numbers, years, months and days.

comment:2 in reply to: ↑ 1 @vividvisions5 years ago

Replying to scribu:

the function should check, if the permalink of the page is at odds with the configured permalink structure

Doing that reliably is easier said than done, considering the permalink could be any combination of post ids, pagination numbers, years, months and days.

True, but to shut numeric page slugs out isn't a solution either. This change broke our site because we have a lot of pages with numeric slugs representing postal codes. These pages are also grandchildren, so there's no way they interfere with our /%year%/%monthnum%/%day%/%postname%/ permalink structure.

comment:3 follow-up: @nacin5 years ago

The code is there because they didn't work, if I recall correctly. [13424], #11917. WP is unable to tell the difference between a numeric slug and a page number.

comment:4 in reply to: ↑ 3 @vividvisions5 years ago

Replying to nacin:

The code is there because they didn't work, if I recall correctly. [13424], #11917. WP is unable to tell the difference between a numeric slug and a page number.

Thanks for the links! Strange, because we never experienced any trouble with numeric page slugs. Aren't page numbers always prefixed with "/page/", at least with pretty urls activated?

comment:5 @nacin5 years ago

/my-post-slug/2/ works too, for better or worse...

comment:6 @scribu5 years ago

Aren't page numbers always prefixed with "/page/", at least with pretty urls activated?

That might change: #12507

comment:7 @vividvisions5 years ago

I see. So IMHO, WP has to get smarter in terms of resolving URLs and spotting possible conflicts when a new page or post is created. Since a page structure should never have the same URL as a post, page numbers of a post really shouldn't matter since they're only a suffix to a unique permalink. For instance: /page1/page2/345/ could never interfere with /2010/07/08/postname/ as long the slug of page1 isn't numeric, whether the post is paged or not.

To spot conflicts in wp_unique_post_slug, my first idea was to take the configured permalink structure, create a set of regular expressions of possible combinations and match them against the URL of the newly created page. If there could be a problem, tell the user or add a suffix to the slug. Or am I naive? ;-)

comment:8 @scribu5 years ago

Actually, you already have a set of regular expressions at hand. That's how the rewrite system works currently. The trick would then be to remove the regular expressions that are supposed to match the newly created page.

Speaking of the rewrite system, see #12935.

comment:9 follow-up: @vividvisions5 years ago

Yes, I know. Thanks for the link, this looks quite interesting.

But the problem remains wp_unique_post_slug since it will always reject numeric slugs for pages. Step one would be to change this function to accept any page slug as long as there is no possible conflict. Maybe my idea above works, I'll look into that.

Step two would be to enhance the URL resolving, so that WP isn't confused anymore when it encounters numeric slugs for pages. A neat URL routing mechanism like described in #12935 would help a lot.

comment:10 @aspirelondon5 years ago

This issue should not span over to pages as they are both hierarchical and are allowed to have overlap URLs and dont have the issues with regard to pagination, so even if the issue isnt resolved for posts, it should be addressed for pages?

comment:11 in reply to: ↑ 9 @mikeschinkel5 years ago

  • Cc mikeschinkel@… added

Replying to vividvisions:

Step two would be to enhance the URL resolving, so that WP isn't confused anymore when it encounters numeric slugs for pages. A neat URL routing mechanism like described in #12935 would help a lot.

Agreed, and thanks for referencing. I'm anxious to work on ticket #12935; hope to get a break in client projects soon (or a client that wants me to do it!)

comment:12 @debashish4 years ago

I second supporting numeric slugs. My webzine had been using slugs of the format MMYY (for monthly issues, example http://nirantar.org/0405) since quite a while and now I notice with Wordpress 3.0.1 that these are no more supported which is disgusting.

comment:13 @nacin4 years ago

If I had to guess, they would work for /%post_id% only, which is what you happen to have. Otherwise the rewrite rules will do some serious damage across the board.

One alternative could be for a plugin to enable them, and in turn all /%page% endpoints would be killed off in favor of /page/%page%. Anything we need to do in core to support that in a plugin, I'm fine with.

comment:14 @gyrus4 years ago

  • Cc gyrus added

Another vote for supporting numeric slugs. Just upgraded to 3 and it broke a major aspect of a major client site (conferences where each year's conference is archived with a parent page for the year). An example URL would be:

/conferences/dec-asia/2011/

I can't see how this would clash with anything or be in need of out-and-out blocking. For now I've had to comment out that preg_match in post.php.

comment:15 @nacin4 years ago

  • Keywords needs-patch added; slug unique numeric page pages removed

It clashes with the rewrite rules that allow for /%page_id%, versus /page/%page_id%. I'd be willing to drop those entirely via a filter and thus allow numeric slugs.

Patches welcome.

comment:16 @nacin4 years ago

  • Milestone changed from Awaiting Review to Future Release

comment:18 @Viper007Bond4 years ago

  • Resolution set to duplicate
  • Status changed from new to closed

This ticket is a dupe of #5305

comment:19 @ocean904 years ago

  • Milestone Future Release deleted
Note: See TracTickets for help on using tickets.