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

[Mike Schinkel]

On Dec 3, 2009, at 9:54 AM, Otto wrote:
> Absolutely not the reality, because I'd say the exact same thing, only
> flip-flopped. You're making your focus too narrow. Your whole idea of
> tying a rewrite URL down to a custom template is far LESS generic than
> the existing system.
> 
> In other words, the examples you have given are a *subset* of existing
> functionality. It's already more generic and more capable than what
> you want it to be able to do. You're trying to constrain the system to
> your specific needs. I'm trying to not do that.

There I have to disagree.  I am not trying to constrain the system, I am trying to creating a layer that simplifies a very common use case. The existing layer still exists when my layer is on top of it so there is nothing constrained, only common use cases simplified.

Programmers add simplifying layers all the time while leaving the more capable complex layers below, and there are myriad examples within WordPress core of the same thing.  Given that WordPress has a focus on usability I find it counter to the mission to push to maintain only the more complex approaches.

> 
>> So let's get pass this and try to figure out what works.  Can you explain what you think my vision is (so I can either agree or correct it) and then why you think that vision is too narrow by giving counter examples?
> 
> The example you've posted several times is something like this:
> add_custom_url( array(
>  'name'          => 'product-page',
>  'url_type'      => 'single-post',
>  'url_template'  => 'products/{product_slug}',
>  'template_file' => 'custom/product.php',
>  'post_type'     => 'product',
> ));
> 
> That's very, very specific. You're basically defining a custom-url and
> attaching it to a fixed template and template file with a specially
> defined variable name, hooked to posts, etc, etc.

I assume "defining a custom-url is okay", right? Otherwise what are we discussing?

I don't understand the "attaching to a fixed template" issue. As opposed to what, a variable template?  

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',
));

> and template file

Are you saying WordPress shouldn't support custom post templates?

> with a specially
> defined variable name,

You mean like how permalinks have special names like "postname" and "monthnum?"   So what's wrong here?

> hooked to posts, etc, etc.

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?

>  etc, etc.


Are there actually other things you take issue with or just embellishment without actual additional considerations?

Essentially you are complaining about the existence of those things without which it would not be possible to match a URL and route it to the most common use case, a custom post type. And it seems you made the assumption that handling the common use case makes it not possible to handle other use cases? Of course that would be a failed assumption.

You could of course make it more object-oriented and decouple the fact that a custom post type uses a custom url such as below but in my experience that's just not the way things are done in WordPress.  Decoupling common use cases just adds complexity to the normal case and WordPress is about making things easier, not about making them harder.


$product_url = add_custom_url( array(
 'name'          => 'product-page',
 'url_template'  => 'products/{product_slug}',
 'template_file' => 'custom/product.php',
));
attach_url_to_custom_post( $product_url, 'product');

> Even if you assume
> that there's multiple types here, it's much *less* flexible than what
> is already in the core. It may be simpler and easier to call something
> along the lines of your version, but it's limited in its capabilities
> to the types of URL direction that you have pre-programmed into it.

Again, providing a simplifying layer that handles the use cases  that are going to occur far more often than others (without removing the existing layer) is A Good Thing(tm).

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.

> That's what I mean by specific vs. generic. Generic is
> add_rewrite_url, which lets you use a simple regexp to define any sort
> of rewrite you want. Generic is template_redirect, which lets you
> redirect to any template you want based on any criteria you can dream
> up.

Are you actually arguing that WordPress should not support any additional layers that simplify things?  Especially things that many people have expressed both an interest in doing and a concern that it's far too difficult?  Seriously?

> Your "vision" seems to be focused on pre-defined ways of doing things,
> in ways that you have given custom names to (like "single-post").

There are custom names for concepts identified by the core developers littered throughout WordPress core. Just look at init_query_flags() in query.php or wp_options table for a littering of custom names. Custom names are not a bad thing. (Besides, how would you identify a concept in core without introducing a custom name?)

And my "vision" (which you incorrectly characterize) is to identify common use cases and make them easy.  To handle the common use case of a custom post type is currently *not* easy, but should be.

-Mike Schinkel