[wp-trac] [WordPress Trac] #3964: Aggressive matching in rewrite.php leads to "nothing matches" errors with custom rewrite endpoints

WordPress Trac wp-trac at lists.automattic.com
Mon Mar 12 18:42:12 GMT 2007


#3964: Aggressive matching in rewrite.php leads to "nothing matches" errors with
custom rewrite endpoints
----------------------------+-----------------------------------------------
 Reporter:  jhodgdon        |       Owner:  anonymous
     Type:  defect          |      Status:  new      
 Priority:  low             |   Milestone:  2.3      
Component:  Administration  |     Version:           
 Severity:  normal          |    Keywords:           
----------------------------+-----------------------------------------------
 In a plugin, I call add_rewrite_endpoint to add a custom endpoint to the
 rewrite rules, and then cause a refresh of the rules by calling
 $wp_rewrite->flush_rules(). I add a suffix endpoint called "foo" to the
 rewrite rules, for a variety of situations, including post permalinks (in
 my case, "foo" is actually a language choosing parameter).

 My permalink structure is set to /%category%/%postname%/

 So, it's working fine on a post, category, page, etc. -- my suffixes are
 recognized and I can set the language and then find the post. But when I
 go to the home page and add suffixes, to get a permalink like:

 http://www.example.com/blogdir/foo/param

 the query fails, because the above it matches the post-with-page-suffix
 rewrite rule:

 (.+?)/([UC/]+)(/[0-9]+)?/?$

 and WordPress thinks it is the post in category "foo" with slug "param"
 (which doesn't exist). Note: I had to type in UC instead of using the up-
 caret character, to get around WIKI formatting issues.

 It's also a problem on feeds, where

 http://www.example.com/blogdir/feed/foo/param

 matches the same matching rule, and WordPress thinks it is the post in
 category "feed/foo", with slug "param". That .+ at the beginning of the
 rule is pretty permissive.

 I do have a rule:

 foo(/(.*))?/?$

 but it is farther down in the list than the rule above, and so the rule
 above takes precidence.

 I am not sure how to fix this... any ideas? The API doesn't allow for
 upping the precedence of rules. For now I have just made my plugin use a
 GET instead of permalink endpoint for the blog's home page and for feeds,
 but it is rather annoying.

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


More information about the wp-trac mailing list