Integer URI segments in slugs not pulling proper page

[jchristopher]

I'm currently building an image gallery consisting of some parent/children pages. The structure is as follows:

e.g. gallery/birthday/2009/

My permalink structure is set to WordPress 'Day and name' setting, and all page slugs were created by WordPress (I didn't edit them myself).

Browsing the admin area is as expected, pages are nested properly and editing works fine as well. The trouble arises when browsing the site itself. I'm able to navigate to the gallery/ page as well as the gallery/birthday/ "category" but as soon as I click the link to go to gallery/birthday/2009/ the gallery/birthday/ page loads. I print_r($post) and WordPress thinks it's displaying the parent page instead of /gallery/birthday/2009/

I changed the slug for the 2009 page to be 'test' and all was well, the proper page was pulled. I again changed the slug to '1000000' and the parent page was again pulled. It appears as though slugs with URI segments composed strictly of numbers cause things to break.

[jchristopher]

After some additional testing, creating a child page with the /2009/ page (and /1000000/ page) as a parent does work as expected.

Also, when firing functions such as wp_list_pages or get_pages the /2009/ and /1000000/ pages are pulled properly as children pages and include the proper permalinks.

[miqrogroove]

This has more to do with the internal "rewrite" system. It considers any trailing numeric tokens to be page numbers, so it's literally trying to find page number 2009 of a multi-paged birthday article.

I believe there is a valid bug here, however. WordPress really does not support numeric slugs and should be preventing you from using them.

[jchristopher]

I thought that might be the case, and agree that if it's established functionality, the auto-generated slug should be written in such a way to work around the issue. Thank you for the feedback!

[miqrogroove]

I'm in favor of rejecting numeric slugs outright. Another possible solution is to treat numeric slugs as duplicates and append the "-1" suffix, as is already done if you try to use "feed" as a slug. I'm not in favor of that idea because I would never want "2009-1" as a slug, but it does solve the immediate problem.

[miqrogroove]

Adds is_numeric to the hierarchical slugs blacklist.

[miqrogroove]

Created and tested new patch on 3.0-alpha.

Before Patch: Created new items with numeric slugs, and observed no problem with numeric slugs for posts. Pages, on the other hand, can be mistaken for /yyyy/ links at the root, or for /about/n/ paged links at the child position.

After Patch: When Publishing a new page, if the slug is numeric, "-2" will be suffixed to the slug automatically. Pages can then be viewed normally with the slug suffix.

[miqrogroove]

use ctype_digit, which is more conservative than is_numeric

[miqrogroove]

use preg equiv of ctype_digit

[nacin]

(In [13424]) Reject numeric page slugs as they don't work, and force a suffix. Props miqrogroove see #11917

[miqrogroove]

Thanks nacin! Note: ticket left open due to ongoing discussions in IRC about how to make a "better" fix.

[miqrogroove]

This is going to need more work per #8948

[miqrogroove]

Also disallow 'page1' type slugs.

[nacin]

(In [13717]) Prevent page(\d+) slugs, and force a suffix. props miqrogroove. fixes #11917. see #8948

[hakre]

Can confirm the issue for WP 2.9.2. It is giving 404s on numeric post slugs.