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

[Mike Schinkel]

On Dec 3, 2009, at 1:26 PM, Otto wrote:
> WordPress is primarily a blogging platform. Yes, you can build any
> sort of thing out of WordPress, if you like, but perhaps you shouldn't
> always do that.

And that's your opinion which you are entitled to. My opinion differs.  

WordPress.org calls itself "a state-of-the-art publishing platform" (and not "a state-of-the-art blogging platform.")  Obviously someone involved in WordPress thinks that WordPress is now more than just a blogging platform.  Of course there are still the factions that want to block any changes that could make it a better CMS.  It's my hope that those factions don't succeed.

BTW, it reminds me of the Army Corp of Engineers in North Georgia. It's run by a group of fishermen.  Their opinion of Lake Lanier is it is "a fishing lake" though it is far more popular for recreational use. Thus, even though the vast majority of users are recreational the Corp blocks every attempt to make the lake safer for recreation because the changes affect it's use as a fishing lake.  What they *could* do is make the 20% of the lake that is popular for recreation safer for recreation and leave the remaining 80% good for fishing, but they won't even consider that approach. 

>> 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?)
> 
> The most common use case I've seen is where people want to customize
> the URL to pull specific posts or sets of pages or what have you. Most
> of these are pretty easy, and don't necessarily involve custom post
> types.

My opinion is that they are not using custom post types yet because they are not yet available in the release version.  Wait a while and I believe that will change.  But it is my opinion so we can only wait to see if I am right or not.

> The most common case I've seen for plugins to use it is to create
> their own subset of pages to display whatever. Like an image gallery,
> for example. It takes over the /gallery/* set of pages, redirects to
> itself, and does whatever it likes.

Or, custom post types by another name...

>>> 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.
> 
> Total nonsense. Utter gibberish.

Why must you be so condescending?  It's hard not to take things personal when you describe my writings in those terms.

> You're making things way too complex
> and slow by doing that. What if I have 20000 products, after all?

Again, you misunderstand (willfully?)

You would never do 20000 custom urls, you'd only do one custom url for all products.  But let's say you wanted to have a custom URL that lists recent products, and you want the "recent" slug to be used like the "acme-widgets" slug; you would add two custom URL templates:

/products/recent/				<-- this is more specific and would match first
/products/{product_slug}/

> Better to match /products/* once and then redirect based on the
> contents of the * piece than to define 20000 separate rules of
> /products/1, /products/2 and so forth..


See, you did misunderstand.  And I think your misunderstanding was total nonsense and utter gibberish! ;-)

> 
> Example: I want /products/whatever to redirect to
> products/whatever.php in my theme directory. If whatever.php doesn't
> exist, then use the products/index.php instead.

You are conflating the two. What's more what you propose is bad REST, HTTP and URL design.  You should issue a 404 error, not redirect to the general purpose.

> Code to do it for ALL arbitrary whatever's:
> function plugin_add_custom_urls() {
> add_rewrite_rule('products/(.*)[/]?$', 'index.php?product=$matches[1]', 'top');
> add_rewrite_tag('%product%','.*');
> }
> add_action('init', 'plugin_add_custom_urls');
> 
> function plugin_add_template() {
> $product = get_query_var('product');
> if (!empty($product)) {
>   locate_template(array("products/$product.php","products/index.php"), true);
>   exit;
> }
> }
> add_action('template_redirect', 'plugin_add_template');
> 
> Just that easy.

The word "easy" and that code are oxymorons.

>>> add_rewrite_endpoint('foo-page', EP_ROOT);
>> 
>> Easily for you.  Not easily for most themers.
> 
> One line of code, which I just gave to you and the rest of the
> internet, is somehow hard to modify?

One line of code, to go along with the tens of other lines of code.  One is not an issue. "Many" is.

>> Insane?  It's nice to see you can be condescending without saying anything of substance.  I'll try to refrain from doing this same.
> 
> Hey, I calls 'em like I sees 'em. I think it is slightly insane to go
> to extreme lengths to wrap things and make them more complicated and
> less capable in the process.

And I am starting to think I'm insane for debating you. 
> 
>> It already exists, and is too complex for the average person to use in a theme.
> 
> This is only your opinion. Please stop treating it like some kind of
> Truth handed down from up on high, when it is no such thing. Thanks.

Ironic, you are treating your own opinions as truth handed down from up on high; why shouldn't I?

Better yet, maybe we are getting somewhere. How about we agree on this list that both of our opinions are just that, and not the final word on anything.  Deal?

>>> - 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.
> 
> False. Layers *ALWAYS* make things slower. This is easy to prove.
> Method 1: I execute code A.
> Method 2: I call layer B which in turn executes code A.
> 
> Method 2 is always slower than method 1. Furthermore. Method 2
> implements code designed to abstract portions of the underlying code,
> which takes time to run. Making it even slower.


It's foolish for you to say false here.  If the layer doesn't execute it doesn't make things slower.

Adding a hook makes things slower.  Does that stop the core team from adding new hooks each version?  Premature optimization is a fools errand.

>> So we are enforcing an orthodoxy, are we?
> 
> No, we're just not encouraging one. That was sort of my point.

Fair enough.  I am encouraging another one.  That's my point.

>> It *IS TOO BLOODY COMPLICATED*!!!
> 
> Your opinion again.

Ditto on all your prior assertions that came without proof.
> 
>> How many WordPress websites are using URL rewriting right now?!?
> 
> Well, I'd say almost all of them use it in one form or another,
> actually. Of course, they do it through plugins, generally speaking,
> but hey. Anybody running an image gallery plugin, off the top of my
> head, is using URL rewriting to some degree.

That's answering out of context.  I'm asking how many people are doing URL rewriting where they had to write the code you are promoting?  Very few.

> Why don't you search the plugin svn repo for how many instances you
> can find of "add_rewrite" and see what you come up with?

What I'd prefer to do is search the theme repo for it.  Again, plugins are not my use case, themes are.

>> As respectfully as I can be, I think you are in a bubble.
> 
> I would say the same back to you, but I think we're past that point.
> 
> Nice having this chat with you, but we're done now.

Finally.  I proposed that a while ago.

>> 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.
> 
> Stop taking things personally. I'm not against *you*, I'm against
> *your idea*. I'm all for improving WordPress. I just don't think that
> this idea is an improvement.

I'm not taking things personally. I'm focused on the approach.  And I plan to ignore your concerns because I think they are irrational and move forward with a patch as soon as I can.

-Mike