Make WP_Rewrite eaiser to use

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Make WP_Rewrite eaiser to use

David House
Reading through the recent thread concerning Scott Merril's troubles
with WP_Rewrite [1], I thought that we really should automate a lot of
what is in the final plugin [2]. People (well, Owen) have been asking
for a while that WP_Rewrite should be easier to use. I'm not proposing
a full rewrite of WP_Rewrite, but I do think we should provide more
API to help the mortal plugin authors understand it.

For example, here's my proposal for a couple of functions that should
make interacting with WP_Rewrite easier (if there's no disagreement
with the specification then I'll draft up some patches):

----------------------------------------------------------------------------
1. add_rewrite_rule(): A function for adding a straight rewrite rule.

Parameters:
* Regex to match
* URL to redirect to.

What it needs to do:
* Build a rewrite rule from the regex and redirect URL.
* Theoretically it could then filter rewrite_rules_array and add the
rules itself, but I think we should add a function to WP_Rewrite for
adding 'extra' rules that needn't be generated by
generate_rewrite_rules(). rewrite_rules() would then just tack on
these extra rules after the ones generated. These extra rules should
probably be stored in an option.

----------------------------------------------------------------------------
2. add_rewrite_tag(): Add a new tag (like %postname%):

Parameters:
* Name of tag
* Regex to match

What it needs to do:
* Get a query var name by stripping the % signs from the name of the
tag: trim($name, '%')
* Call $wp_rewrite->add_rewrite_tag() with the name, generated QV name
and regex.
* Add the QV as a query var (again, this could be done by filtering
query_vars but it might be nicer to add a function to the WP class
that stores 'extra' QVs like above)

Notes:
I was thinking about passing a callback to this function which would
be called with the contents of the QV when a request matched the regex
(so e.g. if the regex is ([0-9]{3}) as in skippy's case, we could
accept a callback to call when someone requests a Julian date, say,
/2006/32, passing 32), but I don't think this will be flexible enough:
people might want to hook onto parse_request, or pre_get_posts, or
parse_query, or many other hooks. So we can just do the
$wp_rewrite->add_rewrite_tag() bit and leave it up to the query author
to add their own hooks.

----------------------------------------------------------------------------

Examples:

To do something similar to what skippy was asking for, you'd do this:

http://xmouse.ithium.net/dmh-source/wp-rewrite-api.phps

[1]: http://comox.textdrive.com/pipermail/wp-hackers/2006-February/004511.html
[2]: http://www.skippy.net/secret/dayofyear.phps
--
-David House, [hidden email], http://xmouse.ithium.net
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

Stefano-10
Il Sun, 5 Feb 2006 15:36:09 +0000, David House <[hidden email]>
scrive:

>Reading through the recent thread concerning Scott Merril's troubles
>with WP_Rewrite [1], I thought that we really should automate a lot of
>what is in the final plugin [2]. People (well, Owen) have been asking
>for a while that WP_Rewrite should be easier to use. I'm not proposing
>a full rewrite of WP_Rewrite, but I do think we should provide more
>API to help the mortal plugin authors understand it.

+10 definitly! :)

>1. add_rewrite_rule(): A function for adding a straight rewrite rule.

...

>2. add_rewrite_tag(): Add a new tag (like %postname%):

I think this will be really usefull i'm getting a bit mad about
rewrite rule too and this would help a lot.

--

Stefano Aglietti - StallonIt on IRCnet - ICQ#: 2078431
Email: [hidden email] [hidden email]
Sites: http://www.40annibuttati.it (personal blog)
       http://www.wordpress-it.it (WordPress Italia)
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

Owen Winkler
In reply to this post by David House
David House wrote:
> Reading through the recent thread concerning Scott Merril's troubles
> with WP_Rewrite [1], I thought that we really should automate a lot of
> what is in the final plugin [2]. People (well, Owen) have been asking
> for a while that WP_Rewrite should be easier to use. I'm not proposing
> a full rewrite of WP_Rewrite, but I do think we should provide more
> API to help the mortal plugin authors understand it.

Well, a full rewrite of WP_Rewrite seems impractical, but the code that
is there is nigh incomprehensible.  I think much of the problem with
adding new rewrite rules is that it is very difficult to look at the
code, watch execution through it, and locate the best place to insert
anything new.

