[wp-hackers] One CMS to Rule Them All (was This was painful to read...)

[Mike Schinkel]

On Dec 3, 2009, at 12:20 PM, Otto wrote:
> I disagree that your use case is common. I think you're being overly
> limited by what you want to do, and I do not think that you can expand
> that out into the general population.

Every site I've come across needs it, bar none.  Most blog sites don't, but any every website that is doing something besides blogging needs it.  

And it's the most common use case for when WordPress doesn't *already* handle the URL in an acceptable way. (Can you propose a more common use case where WordPress doesn't already handle the URL in an acceptable way?)

Still you see close-minded on this topic so we'll probably have to agree to disagree.  At least until after custom post types take off and you see how many people are using custom post types.

> 
>> I don't understand the "attaching to a fixed template" issue. As opposed to what, a variable template?
> 
> Yes, a variable template. As in maybe I have a products directory, and
> whatever.php is inside it. I can also have an index.php inside it as a
> fallback position, perhaps. This is how much of the theme hierarchy
> works, after all.

Then you misunderstand how URL templates work.  You specify them from specific to general.  You handle the use-case you refer to by adding another custom url definition, not by making each custom url overly complicated to specify.

>> BTW, my code that I sent you also supports callbacks, is that what you meant? i.e.
>> 
>> add_custom_url( array(
>>  'url_template' => 'foo-page',
>>  'url_type' => 'callback',
>>  'callback' => 'do_foo_page',
>> ));
> 
> I saw the callbacks, but have no idea what they do. What is the URL
> you're defining here? /foo-page? You can do that rather easily by
> adding a rewrite endpoint.
> 
> add_rewrite_endpoint('foo-page', EP_ROOT);

Easily for you.  Not easily for most themers.

> The EP_ROOT is where you want the endpoint to be enabled. In this
> case, just off the root URL, and not all single post pages, archives,
> etc. Full list of possibles is in rewrite.php.
> 
> Anyway, then in your template_redirect action function, you can do
> get_query_var('foo-page') to detect when your URL endpoint is
> recognized. It'll be set to 1 when it's there.

A full list of complex possibilities.  I want to make easier.

>> Are you saying WordPress shouldn't support custom post templates?
> 
> I'm saying that it shouldn't support simplistic and slightly insane
> ways of doing them, yes. If you want to do a custom post template,
> then there's a very easy method that already exists to do that.

Insane?  It's nice to see you can be condescending without saying anything of substance.  I'll try to refrain from doing this same.

>> You mean like how permalinks have special names like "postname" and "monthnum?"   So what's wrong here?
> 
> Nothing is wrong there. That's why we have add_rewrite_tag,
> specifically to add those variables. That's the whole *purpose* of it.
> What you want in this respect already exists.

It already exists, and is too complex for the average person to use in a theme.

>> Yes, a custom post type. From what I've seen that's the most common use case for custom URLs by far.  You have an issue with simplifying common use cases?
> 
> I disagree that it is a common use case, especially since custom post
> types have not been well supported until 2.9 and didn't even exist
> before 2.7.

It's a common use case *for* custom post types.

>> If you feel the need to continue criticizing please explain why it's bad to have a simplifying layer instead of arguing for a layer that does thing exactly as complicated as the layer below it.
> 
> Few reasons:
> - Creating a simplifying layer creates unnecessary code maintenance
> headaches. What happens when the underlying code changes? Now your
> layer must change with it.

Based on your comments it sounds like that underlying is perfect so maintenance is not a big issue here.

> - Layers make things slower. This is just a fact. More code = more
> memory used = slower.

Not necessarily.  It depends on how the layer is implemented.  If a layer only gets triggered in the exceptional case it only affects the exceptional case.  If it only happens on activation, then where's the real issue?

> - Layers create de-facto ways of doing things that forces people into
> a specific mindset. In other words, if we create something that lets
> people tie URLs to custom post types, then people will do that instead
> of thinking of the right way of doing what they want to do. It's
> better to leave it more open, to encourage original thinking.

So we are enforcing an orthodoxy, are we?  

> - The existing way of doing it, in this specific case, is not that
> bloody complicated. You're talking about reducing 10-15 lines of code
> down to 1 by creating a function which would have to be at least 60-70
> lines to do properly. That just makes zero sense.

It *IS TOO BLOODY COMPLICATED*!!!   How many WordPress websites are using URL rewriting right now?!?  Find me 10 sites out of millions that do something different with URLs (I'll give you one freebie: http://pm-sherpa.com/solutions/)  I'll bet you can't. The reason they are not doing it is URL rewriting in WordPress is currently TOO HARD.

> Finally: This really belongs in a plugin. You're wanting to do
> something that I doubt that even a sizable minority of WordPress users
> really want to do.

As respectfully as I can be, I think you are in a bubble. How often do you get out and talk to other people face to face about what they need in a WordPress site?  I can only think you've not had much experience with even a significant minority of those users because every website project I look at needs custom post types with custom urls.

> No, I'm arguing that WordPress should not support *this* layer which
> you're proposing.

Well, we must disagree on this.  I'll submit a patch when I can; feel free to do your best to block it if you must.

> WordPress 2.9 makes it much easier, as I have demonstrated.

At least with that we can agree.

-Mike