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

[Mike Schinkel]

On Dec 3, 2009, at 12:01 PM, Otto wrote:
> On Thu, Dec 3, 2009 at 10:37 AM, Mike Schinkel
> <mikeschinkel at newclarity.net> wrote:
>> First, that's far more complicated than it should be if this is something people will be doing a lot.
> 
> I fail to understand how two function calls is at all "complicated".

It's not that there are two calls, it's the complex parameters that must be passed. 

> Yes, you need to know regular expressions. They're not that complex.


Maybe you should drive down from Tennessee to Atlanta to the WordPress users group and/or the Atlanta Bloggers group and ask for a show of hands for how many people understand and can use regular expressions?  My guess is you *might* get 2 in 100 to raise their hands.

See I think you are so advanced it's difficult for you to understand just how hard some of this stuff is for most users (the irony? Most people around here know me as the "advanced" guy. :-)

>> Unless I misunderstand, that's not I'm looking for.  Using your example, this might be what I'm looking for (not sure about the "add_rewrite_tag()" as I don't really understand what it does):
> 
> You know how custom permalinks work? Like /%year%/%month%/%postname%
> and so forth?
> 
> %postname% is a rewrite tag. It takes whatever is in that space and
> puts it into the $wp_query->postname variable.
> 
> When you add a rewrite tag, you're creating a new one of those. The
> second parameter is a limiter, so I can limit the value to be all
> digits or something, if I wanted. The .* is simply a way of saying it
> can be anything (regular expressions again).

I didn't understand the limiter part, thanks; it helps.

>> Can I assume that post_type is not supported until 2.9?  It doesn't seem to work in 2.8 (which is what I'm working with.)
> 
> The post_type variable is supported in 2.8, but *custom* post_type
> support wasn't added until 2.9.

But it still doesn't work in 2.8, right?   At least it didn't work when I tried to use the URL with a post_type parameter on an existing live site.  Anyway, not important.

>>> function plugin_add_template() {
>>>  if (get_query_var('post_type') == 'whatever') {
>>>    locate_template(array('custom/product.php'),true);
>>>    exit;
>>>  }
>>> }
>>> add_action('template_redirect', 'plugin_add_template');
>> 
>> Again, too complex for doing often.  But let's hold that thought too...
> 
> I'm utterly floored by this statement. What part of that is at all
> "complex"? That's about the simplest possible code I can imagine to do
> something like this. If you want to abstract 10 lines of code into 1,
> then that's fine, but that sort of nonsense shouldn't be core code.

Conversely I'm floored by your adamancy about not wanting to make this common need approachable.  The code you mention is fine for plugins but not fine for themes. 

The skill level for PHP coding among plugin developers is much higher than for your *average* themer who in many cases use cuts and pastes PHP code from examples (no hate mail from you themers highly skilled in PHP please; you are in the minority.) In your example the themer has to know how to hook template redirect, to use get_query_var(), to use locate_template(), to pass an array to locate_template, that it accepts a second param of true (what's true?) and that it should exit.  FAR too much conceptual overload for the themer to bother with and more importantly, for them to have to debug. 

Give the themer a break and make it easy as I did with add_custom_url().

> I would suggest that you submit it as a plugin instead. I don't think
> that this sort of needless wrappers and abstraction should be in the
> core.

I already have a plugin.  IMO this sort of wrapper is exactly what should be in the core, so that URL rewriting it approachable to the everyday user of WordPress and not just for coding wizards like yourself.

-Mike