Perhaps adding a couple of extra API hooks for making rewriting easier
would be beneficial to the many plugin developers who have recently
expressed an interest in adding their own rules.  This doesn't solve the
more fundamental problem that the extant code is hard to read and, by
extension, maintain.

Owen

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

Peter Westwood
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Owen Winkler wrote:

> David House wrote:
>> Reading through the recent thread concerning Scott Merril's troubles
>> with WP_Rewrite [1], I thought that we really should automate a lot of
>> what is in the final plugin [2]. People (well, Owen) have been asking
>> for a while that WP_Rewrite should be easier to use. I'm not proposing
>> a full rewrite of WP_Rewrite, but I do think we should provide more
>> API to help the mortal plugin authors understand it.
>
> Well, a full rewrite of WP_Rewrite seems impractical, but the code that
> is there is nigh incomprehensible.  I think much of the problem with
> adding new rewrite rules is that it is very difficult to look at the
> code, watch execution through it, and locate the best place to insert
> anything new.
>
> Perhaps adding a couple of extra API hooks for making rewriting easier
> would be beneficial to the many plugin developers who have recently
> expressed an interest in adding their own rules.  This doesn't solve the
> more fundamental problem that the extant code is hard to read and, by
> extension, maintain.
>
I think a rewrite of WP_Rewrite should be possible.

I am getting to know it quite well at the moment trying to put together
a patch for this old trac ticket - http://trac.wordpress.org/ticket/301
(current inprogress patch attached)

I was considering looking at refactoring the code after I had this finished.

I have nearly working code which allows configuration of:

Author, Search, Comments and Feed permalinks. Getting the feed ones
working is somewhat of a pain but I am nearly there.

If we are to work on WP_Rewrite adding an api for registering generic
endpoint types looks like a good idea.  This would be some way of
registering the query var, permalink string and input/output handler
this could then in theory be used by both the core code and plugins for
things like feeds, trackbacks, ajax endpoints etc.

What do people think of this.

It would probably simplfy WP_Rewrite if it is made generic - it contains
a lot of duplicate code at present and also aid in the removal of some
of the feed types from the core to plugins and ideally the registration
functions described above should allow you to override someone elses
handler - this could have been used for things like the atom feeds where
the builtin  atom 0.3 feed could have easily been replaced by a plugin.

westi
- --
Peter Westwood
http://blog.ftwr.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD5mZ8VPRdzag0AcURAhGRAKCF+fmW9TcKu3oU4MhZLDmMRSCOVACdEa2r
HhD/fmTnFQ7GG25tJjr3IaI=
=nqDP
-----END PGP SIGNATURE-----

Index: wp-includes/classes.php
===================================================================
--- wp-includes/classes.php (revision 3504)
+++ wp-includes/classes.php (working copy)
@@ -862,14 +862,14 @@
  var $permalink_structure;
  var $category_base;
  var $category_structure;
- var $author_base = 'author';
+ var $author_base = 'writer';
  var $author_structure;
  var $date_structure;
  var $page_structure;
- var $search_base = 'search';
+ var $search_base = 'find';
  var $search_structure;
- var $comments_base = 'comments';
- var $feed_base = 'feed';
+ var $comments_base = 'discussion';
+ var $feed_base = 'syndicate';
  var $comments_feed_structure;
  var $feed_structure;
  var $front;
@@ -1095,8 +1095,13 @@
  return false;
  }
 
- $this->author_structure = $this->front . $this->author_base . '/%author%';
+ if (empty($this->author_base))
+ $this->author_structure = $this->front . 'author/';
+ else
+ $this->author_structure = $this->front . $this->author_base . '/';
 
+ $this->author_structure .= '%author%';
+
  return $this->author_structure;
  }
 
@@ -1110,7 +1115,12 @@
  return false;
  }
 
- $this->search_structure = $this->root . $this->search_base . '/%search%';
+ if (empty($this->search_base))
+ $this->search_structure = $this->front . 'search/';
+ else
+ $this->search_structure = $this->search_base . '/';
+
+ $this->search_structure .= '%search%';
 
  return $this->search_structure;
  }
@@ -1140,7 +1150,12 @@
  return false;
  }
 
- $this->feed_structure = $this->root . $this->feed_base . '/%feed%';
+ if (empty($this->feed_base))
+ $this->feed_structure = $this->front . 'feed/';
+ else
+ $this->feed_structure = $this->front . $this->feed_base . '/';
+
+ $this->feed_structure .= '%feed%';
 
  return $this->feed_structure;
  }
