[wp-trac] [WordPress Trac] #5305: permalinks broken when article name is numeric
WordPress Trac
noreply at wordpress.org
Sat Feb 21 20:47:46 UTC 2015
#5305: permalinks broken when article name is numeric
-------------------------------------------------+-------------------------
Reporter: thomask | Owner:
Type: defect (bug) | valendesigns
Priority: normal | Status: assigned
Component: Permalinks | Milestone: 4.2
Severity: major | Version: 2.3.1
Keywords: has-patch needs-testing dev- | Resolution:
feedback | Focuses:
-------------------------------------------------+-------------------------
Comment (by boonebgorges):
valendesigns - Thanks for your work on this. Broadly speaking, I think the
strategy here is good: when a date query is detected and the permalink
structure contains `%postname%`, give precedence to a post matching the
postname, rather than the corresponding date archive.
I have some implementation suggestions, some large and some small. See
[5305.7.diff].
First, a 'pre_get_posts' callback doesn't seem like the right place to do
this. For one thing, while you've given it a priority of 1, it's still
possible for plugins to intervene before it runs, which could cause
various problems. It's also not clear to me why we would want the proposed
to be unhookable. It seems to me that the proper place is in
`WP_Query::parse_query()`, right after the existing date checks.
I've also simplified (and, I think, generalized) your `$token_index`
trick. What we really care about is the location of `%postname%`, and
whether it's preceded directly by `%year%` or `%month%` or whether it's in
the 0th position. My patch tests this more directly.
I also combined the two functions into a single method. By returning from
the method whenever we know there's nothing to do, we prevent the nesting
that I'm assuming you were trying to avoid.
I simplified `<!--nextpage-->` support as well. Most of the necessary work
- like the nextpage count - is done for us later on in `setup_postdata()`.
No need to repeat it here. The only thing required is to translate the
date query var into 'page'.
I've left a `@todo` comment on the `zeroise()` block. There is still a bug
here. Month and day URL chunks are parsed properly with or without the
leading zero (`([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/page/?([0-9]{1,})/?$'`
- note the {1,2}`). This means that `2015/2` is a potential clash when
post_name=2, in addition to `2015/02` and post_name=02. Does this mean we
have to do two calls to `get_page_by_path()`?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/5305#comment:63>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list