id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
16692,Add hook to allow plugins to implement custom $wp->parse_request() logic to support arbitrary custom URLs,mikeschinkel,nacin,"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.
",enhancement,closed,normal,3.5,Rewrite Rules,3.1,normal,fixed,has-patch commit,mikeschinkel@… mpretty@… landwire sirzooro mike@… ben@… georgemamadashvili@…