@@ -1155,8 +1170,19 @@
  return false;
  }
 
- $this->comment_feed_structure = $this->root . $this->comments_base . '/' . $this->feed_base . '/%feed%';
 
+ if (empty($this->comments_base))
+ $this->comment_feed_structure = $this->front . 'comments/';
+ else
+ $this->comment_feed_structure = $this->front . $this->comments_base . '/';
+
+ if (empty($this->feed_base))
+ $this->comment_feed_structure .= 'feed/';
+ else
+ $this->comment_feed_structure .= $this->feed_base . '/';
+
+ $this->comment_feed_structure .= '%feed%';
+
  return $this->comment_feed_structure;
  }
 
@@ -1178,10 +1204,10 @@
  function generate_rewrite_rules($permalink_structure, $paged = true, $feed = true, $forcomments = false, $walk_dirs = true) {
  $feedregex2 = '';
  foreach ($this->feeds as $feed_name) {
- $feedregex2 .= $feed_name . '|';
+ $feedregex2 .= '/' . $feed_name . '|';
  }
- $feedregex2 = '(' . trim($feedregex2, '|') .  ')/?$';
- $feedregex = $this->feed_base  . '/' . $feedregex2;
+ $feedregex2 = '(|' . trim($feedregex2, '|') .  ')/?$';
+ $feedregex = $this->feed_base . $feedregex2;
 
  $trackbackregex = 'trackback/?$';
  $pageregex = 'page/?([0-9]{1,})/?$';
@@ -1485,6 +1511,8 @@
  // Fetch the rewrite rules.
  $rewrite = $wp_rewrite->wp_rewrite_rules();
 
+ print_r($rewrite);
+
  if (! empty($rewrite)) {
  // If we match a rewrite rule, this will be cleared.
  $error = '404';
@@ -1538,12 +1566,16 @@
  if ((! empty($req_uri)) && (strpos($match, $req_uri) === 0) && ($req_uri != $request)) {
  $request_match = $req_uri . '/' . $request;
  }
+
+ echo "$match : $request_match \n";
 
  if (preg_match("!^$match!", $request_match, $matches) ||
  preg_match("!^$match!", urldecode($request_match), $matches)) {
  // Got a match.
  $this->matched_rule = $match;
 
+ print_r($matches);
+
  // Trim the query of everything up to the '?'.
  $query = preg_replace("!^.+\?!", '', $query);
 
@@ -1601,6 +1633,8 @@
 
  if ( isset($error) )
  $this->query_vars['error'] = $error;
+
+ print_r($this->query_vars);
  }
 
  function send_headers() {
Index: wp-admin/options-permalink.php
===================================================================
--- wp-admin/options-permalink.php (revision 3504)
+++ wp-admin/options-permalink.php (working copy)
@@ -75,6 +75,10 @@
 
 $permalink_structure = get_settings('permalink_structure');
 $category_base = get_settings('category_base');
+$author_base = get_settings('author_base');
+$search_base = get_settings('search_base');
+$comments_base = get_settings('comments_base');
+$feed_base = get_settings('feed_base');
 
 if ( (!file_exists($home_path.'.htaccess') && is_writable($home_path)) || is_writable($home_path.'.htaccess') )
  $writable = true;
@@ -155,7 +159,24 @@
 <?php endif; ?>
  <p>
   <?php _e('Category base'); ?>: <input name="category_base" type="text" class="code"  value="<?php echo $category_base; ?>" size="30" />
-     </p>
+     </p>
+<?php if ($is_apache) : ?>
+ <p><?php _e('If you like, you may enter a custom prefix for some of your other URIs here including Author, Search, Comments and Feed. For example, <code>/discussion/</code> could be used for your comments to make your links like <code>http://example.org/1980/01/01/my-post/discussion/</code>. If you leave this blank the default will be used.') ?></p>
+<?php else : ?>
+ <p><?php _e('If you like, you may enter a custom prefix for some of your other URIs here including Author, Search, Comments and Feed. For example, <code>/discussion/</code> could be used for your comments to make your links like <code>http://example.org/index.php/1980/01/01/my-post/discussion/</code>. If you leave this blank the default will be used.') ?></p>
+<?php endif; ?>
+ <p>
+  <?php _e('Author base'); ?>: <input name="author_base" type="text" class="code"  value="<?php echo $author_base; ?>" size="30" />
+    </p>
+ <p>
+  <?php _e('Search base'); ?>: <input name="search_base" type="text" class="code"  value="<?php echo $search_base; ?>" size="30" />
+    </p>
+ <p>
+  <?php _e('Comments base'); ?>: <input name="comments_base" type="text" class="code"  value="<?php echo $comments_base; ?>" size="30" />
+    </p>
+ <p>
+  <?php _e('Feed base'); ?>: <input name="feed_base" type="text" class="code"  value="<?php echo $feed_base; ?>" size="30" />
+    </p>
     <p class="submit">
       <input type="submit" name="submit" value="<?php _e('Update Permalink Structure &raquo;') ?>" />
     </p>

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

David House
On 05/02/06, Peter Westwood <[hidden email]> wrote:
> I think a rewrite of WP_Rewrite should be possible.

Perhaps it is, but I think we should add the API in first. At the
moments, plugins use $wp_rewrite, and if we refactor that then we'll
likely break them. Adding in a level of abstraction (and getting the
small number of plugin authors that currently use $wp_rewrite) means
we can refactor at a later date.

--
-David House, [hidden email], http://xmouse.ithium.net
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

David House
On 05/02/06, David House <[hidden email]> wrote:
> Perhaps it is, but I think we should add the API in first. At the
> moments, plugins use $wp_rewrite, and if we refactor that then we'll
> likely break them. Adding in a level of abstraction (and getting the
> small number of plugin authors that currently use $wp_rewrite) means
> we can refactor at a later date.

If anyone wants to add functions/edit stuff please do it at the wiki
page I've just set up to hold the specification for this API [1]. If
you add anything controversial mention it here as well so we can
discuss it.

[1]: http://codex.wordpress.org/User:DavidHouse/WP_Rewrite_API

--
-David House, [hidden email], http://xmouse.ithium.net
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

Kimmo Suominen-3
In reply to this post by Peter Westwood
On Sun, Feb 05, 2006 at 08:56:28PM +0000, Peter Westwood wrote:
> What do people think of this.

While working on this file, all those little English words should
be wrapped in __() so that they can be translated.  Please?

Best regards,
+ Kimmo
--
<A HREF="http://kimmo.suominen.com/">Kimmo Suominen</A>

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

Sam Angove
In reply to this post by David House
On 2/6/06, David House <[hidden email]> wrote:
> Reading through the recent thread concerning Scott Merril's troubles
> with WP_Rewrite [1], I thought that we really should automate a lot of
> what is in the final plugin [2].

I think we should arrange some clear code examples. Ryan's is great,
but it doesn't suit every use-case.

Are there any other hooks/filters that get convenience wrappers?
They're pretty convenient as-is. The current way is very flexible, and
it only looks verbose when it's for the sake of one query var -- I had
a plugin with about eight, and three times that many rewrite rules,
and it was very nice indeed.

Scott's plugin is only complicated because there's no good place to
modify other query variables -- changing the query string is hackish,
and parse_query might be too late if the wrong is_* variables have
already been set -- and it modifies the post permalink. The latter, at
least, can't be easily simplified.

> ----------------------------------------------------------------------------
> 1. add_rewrite_rule(): A function for adding a straight rewrite rule.
>
> [snip]
> * Theoretically it could then filter rewrite_rules_array and add the
> rules itself, but I think we should add a function to WP_Rewrite for
> adding 'extra' rules that needn't be generated by
> generate_rewrite_rules().

I don't have a problem with it, but why is filtering the array so bad?
The current way is very easy, and it's more elegant for adding
multiple rules.

function add_arbitrary_rules($rules) {
    $url = get_settings('home');
    $rules[$url.'/arbitrary/(wibble)/?$'] = 'index.php?var=$matches[1]';
    $rules[$url.'/arbitrary/(wobble)/?$'] = 'index.php?var=$matches[1]';
    return $rules;
}
add_filter('rewrite_rules_array', 'add_arbitrary_rules');



> ----------------------------------------------------------------------------
> 2. add_rewrite_tag(): Add a new tag (like %postname%):
>
> What it needs to do:
> * Get a query var name by stripping the % signs from the name of the
> tag: trim($name, '%')
> * Call $wp_rewrite->add_rewrite_tag() with the name, generated QV name
> and regex.
> * Add the QV as a query var (again, this could be done by filtering
> query_vars but it might be nicer to add a function to the WP class
> that stores 'extra' QVs like above)

Without your callback, does this do enough to make it worth the
bother? The query_vars filter is the easy bit anyway, and this API is
much less efficient if you're adding more than one QV.

Not a code reason, but FWIW I like having registration of query vars
separate since it makes the author more likely to remember to use
get_query_var() instead of $_GET. Since in my case that author is me,
aids to memory are very, very welcome... ;)
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

Sam Angove
In reply to this post by Peter Westwood
On 2/6/06, Peter Westwood <[hidden email]> wrote:
>
> I am getting to know it quite well at the moment trying to put together
> a patch for this old trac ticket - http://trac.wordpress.org/ticket/301
> (current inprogress patch attached)

It'll clutter the interface something shocking. I agree with that
ticket inasmuch as there should be more tokens used, though -- %page%
instead of hard-coded /page/, %trackback%, %attachment%, %date% etc.
For i18n if nothing else.

You can change the bases via plugin; here's one with no admin interface:

<?php
/*
Plugin Name: Ace of Base
*/

class AllYourBase {
        function change_of_base() {
                global $wp_rewrite;
                $wp_rewrite->feed_base = 'dinner';
                $wp_rewrite->author_base = 'hemingway';
                $wp_rewrite->comments_base = 'gossip';
                $wp_rewrite->search_base = 'mountainview';
        }
}
add_filter( 'init', array('AllYourBase', 'change_of_base') );
?>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

Peter Westwood
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sam Angove wrote:

> On 2/6/06, Peter Westwood <[hidden email]> wrote:
>> I am getting to know it quite well at the moment trying to put together
>> a patch for this old trac ticket - http://trac.wordpress.org/ticket/301
>> (current inprogress patch attached)
>
> It'll clutter the interface something shocking. I agree with that
> ticket inasmuch as there should be more tokens used, though -- %page%
> instead of hard-coded /page/, %trackback%, %attachment%, %date% etc.
> For i18n if nothing else.
>
> You can change the bases via plugin; here's one with no admin interface:
>
> <?php
> /*
> Plugin Name: Ace of Base
> */
>
> class AllYourBase {
> function change_of_base() {
> global $wp_rewrite;
> $wp_rewrite->feed_base = 'dinner';
> $wp_rewrite->author_base = 'hemingway';
> $wp_rewrite->comments_base = 'gossip';
> $wp_rewrite->search_base = 'mountainview';
> }
> }
> add_filter( 'init', array('AllYourBase', 'change_of_base') );
> ?>

This will work _except_ for feeds.  The rewrite rules for feeds expect
the feed_base to be feed and don't match when it is changed - you end up
with the feed links 404'ing.

This is the part of the patch that has been causing me the most grief
but I'm getting there.

westi
- --
Peter Westwood
http://blog.ftwr.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD5uvNVPRdzag0AcURAtRYAJ0elU+YoQAMI7WRf/IOj6N1LhgzyACgzU9z
6764hIr+KWt3D/uqJZ9t4jE=
=UYqh
-----END PGP SIGNATURE-----

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

Peter Westwood
In reply to this post by Sam Angove
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sam Angove wrote:

>> ----------------------------------------------------------------------------
>> 1. add_rewrite_rule(): A function for adding a straight rewrite rule.
>>
>> [snip]
>> * Theoretically it could then filter rewrite_rules_array and add the
>> rules itself, but I think we should add a function to WP_Rewrite for
>> adding 'extra' rules that needn't be generated by
>> generate_rewrite_rules().
>
> I don't have a problem with it, but why is filtering the array so bad?
> The current way is very easy, and it's more elegant for adding
> multiple rules.
>
> function add_arbitrary_rules($rules) {
>     $url = get_settings('home');
>     $rules[$url.'/arbitrary/(wibble)/?$'] = 'index.php?var=$matches[1]';
>     $rules[$url.'/arbitrary/(wobble)/?$'] = 'index.php?var=$matches[1]';
>     return $rules;
> }
> add_filter('rewrite_rules_array', 'add_arbitrary_rules');
>

Doing things this way breaks when we need index.php/permalinks/ the
whole reason for providing an API is that WP_Rewrite can take care of
the nasty stuff like that and let you get on with writing your plugin.

This level of abstraction is usefull, and opens up the addition of rule
types to more plugin developers - they need not understand PCRE to add a
new endpoint type for example.

westi
- --
Peter Westwood
http://blog.ftwr.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD5u4UVPRdzag0AcURAtDqAJ4kekm61ghbRyIiv72IuGe6B5Cy/gCfSS3u
Gq8cYEI3OP2qpRFDRqJ5MUQ=
=ip0S
-----END PGP SIGNATURE-----

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

Peter Westwood
In reply to this post by David House
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David House wrote:

> On 05/02/06, David House <[hidden email]> wrote:
>> Perhaps it is, but I think we should add the API in first. At the
>> moments, plugins use $wp_rewrite, and if we refactor that then we'll
>> likely break them. Adding in a level of abstraction (and getting the
>> small number of plugin authors that currently use $wp_rewrite) means
>> we can refactor at a later date.
>
> If anyone wants to add functions/edit stuff please do it at the wiki
> page I've just set up to hold the specification for this API [1]. If
> you add anything controversial mention it here as well so we can
> discuss it.
>
> [1]: http://codex.wordpress.org/User:DavidHouse/WP_Rewrite_API

I added a few suggestions to this last night

westi
- --
Peter Westwood
http://blog.ftwr.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD5u5OVPRdzag0AcURAovHAKCSohVOIljq1bgCtaaMeFknxzhoQACdFSWt
TsxUY1Yv76T6jnCZG0tpGac=
=TwqF
-----END PGP SIGNATURE-----

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

Peter Westwood
In reply to this post by Peter Westwood

On Mon, February 6, 2006 6:35 am, Peter Westwood wrote:

> Sam Angove wrote:
>>> ----------------------------------------------------------------------------
>>> 1. add_rewrite_rule(): A function for adding a straight rewrite rule.
>>>
>>> [snip]
>>> * Theoretically it could then filter rewrite_rules_array and add the
>>> rules itself, but I think we should add a function to WP_Rewrite for
>>> adding 'extra' rules that needn't be generated by
>>> generate_rewrite_rules().
>>
>> I don't have a problem with it, but why is filtering the array so bad?
>> The current way is very easy, and it's more elegant for adding
>> multiple rules.
>>
>> function add_arbitrary_rules($rules) {
>>     $url = get_settings('home');
>>     $rules[$url.'/arbitrary/(wibble)/?$'] = 'index.php?var=$matches[1]';
>>     $rules[$url.'/arbitrary/(wobble)/?$'] = 'index.php?var=$matches[1]';
>>     return $rules;
>> }
>> add_filter('rewrite_rules_array', 'add_arbitrary_rules');
>>
>
> Doing things this way breaks when we need index.php/permalinks/ the
> whole reason for providing an API is that WP_Rewrite can take care of
> the nasty stuff like that and let you get on with writing your plugin.
>

Scratch that comment..  I realised on my way into work this morning that
I'm talking rubbish here.  Thats what I get for replying to emails at 6:30
in the morning five minutes after I wake up :-(

> This level of abstraction is usefull, and opens up the addition of rule
> types to more plugin developers - they need not understand PCRE to add a
> new endpoint type for example.
>

This point is still valid though :-)

westi
--
Peter Westwood
Blog: http://blog.ftwr.co.uk

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

Sam Angove
In reply to this post by Peter Westwood
On 2/6/06, Peter Westwood <[hidden email]> wrote:
>
> This will work _except_ for feeds.  The rewrite rules for feeds expect
> the feed_base to be feed and don't match when it is changed - you end up
> with the feed links 404'ing.

Hmm, I see what you mean. Though I'm more inclined to say that
get_feed_link() is broken if the feed is RSS2. Of course, you can
always work around it... ;)

function fix_broken_get_feed_link($rules) {
        global $wp_rewrite;
        $base = $wp_rewrite->feed_base;
        $comment_base = $wp_rewrite->comments_base;
        $rules["$base/?"] = 'index.php?feed=rss2';
        $rules["$comment_base/$base/?"] = 'index.php?feed=rss2&withcomments=1';
        return $rules;
}
add_filter( 'rewrite_rules_array', 'fix_broken_get_feed_link');
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

Peter Westwood
On Mon, February 6, 2006 9:31 am, Sam Angove wrote:

> On 2/6/06, Peter Westwood <[hidden email]> wrote:
>>
>> This will work _except_ for feeds.  The rewrite rules for feeds expect
>> the feed_base to be feed and don't match when it is changed - you end up
>> with the feed links 404'ing.
>
> Hmm, I see what you mean. Though I'm more inclined to say that
> get_feed_link() is broken if the feed is RSS2. Of course, you can
> always work around it... ;)
>
> function fix_broken_get_feed_link($rules) {
> global $wp_rewrite;
> $base = $wp_rewrite->feed_base;
> $comment_base = $wp_rewrite->comments_base;
> $rules["$base/?"] = 'index.php?feed=rss2';
> $rules["$comment_base/$base/?"] = 'index.php?feed=rss2&withcomments=1';
> return $rules;
> }
> add_filter( 'rewrite_rules_array', 'fix_broken_get_feed_link');

