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

[WordPress Trac]

#3964: Aggressive matching in rewrite.php leads to "nothing matches" errors with
custom rewrite endpoints
----------------------+-----------------------------------------------------
 Reporter:  jhodgdon  |        Owner:  westi   
     Type:  defect    |       Status:  assigned
 Priority:  normal    |    Milestone:  2.2     
Component:  General   |      Version:  2.1.2   
 Severity:  normal    |   Resolution:          
 Keywords:  rewrite   |  
----------------------+-----------------------------------------------------
Old description:

> 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.

New description:

 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:

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

 and WordPress thinks it is the post in category "foo" with slug "param"
 (which doesn't exist).

 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#comment:5>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software