[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:  defect (bug)   |     Status:  new
 Priority:  normal         |  Milestone:  Awaiting Review
Component:  Rewrite Rules  |    Version:  3.1
 Severity:  normal         |   Keywords:  has-patch dev-feedback
---------------------------+------------------------------------
 This ticket addresses the issues raised in the following two tickets:

  - [http://core.trac.wordpress.org/ticket/12935 Evolve the URL Routing
 System]
  - [http://core.trac.wordpress.org/ticket/16687 %postname% permalinks
 should not trigger verbose rewrite rules]

 The first ticket (#12935) was an exploration and proposed
 ''"[http://www.netlingo.com/word/boil-the-ocean.php boiling the ocean]"'';
 frankly not a smart approach in hindsight.

 The second ticket (#16687) proposes to implement a hack to resolve one
 very comment use-case that is not well handled as of v3.1 while
 unfortunately ignoring the subsequent most common use-cases that will
 arise that are also not well handled.

 This ticket actually '''aims to support the second ticket''' by providing
 a generic way that a plugin can front-end the `parse_request()` of the
 `global $wp` variable which will then allow core to generically address
 the issue raised on #16687 but also allow plugins to add support for the
 subsequent common use-cases that arise after ticket #16687 is resolved.

 As a validation of the need for this
 [http://wordpress.stackexchange.com/questions/9419/remove-taxonomy-slug-
 from-a-custom-hierarchical-taxonomy-permalink/10162#10162 here is a
 question on WordPress Answers that I answered by showing how to front-end
 `$wp-parse_request()` by subclassing the `WP` class], but clearly
 '''''only one plugin can use that technique at a time''''' so it's not a
 technique that should be used except by a site owner. This ticket aims to
 give safe plugins the ability to extend `$wp->parse_request()` so that
 plugins don't subclass `WP` to the detriment of users who need to use two
 plugins that use the same technique.

 What the patch for this ticket does is add a `'wp_parse_request'` hook and
 uses it to call `$wp->parse_request()` instead of the currently hard-coded
 call to  `$wp->parse_request()`. This will allow a plugin to remove the
 action and add its own, and if the plugin does not find an appropriate URL
 match then it can be free to delegate matching back to
 `$wp->parse_request()`.  It would be a technique that could be used by
 skilled plugin developers to really enhance the ability to route URLs in
 WordPress without negatively affecting those who are not using it in any
 way.

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