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

[Otto]

On Thu, Dec 3, 2009 at 10:10 AM, Mike Schinkel
<mikeschinkel at newclarity.net> wrote:
> 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.

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.

> 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.

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

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.

> 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.

> 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.

> 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.

> 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.
- Layers make things slower. This is just a fact. More code = more
memory used = slower.
- 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.
- 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.

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.

> 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?

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

> 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.

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

-Otto
Sent from Memphis, TN, United States