[wp-trac] [WordPress Trac] #12935: Evolve the URL routing system

[WordPress Trac]

#12935: Evolve the URL routing system
--------------------------+-------------------------------------------------
 Reporter:  mikeschinkel  |       Owner:  ryan      
     Type:  enhancement   |      Status:  new       
 Priority:  normal        |   Milestone:  Unassigned
Component:  Permalinks    |     Version:  3.0       
 Severity:  normal        |    Keywords:            
--------------------------+-------------------------------------------------

Comment(by mikeschinkel):

 Replying to [comment:2 scribu]:
 > Why do some routes have %% and some don't? i.e. 'top10' vs '%month%'

 Hi @scribu, really glad to have you comment.  I remember you were the one
 to express interest in this concept when I mentioned it briefly on wp-
 hackers a few months ago.

 '''The routes with %% are rewrite tags vs. literal matches'''; i.e.
 'top10' is literal whereas '%month%' can accept any value that matches the
 regex, i.e.: for the following URL %match% matches '2010' and 'top10'
 match 'top10', of course. So this:
 {{{
 http://example.com/%year%/top10/
 }}}
 Matches:
 {{{
 http://example.com/2010/top10/
 }}}
 That is equivalent to the following rewrite rule
 {{{
 [([0-9]{4})/top10/?$] =>
 index.php?post_type=post&year=$matches[1]&taxonomy=post_tag&term=top10
 }}}
 This would be similar to this (assuming I did this right; I ''still'' have
 trouble with WordPress' rewrite system even though I've used to numerous
 times):
 {{{
 add_rewrite_tag('%year%','([0-9]{4})');
 add_permastruct('top10', '%year%/top10');
 }}}
 I believe we can do it in a way that {{{get_option('rewrite_rules')}}} are
 tested first for backward compatibility and then the routes are inspected
 if the old rewrite rules don't apply. However, we could make it so any
 calls to {{{add_rewrite_tag()}}}, {{{add_rewrite_rule()}}} and
 {{{add_permalink()}}} build the route structure instead of rewrite rules
 and thus convert most rewriting to routing in a very short period of time.

 Additional benefits of this approach would include:

  * '''Simplicity''': I think we'll find it will take a lot less code for
 this than is currently in rewrite.php (~2000 lines.)
  * '''Understandability''': I think it will be much easier for people to
 understand this tree structure than the global flat mapping of the rewrite
 rules.
  * '''Flexibility''': We'll be able to use different options down
 different path segments. If some paths want to disable fe
  * '''Eliminate Clutter''': Many of the rewrite rules are not needs but it
 was easier to code it that way, i.e. most pages and custom post types
 don't need feeds.
  * '''Robustness''': Since all routes wouldn't be path-segment local we
 can add new routes along a path segment being much less concerned with
 conflicting rewrite tags.
  * '''Reuse Routes''': With this structure it would be very easy to define
 feed, pages, comments, trackbacks, attachments, etc. in one place and
 reference it anywhere needed as opposed to the current structure which has
 that information duplicated for every rewrite. In a system I'm working on
 with 5 custom post types there are 60 rewrite rules dealing with
 attachments. I think attachments can be defined as five routes and
 referenced only where needed.
  * '''Performance''': This approach would allow for the literal tags to be
 stored as array keys and thus will be faster to match against than running
 100+ reasonably complex regexes in order to find the last regex that
 matches the "about" page URL.  See the psuedo-code showing the difference
 for loading a root page with routes vs. with rewrites (yes the full route
 code will be much more complicated):

 With routes:
 {{{
 if (isset($wp_routes[$request])) {  // Once...
   load_page($request);
 }
 }}}

 With rewrites:
 {{{
 foreach ( $rewrite as $match => $query) {   // 100 times or more...
   if (preg_match("#^$match#",$request,$matches) {
     load_page($request);
   }
 }
 }}}

 Hopefully this explains?

 P.S. Just to be comprehensive, the rewrite tags would still be global
 because they would map onto a single URL. But ensure rewrite tags are
 unique is easier (and more flexible) than requiring URL path segments to
 be unique across all URLs that are not part of the same path segment
 branch. Also, routes would be processed inside {{{$wp->parse_request()}}}
 where rewrites are currently being processed.  {{{$wp->query_posts()}}}
 would execute exactly as it already does, thus when I say backward
 compatible I'm referring to creating a drop-in replacement for
 {{{$wp->parse_request()}}}.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/12935#comment:3>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software