[wp-trac] [WordPress Trac] #16692: Add hook to allow plugins to implement custom $wp->parse_request() logic to support arbitrary custom URLs

[WordPress Trac]

#16692: Add hook to allow plugins to implement custom $wp->parse_request() logic to
support arbitrary custom URLs
------------------------------------+------------------------------
 Reporter:  mikeschinkel            |       Owner:
     Type:  enhancement             |      Status:  reviewing
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Rewrite Rules           |     Version:  3.1
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+------------------------------

Comment (by mikeschinkel):

 Replying to [comment:13 scribu]:
 > I think the reason all these approaches feel clunky is because the part
 you're interested in, the rewrite logic, should be in WP_Rewrite in the
 first place.

 I very much disagree with that.  The current `WP_Rewrite` system is
 probably the clunkiest aspect of WordPress which I'm hoping we can get
 deprecated by 4.0 by proving via a plugin that there is a much better way.

 The current `WP_Rewrite` system is overly complex because there is an
 impedance mismatch between the `WP_Rewrite` system ''(a list of regexes
 with almost no metadata)'' and the underlying use-case it is trying to
 model ''(a tree of nodes and leafs where each node and/or leaf potentially
 needs unique metadata based on it's parent path.)''

  '''''The current system just does not ''"match"'' the underlying use-
 case'''  ''(pun intended)'' and as such just gets more and more
 complicated as requirements get added to WordPress. Isn't it time to think
 different?''

 A great analogy is that `WP_Rewrite` is like SOAP-based web services
 ''(i.e. overly complex)'' vs. a URL routing system that is analogous to
 REST-based web services ''(simple and elegant.)'' Implementing a match
 system within `WP_Rewrite` would make it harder to prove the value of an
 alternate approach in a plugin vs. embracing a straight replacement of
 `$wp->parse_request()`.

 FYI this weekend I started working on an alternate URL routing system that
 simply replaces `parse_request()` and is it coming together in an
 extremely promising manner.  Given the complexity of the use-cases that
 must be matched a `$wp_rewrite->match_rule` would not enable needed
 functionality so for what I'm working on it that's a non-starter.

 If you will keep an open mind towards this until you have a chance to work
 with it I think you may change your mind on the need to implement
 something within the WP_Rewrite system.

 > So, a better approach would be to create a match_rule() method in
 `WP_Rewrite` and then hook that to a `'match_rule'` action called from
 `parse_request()`.

 `WP_Rewrite` has too much baggage and overhead on each page load. Having
 both systems active when we'll ultimately only need one is overhead that
 should be avoided.

 Of course I can achieve what I need by subclassing `WP` and if I'm given
 no other alternative that's what I will do and in it I will implement my
 own `'wp_parse_request'` hook, I just hope that I don't have to default to
 that approach for 3.2.

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