WordPress prevents pages with numeric slugs

[vividvisions]

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.

[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.

[vividvisions]

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.

[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.

[vividvisions]

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?

[nacin]

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

[scribu]

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

That might change: #12507

[vividvisions]

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? ;-)

[scribu]

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.

[vividvisions]

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.

[aspirelondon]

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?

[mikeschinkel]

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!)

[debashish]

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.

[nacin]

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.

[gyrus]

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.

[nacin]

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.

[nacin]

​http://wordpress.org/extend/plugins/allow-numeric-stubs/

[Viper007Bond]

This ticket is a dupe of #5305