[wp-hackers] The problem with WP_Rewrite <<< RE: Options for Controller - Views

Mike Schinkel mikeschinkel at newclarity.net
Sun Nov 29 22:27:41 UTC 2009


On Nov 29, 2009, at 1:46 AM, Dion Hulse (dd32) wrote:

Hi Dion,

> For everyones benefit, i've just written a quick plugin which achieves what you set out to do with the product rewrite rules, whilst reducing the amount of useless SQL queries performed as well as avoiding some rather messy code:

Thanks for the proof of concept.  I'll be applying it to my use cases very soon to see how it applies and if it actually addresses the same needs (but it will be a few days before I can get to it, though.)

> Your idea of add_custom_url() is indeed very simplistic, and clean, The major problem with that IMO, is its not flexible enough.. Its ok for simplistic structures, but i'm certain it'll not last for ever.


I'm curious what about add_custom_url() is not flexible enough, at least in concept?  Can you give me some viable use cases such an approach cannot handle?

> Yes, This is not a complete writeup, Its just to demonstrate, that the code does not have to be as messy as you've quoted, And while its longer and more verbose than add_cusotm_url(), its definately a better start.

A point of note; as implemented your solution hard codes the "product" path in logic too complex for the average developer who isn't intimately familiar with adding rewrites, permastructs, flushing of rules, parsing queries, trailingslashits, etc. And it requires careful coordination to make sure everything lines up correctly. Imagine if I had 5 URLs for custom content types? Or 20, especially if they are more complex then just "foo/{foo}?" To implement with the approach you presented would be way beyond all but the more advanced users. 

My #1 key stated goal of my plugin was to hide that complexity (and I think that's what Jacob wants to accomplish too, with his most recent email to the list.)

Of course you could be showing the mechanics so I can make it more generic and if so I really appreciate that.  OTOH, if so I'm confused by your assertion that "add_custom_url() is not flexible enough?"

BTW, I see that you and the WordPress community are fond of using percent signs (%) as URL delimiters and because of that I probably should too.  OTOH, I've always been disheartened that WordPress uses percent signs because there is a draft proposal that has a lot of backers for a URI Template syntax that can scale in complexity unlike WordPress' current approach:

http://bitworking.org/projects/URI-Templates/spec/draft-gregorio-uritemplate-03.html

Minimally that syntax uses braces like the following and I'd like to advocate that WordPress move in that direction for 3.0 so as to be compatible with that future standard (it's already a defacto standard in use by many):

/product/{product_slug}

Maybe I should submit a proposal on Trac?

> * Admin panel to add/remove products

I especially appreciate this part; it shows me how to do something I didn't previously realize there where hooks for.

> I'll be writing a series based around things like this, this code is to become part of the first post in the series.

I look forward to see where you are taking this.

> I'd like to see register_post_type() extended to take care of custom url's, to a certain extent, and i'll be creating a few tickets later for 3.0

Yes it would be nice to have register_post_type() handle custom URLs but I really hope that functionality is not coupled to register_post_type(); it would be better if it were independent but able to be called from register_post_type() for convenience too as there are other custom URL use cases that are not post-type specific, albeit significantly fewer in comparison.

> i hope.. 3.0 is going to bring some great changes by the look of it.

I'm anxious for it!

> I can say however, That register_post_type will NOT be able to do everything for you, It will most likely however, manage to take care of the basics at first.

Do you have specifics of what it WON'T be able to do in mind, or was that a general disclaimer?  

Thanks in advance for response.

-Mike Schinkel

> On Sat, 28 Nov 2009 23:58:05 +1100, Mike Schinkel <mikeschinkel at newclarity.net> wrote:
>>> In other words, I'm trying to explain why I think it's a good system,
>>> and trying to get you to explain to me why you think that it is not.
>> 
>> To start, it is very confusing and hard to figure out what you need to do to accomplish a URL routing task in WordPress.  Let's take a look at the following which is what I'd like to be able to do (my plugin actually does it but in a manner I feel is very fragile):
>> 
>> add_custom_url(	array(
>>   'name'          => 'product-page',
>>   'url_type'      => 'single-post',
>>   'url_template'  => 'products/{product_slug}',
>>   'template_file' => 'custom/product.php',
>>   'post_type'     => 'product',
>> ));
>> 
>> To me that seems very straightforward and is a level of simplicity I think we should strive for, don't you think?  (Wouldn't it be great to have custom URLs addable from the admin console? That's what I think we should have. Also note is assumes a custom post type, the other thing Wordpress badly needs to support in core.)
>> 
>> Now what is (some of) the code I have to write to support that?  Let's take a look:
>> 
>> $wp_query->query_vars['page_id'] = 0;
>> $wp_query->is_page = false;  // A "single-post" is not same as a WordPress "Page"
>> $wp_query->is_single = $wp_query->is_singular = true;
>> if ($post_id = self::get_post_id($wp_query)) {
>>   $wp_query->queried_object = $wp_query->post = get_post($post_id);
>>   $wp_query->query_vars['p'] = $post_id;
>> } else {
>>   $wp_query->is_404 = true;
>> }
>> 
>> Simple?  I think not (what's "is_single" and how does it compare to "is_singular?" Why do I need to set "page_id" to 0? Why do I have to set "query_vars['p']" to $post_id? Why do I have to set "is_page" to false? What else should I have set that I didn't know to set? )
>> ..<snip>..
>> What's more, there's lots of code that runs in core that, by the time I get enough control in my plugin, I have to unravel and redo. That's not an ideal architecture and that's what I'm looking to have improved.
> 
> I think you're hooking too late in the process, and as such, you're running into issues related to WordPress looking too deeply into it before you tell it otherwise.
> 
> Your idea of add_custom_url() is indeed very simplistic, and clean, The major problem with that IMO, is its not flexible enough.. Its ok for simplistic structures, but i'm certain it'll not last for ever.
> 
> For everyones benefit, i've just written a quick plugin which achieves what you set out to do with the product rewrite rules, whilst reducing the ammount of useless SQL queries performed as well as avoiding some rather messy code:
> 
> http://dd32.id.au/uploads/2009/11/HTDIR_URL_Rewrite.zip
> 
> In a nutshell:
> * 3 filters to control Rewrite, Query, and Template
> * No eronous SQL queries, The only query is the product load query. (I'm refering to post queries here btw)
> * Works with WordPress 2.9, 2.8 should work too
> * Fair bit of comments inline, Not finished obviously
> * Takes /products/<slug> and spits out post_type = product
> * Works no matter what your permastructure is ( none, ie. ?product=product-1, /product/product-1/, /index.php/product/product-1/)
> * Admin panel to add/remove products
> * 2 lines which i would call hackish.. But thats only telling wordpress that we're on a custom page.. (is_single = true, is_home = false)
> * Uses a custom page template bundled with the plugin (Taken from single.php from default theme, removed a bit of code, bare basics)
> * Uses as much of the API as currently exists for it.
> * Not finished 100%, Final few touches need to be put on, such as flushing of rules on deactivation
> 
> Yes, This is not a complete writeup, Its just to demonstrate, that the code does not have to be as messy as you've quoted, And while its longer and more verbose than add_cusotm_url(), its definately a better start.
> 
> I'll be writing a series based around things like this, this code is to become part of the first post in the series.
> 
> I'd like to see register_post_type() extended to take care of custom url's, to a certain extent, and i'll be creating a few tickets later for 3.0 i hope.. 3.0 is going to bring some great changes by the look of it.
> I can say however, That register_post_type will NOT be able to do everything for you, It will most likely however, manage to take care of the basics at first.
> -- 
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers



More information about the wp-hackers mailing list