[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:  3.1 
Component:  Permalinks    |     Version:  3.0 
 Severity:  normal        |    Keywords:      
--------------------------+-------------------------------------------------

Comment(by mikeschinkel):

 Replying to [comment:29 jacobsantos]:
 > I wouldn't worry about the callback at this point, I only wanted to see
 what your thoughts were on it and if you were going to have it as part of
 your plan. I think having a better Routes would allow for a controller
 callback system to be built on top of it for a controller system.

 Cool. And agreed.

 > Right now, I guess it is possible to specify a controller component on
 top of the current system, similar to the way the custom post types work.
 However, I think all of the current code is spread out in to 3 different
 classes.

 Yeah, kind of.

 Which 3 specific classes are you referring to?

 > Are you working to consolidate the functionality into separate classes
 and then use the new code back in those classes? Or create new classes
 from new code?

 Not sure if I understand the question 100%, but I will try to answer it
 anyway.

 My plan for this ticket is to (hopefully) make a drop-in replacement for
 `$wp->parse_request()` using the path segment based routes instead of full
 path regular expression rewrites.  I envision doing my best not to affect
 any other part of WordPress with this route system.

 I would like to implement it as a plugin (at least initially) which means
 I will likely be requesting one or more hooks to enable this.  I want to
 make it as compatible as possible with existing plugin and hooks and of
 course fully compatible with core.

 I want to enable full fidelity with the external view of a website; IOW a
 site should be able to switch completely from rewrites to the routing
 system without changing or having to 301 redirect a single URL. (Of course
 I'd like to give the site owner a constant definable option to use a
 cleaner set of URLs without the messy edge cases for those not concerned
 with backward compatibility, but that's a nice-to-have, not a must-have.)

 I think it will be possible to switch to a "compatibility mode" where core
 could use this system instead of rewrites and behave 100% identically.
 This could be made possible by having core either back-end the existing
 functions `add_rewrite_tag()`, `add_permastruct()` and others or to bypass
 them and use methods of specifying URLs like (similar to) those shown
 above. I anticipate enabling both of these options, most likely selectable
 via defining a constant in `wp-config.php`.

 I also believe it will be possible in this compatibility mode for most
 plugins that interact with rewrites to use the rewrite system and thus
 still transparently support the route system; i.e. if plugins use
 functions like `add_rewrite_tag()` and `add_permastruct()` this should be
 possible.  However, for those functions that do string search-and-replace
 on the existing rewrite rules, like the hook I showed above, I think it
 will likely not be possible to have them transparently support the route
 system.

 I'm also envisioning dual usage where rewrites can continue to be used but
 if not matched then the routes system will take over. I see this as how
 compatibility with most older plugins could be maintained while having
 core and newer/updated plugins could use the route system.  Additionally,
 this could be switched to where the route system could take priority and
 fall back to the rewrite system if desired by the user by them defining a
 constant in `wp-config.php`.

 Assuming this routes system were adopted into core for v3.1 (for example)
 I envision that the most compatible mode would initially be used on both
 new installs and upgrades. Then maybe by v3.3 after most currently
 maintained plugins have switched to using routes WordPress could enable a
 "transitional mode" for new installs where the route system takes
 priority. OTOH upgrades to existing installs would continue to use
 compatibility mode for v3.3. Later, say maybe v3.5 WordPress could allow
 upgrades to use routes if upgraded from a version that already supports
 routes. Eventually, maybe v4.0, rewrites would be gone completely (or
 maybe not.)

 Definable constant selectable modifications to this behavior could include
 having WordPress inspect plugins for likely incompatibility and offer to
 switch to transitional compatibility mode if no likely incompatibilities
 are found.  Further there could be a "no compatibility mode" that advanced
 users could select to ensure that their plugins and themes only use routes
 and not rewrites. And I'm sure there might even be other "modes" to
 address concerns I've yet to recognize.

 Finally I envision the ability for plugins to register support for routes
 which could also include plugins registering that they do not use rewrites
 even if they don't affect URL routing so that routes could be used during
 an upgrade as soon as all plugins in use support routes.

 Does that answer the question?

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