[wp-hackers] Make WP_Rewrite eaiser to use

[Sam Angove]

On 2/6/06, David House <dmhouse at gmail.com> wrote:
>
> Are you proposing we give up on the API idea?

No. But I'm not sure this is the *right* API idea. Yes, my
super-complicated multi-var plugin was an edge case, but almost
certainly so is someone wanting to add a single arbitrary rewrite
rule.

I don't think the proposed API simplifies *enough*, because the
implementations it replaces aren't very hard -- just mostly
undocumented. I think it's better to dramatically simplify the few
most obvious cases, inflexible as that may be, and leave the rest to
the current super-flexible love love plugin API.


* post permalink tag (i.e. Skippy's problem).
 The ideal solution there is a callback and automatic filtering on
'post_link'. Even better would be a global $rewritereplace array used
for every link, removing the need for explicit filters on post_link
and year_link and day_link and page_link and the dozen others.


* plugin page redirect
 This is the *only* use I can imagine for a single arbitrary rewrite
rule. Probably a redirect from $home/somename/ to
index.php?do_my_plugin_thang=true, which will in turn lead to some
kind of template. Ideally these people don't need to register query
vars at all, since they could (should) all be sharing some
API-controlled "plugin_page" var. [^1]


* adding tags to the end of post permalinks, i.e. westi's add_endpoint()
  I have two plugins that use something like this to load custom post
templates, so obviously I like it. [^1]


[^1] What's the best practice for templates? Embedded like the new
plugin admin pages? In themes? In a plugin's own directory? Special
location in wp-content? If the API enforces a certain way then it'll
be adopted.


I don't see add_feed() as primarily a rewrite thing, but it's a good
idea and there's no reason not to have it. add_base(), not so much.