Don't forget that you need to do this for _every_ post/page permalink
rewrite rule as well it's not just the root feed that is broken.

This is why WP_Rewrite needs fixing to support this rather than trying to
hack arround it.

westi
--
Peter Westwood
Blog: http://blog.ftwr.co.uk

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

Sam Angove
In reply to this post by Peter Westwood
On 2/6/06, Peter Westwood <[hidden email]> wrote:
> Doing things this way breaks when we need index.php/permalinks/ the
> whole reason for providing an API is that WP_Rewrite can take care of
> the nasty stuff like that and let you get on with writing your plugin.

I was actually going to suggest prepending `index.php` globally (and
converting $1 to $matches[1], etc) after the array filter, instead of
one at a time during `generate_rewrite_rules()`.

But you're right, that is a good reason.


> This level of abstraction is usefull, and opens up the addition of rule
> types to more plugin developers - they need not understand PCRE to add a
> new endpoint type for example.

True (for your proposed add_endpoint() function), but they'll still
need to understand them to use add_rewrite_rule().

Something much more abstracted might be interesting...
   add_rewrite_rule('%tag%/%tag2%', 'index.php?a=%tag%&b=%tag2%');
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

Sam Angove
In reply to this post by Peter Westwood
On 2/6/06, Peter Westwood <[hidden email]> wrote:
>
> Don't forget that you need to do this for _every_ post/page permalink
> rewrite rule as well it's not just the root feed that is broken.
>
> This is why WP_Rewrite needs fixing to support this rather than trying to
> hack arround it.

