[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):

 So as working on this even though I have projects with intense deadlines
 waiting as I want to move it forward and as it is a guilty pleasure for
 me.  Figuring out where to start has not been easy but I decided to start
 both writing down some goals that I think are important and I also did
 some deconstructing of the rewrite rules after a vanilla install of
 WordPress 3.0 beta. ('''''Note''' I write the goals here so they can be
 open to discussion; my views are not as important as the views of the core
 dev team and the collective views of the WP developer community, but at
 least my views are a starting point for discussion''.)

 Here are the goals I wrote down.  I will probably think of more but at
 least these are a start:

 == NAMING ==
  * The existing system is referred to as the "'''''Rewrite'''''" system.
  * The new system is referred to as the "'''''Routes'''''" system.
  * These goals define "'''''Compatible'''''" as rewrite first, routes
 second.
  * These goals define "'''''Transitional'''''" as routes first, rewrite
 second.

 == GOALS ==
  * '''Compatibility'''
                  * '''Drop-in replacement for `$wp->parse_request()`'''.
                  * Support first implemented via plugin thus potentially
 requiring new hooks.
                  * No potential compatibility issues except potential edge
 cases with rewrite hooks in transitional mode.
                  * Introduces as few new concepts and structures as
 absolutely necessary.
                  * Supports `query_vars` as before.
                  * As much as possible routes should feel '''familiar'''
 to WordPress devs and themers.
                  * As compatible as possible with all plugins with
 selectable modes to change priority.
                  * Matching existing external URL structure behavior a
 high priority
                  * Priority of matching internal rewrite hook behavior
 selectable by mode
                  * Enable plugins to register support for routes vs.
 rewrite otherwise rewrite assumed.
                  * Mode to support internal usage of rewrites as primary,
 routes as secondary.
                  * If possible, "sniff out" requirement to support rewrite
 mode based on hooks in use.
                  * "No compatibility" mode should enable development of an
 easy-to-use URL configuration admin module.
                  * Aim to deprecate rewrite after sufficient calendar time
 and suffient plugins convert to routes.
                  * Default compatibility mode changes over releases, from
 rewrite, to compatible, to transition, to routes.
                  * Near-term releases of WordPress delivered in "most
 compatible" mode.

  * '''Functionality'''
                  * Easy to understand for the coder.
                  * Reasonably easy to code advanced routes.
                  * Minimal new class/structure/syntax required.
                  * Able to define most routes using existing URL template
 formats.
                  * Internally views URL paths as collections of slash-
 separated segments.
                  * Primarily focuses on URL path segments but can address
 partial segments and multi-segments.
                  * Maps URLs to query_vars, just like rewrite.
                  * Mimics existing WordPress design patterns
 (`register_*()` functions,etc.)
                  * Fully flexible regarding URL layout.
                  * Logically recursive; Allows any path tree to be a
 branch of any path segment.
                  * Post_type agnostic; allow any post type to come in any
 order.
                  * Heterogeneous parent-child paths; i.e. a page can be a
 parent of a custom post type.
                  * Explicitly stated: full support for paths like
 `/%category%/%post%/`.
                  * Advanced matching; allows matching by literal,
 pattern(regex), or function.
                  * Full control of path segment order; supports fine grain
 matching in any combination.
                  * Group common endpoints (path segment branches) to be
 applied to branches in the path tree.
                  * Allows assignment of literal matches post_types and/or
 taxonomies.
                  * As performant as rewrites in standard case; acceptibly
 performant in 99 percentile.
                  * Optimizable and tunable; certain routes can be
 preloaded by design.
                  * Self-tuning on cron task; most commonly used routes
 pre-routed.
                  * Easily supports basic structure of slashes and
 segments, i.e. `/segment/segment/.../`
                  * Enables support for structure beyond slashes and
 segments, albeit more complex.
                  * Order of URL path segment assignment mostly unimportant
 (except for regex & functions).

 I'll post the deconstruction of URLs next.

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