[wp-trac] [WordPress Trac] #32903: Url request order of priority - why "search" 3rd, after category, tag but before author, date, post etc?

WordPress Trac noreply at wordpress.org
Thu Jul 2 15:35:40 UTC 2020


#32903: Url request order of priority - why "search" 3rd, after category, tag but
before author, date, post etc?
-----------------------------+------------------------
 Reporter:  luciandavidescu  |       Owner:  (none)
     Type:  enhancement      |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  Permalinks       |     Version:  1.5
 Severity:  normal           |  Resolution:  duplicate
 Keywords:                   |     Focuses:
-----------------------------+------------------------
Changes (by earnjam):

 * keywords:  dev-feedback =>
 * status:  new => closed
 * version:  4.2.2 => 1.5
 * resolution:   => duplicate


Old description:

> I'm not too good at hooking into internal WP function, neither do I know
> if this particular hook could even be done (no documentation as far as I
> was able to search). I have this
> (http://stackoverflow.com/questions/31170657/redirecting-404-to-search-
> with-pagination-on-404-template/) situation where I need that the URL
> request be parsed into a search after anything else was exhausted.
>
> By trial and error, I found that there is a list of priorities whenever
> an url is requested. First, Wordpress will test if it's a category, if
> match serve, else test if tag, if match serve, else try a search.
> Anything else (author, date, custom taxonomy, post! etc) is parsed only
> after.
>
> I know that this particular issue of mine wouldn't warrant any effort,
> but on the other hand, if there are no hard constraints preventing it,
> search would be much better suited at the very end of this queue. It's
> more logical that a search is absolutely the least specific type of url
> and it may also find it's way in numerous other applications.
>
> So, IMO, url requests should be interpreted as a search only as the very
> last resort, either by default or at least via some documented hook into
> the code.

New description:

 I'm not too good at hooking into internal WP function, neither do I know
 if this particular hook could even be done (no documentation as far as I
 was able to search). I have this
 (http://stackoverflow.com/questions/31170657/redirecting-404-to-search-
 with-pagination-on-404-template/) situation where I need that the URL
 request be parsed into a search after anything else was exhausted.

 By trial and error, I found that there is a list of priorities whenever an
 url is requested. First, WordPress will test if it's a category, if match
 serve, else test if tag, if match serve, else try a search. Anything else
 (author, date, custom taxonomy, post! etc) is parsed only after.

 I know that this particular issue of mine wouldn't warrant any effort, but
 on the other hand, if there are no hard constraints preventing it, search
 would be much better suited at the very end of this queue. It's more
 logical that a search is absolutely the least specific type of url and it
 may also find it's way in numerous other applications.

 So, IMO, url requests should be interpreted as a search only as the very
 last resort, either by default or at least via some documented hook into
 the code.

--

Comment:

 Duplicate of #20067.

 This is based off the order in which the default rules are registered
 inside `WP_Rewrite->rewrite_rules()`

 It's been this way for a long time and there are very few recorded
 examples of it being a problem, so it seems like a pretty rare edge case.

 There haven't been any updates on this ticket 4+ years, but the rules
 should be significantly filterable enough that you can change them to meet
 your unique requirements.

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


More information about the wp-trac mailing list