[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