Unless it's been changed since 2.0 (haven't upgraded yet), the
comments_rss function will always return permalink/feed/, which will
still work.

permalink/rss2/, permalink/atom/ etc. will work too -- as will
permalink/feed_base/(feed|rss2|rss|atom).
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

David House
In reply to this post by Sam Angove
On 05/02/06, Sam Angove <[hidden email]> wrote:
> Are there any other hooks/filters that get convenience wrappers?
> They're pretty convenient as-is. The current way is very flexible, and
> it only looks verbose when it's for the sake of one query var -- I had
> a plugin with about eight, and three times that many rewrite rules,
> and it was very nice indeed.

<snip>

> Without your callback, does this do enough to make it worth the
> bother? The query_vars filter is the easy bit anyway, and this API is
> much less efficient if you're adding more than one QV.

Are you proposing we give up on the API idea? Here's why I think it's necessary:

1) Plugin authors want a simple solution to a simple problem. Adding,
say, a single rewrite rule is a simple problem and so we should
provide a simple function for it.
2) It gives us a level of abstraction so we can refactor WP_Rewrite at
a later date without worrying about breaking the plugin-facing
interface.

I just think that having to hook three or more filters to add a new
rewrite tag is too much. It may not seem unbearable when you have
eight QVs, but I'd think that yours is the edge case and skippy's more
normal.

Something like the example I pointed out [1] illustrates the power of
just the two simple functions I proposed. Westi's would make
everything a lot more flexible.

I don't see any reason not to add the API.

I'll probably be drafting up patches for add_rewrite_rule() and
add_rewrite_tag() over the next few days (with the others following)
unless anyone disagrees.

--
-David House, [hidden email], http://xmouse.ithium.net
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Make WP_Rewrite eaiser to use

Sam Angove
On 2/6/06, David House <[hidden email]> 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.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Loading...