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

WordPress Trac noreply at wordpress.org
Fri Jan 23 09:30:48 UTC 2015


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

Comment (by Denis-de-Bernardy):

 I don't like this last patch, as it introduces potential localization
 problems.

 Prepending or appending a hyphen might technically be numeric, but it
 doesn't get caught be the rewrite regex, and that's the only thing that
 counts. Imho, it's a better option that trying to introduce some arbitrary
 string that screams "translate me".

 Along similar lines, we could prepend and/or append a colon `:` to the
 post's slug instead of a hyphen, in order to get urls like `/2015/01/:23/`
 or  `/2015/01/:23:/`. (This is assuming, of course, that sanitize_title
 wouldn't balk at the input. Whereas it actually might...)

 Anyway, my concern is these potential solutions don't really fix the
 problem. They merely sweep things under the rug in the hopes of not
 allowing the bug in the future while not addressing the multitudes of .
 That and the other solutions discussed here merely stick to sweeping it
 under the rug so as to try to avoid it from occurring.

 If the latest patch or a variation thereof gets applied, I'm left
 wondering what to do with the existing posts on my site that led me to
 report a bug, and I'd gather other reporters in the thread are left asking
 for more as well.

 Be it #22592, #26974, #22592 or #24294, #20185, #26641, the issue seems to
 invariably breaking down to one of:

 - `/yyyy/mm/slug/` conflicting with `/yyyy/mm/dd/`
 - `/yyyy/slug/` conflicting with `/yyyy/mm/`
 - `/slug/` conflicting with `/yyyy/`

 On my own site, I disabled day links. It's not a one-size fits all
 solution, since for all I know I'd like these day links to get recognized
 in the event a user tries an arbitrary day link, but it was the right
 thing to do.

 It seems to me that the better solution would be something like this:

 1. On permalink save (and on the next WP upgrade), test for permalink
 conflict potential. Suppose a two or four digit slug. Does a day rule
 catch it? The same for month and year rules. If yes, flag the structure as
 potentially leading to conflicts (as in year, month, day, or none).

 2. On the appropriate date archive type where we know conflicts may occur
 (year, month or day), try treating the offending parameter as if it was a
 post ID. This is a nearly free query -- we're looking for a single post.
 If a post is found, serve the expected post. If not, either fallback to
 serving the date archive as usual, or redirect to something appropriate
 (e.g. day url to month url, month url to year url, year url to blog url).

 The upside of this suggestion is it "just works" from the end-user's point
 of view. I may be wrong, but I can't imagine a site owner caring the
 slightest bit about offending date archives having a slightly non-standard
 behavior if he opted for a permalink structure that basically invites
 potential conflicts.

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


More information about the wp-trac mailing list