[wp-trac] [WordPress Trac] #5305: permalinks broken when article name is numeric

[WordPress Trac]

#5305: permalinks broken when article name is numeric
-------------------------------------+---------------------------
 Reporter:  thomask                  |       Owner:  valendesigns
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  4.2
Component:  Permalinks               |     Version:  2.3.1
 Severity:  major                    |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+---------------------------
Changes (by valendesigns):

 * keywords:  has-patch needs-testing dev-feedback => has-patch needs-
               testing


Comment:

 @boonebgorges Thank you for testing my patch. Also, I really like your
 iteration, it's very clean and concise.

 To address using `pre_get_posts`, my thinking was doing it that way first
 would make it easier to test and iterate on. I just wasn't sure of the
 best place to jump in and take over. You seemed to have found it though.

 As for `<!--nextpage-->`, this is something that does not act in the same
 manner as the last patch. For example, say I have a `/%year%/%postname%/`
 permalink structure and I create a post named '02' and I try and view any
 day archive in February, the post takes over. The way I had it setup was
 that it took over only if `<!--nextpage-->` was being used. And then, only
 for the pages it uses. So that means if I have 2 pages for the '02' post,
 then `/2015/02/1/` & `/2015/02/2/` would match a page, but `/2015/02/3/`
 would pass and the date archive would be shown instead. So even though
 `setup_postdata()` is where the current page count happens, we need to do
 our own logic to establish the paging boundaries and avoid introducing a
 regression.

 I used `zeroise()` in an attempt to normalize input so it returned in a
 date format with a leading zero. However, after second thought, that logic
 may be somewhat flawed due to the reasons you mentioned above with '2' &
 '02' being the same as a date, but not as a post. The real issue is that
 the `0` is not passed in the query var, so it doesn't match the '02' post
 name format. I guess the question should be why is the leading zero being
 stripped away from the query var? We might want to start looking in that
 direction to avoid a second query and/or using `zeroise()`. If that can't
 be changed, then yes we'll likely need to do a second
 `get_page_by_path()`.

 Something to note, is that `get_page_by_path()` cannot find posts without
 titles. It will always return `null` in that situation. So in order to
 resolve that, we need to have the second check in place or update the
 logic in `get_page_by_path()` to allow for checks against `ID` and not
 just `post_name`. In either case, we should find a way to address
 resolving posts without titles where the ID collides with a date.

 I realized yesterday that the `post_type` filter was not needed when I
 tested the patch further by creating a very simple CPT. I quickly found
 out that it was a pointless filter and I had every intention of removing
 it, but got sidetracked on something else. It would seem you beat me to
 it. ;)

 I only briefly tested your new patch, but I'll put it through its paces
 and lob back an update on Monday. Overall though, I think we're getting
 pretty close to having a final solution to this long standing issue.

 Thanks again for taking the time to rework the code and give feedback.
 Cheers!

--
Ticket URL: <https://core.trac.wordpress.org/ticket/5305#comment:65>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform