[wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

[Marcus Pope]

> That's the point. You want that content to remain unaltered and useful no matter where you put it or how you use it. If you
> have relative URLs in that content, then the correctness of the content is now dependent on the place it is displayed. This is
> the underlying problem I have with relative URLs.

Yes, and if you use that content on staging.example.com AND www.example.com it is not useful and does not work in both places - hence it violates "being useful no matter where you put it."

> You're correct, however URLs should not change often, and neither should domains. These are things which, in an ideal
> scenario, *rarely* happen. On the other hand, content is often displayed outside the context of the web site. RSS feeds are
> the most obvious example.
> To optimize your methodology to account for the "almost-never-happens"
> case while adding a bunch of new and extra code for the "happens-a-lot" case seems like a poor way to do things

Rarely for you might be true, but for us who use continuous integration practices it is hourly.  We constantly push our content and code on every commit.  Using DNS tricks won't solve replacing content URLs via hacky filters.   Don't assume your practices are universal.  Don't you see the value in having one function that filters your content on export only?  As it stands you filter on export AND serving BECAUSE you use absolute URI's.

>> Otto - how do you show clients your test site?
> Simple: I don't write my code in a way that changing the URL will break the site. If I need to use "real" content, then I can
> process it to change the domain around and thus keep things working with just a few simple filters and the handy str_replace
> function.

Ok, let's be more explicit.  How do you show your client, let's say Google.com, their staging site so they can review features you've added before they go into production?  That is to say, how do you show them staging.google.com, let them login to the admin, make post development edits and testing on new features before pushing it live to www.google.com?  The moment they login to staging.google.com and try to edit a post they will be redirected to www.google.com and they'll be editing live posts because you stored and served absolute URLs.

You either have to hack their DNS/HOST settings, or you have to convert all URLs to staging.google.com, let them test, and then convert their URL's back after they are done with it.  What if you have to re-integrate production changes that occurred into the database while you were demoing it?  That's a maintenance nightmare with hard-coded URL's and prevents you from doing seamless production pushes without a period of downtime while you or your program swaps out urls in a gigabyte sized database.

> No, but that's not the same thing at all. A dev/staging/production environment is something used by a company to create a
> continual development process. It's not the same as a demo or test site that you would be showing clients. You're mixing
> ideas here.

Not always, sometimes you demo to a client on your staging site.  And when they are external to your network, they can't access your site without being redirected to production in the admin portal, without a slew of str_replace tricks.  And it's not that simple because to do it correctly you have to implement everything I've implemented in my plugin, and even then it won't work for MU sites.

The reality here is that you don't do any of this, because if you did you would immediately recognize our headaches.  You might get away with what you've had to do in the past, but it would not fly with blue-chip industries.  Wordpress isn't even a common selection in this industry because of this fact, (sure  it may power their blog, but it doesn't power their intranet or extranet webapps.)  But it could if they moved away from absolute URL's in the same way that the rest of the industry did back in 97.

-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Otto
Sent: Friday, October 28, 2011 1:45 PM
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

On Fri, Oct 28, 2011 at 1:32 PM, Robert Lusby <nanogwp at gmail.com> wrote:
> While writing this I've just seen "because you might write a book" 
> listed as a reason for not changing. Seriously?

Yes, seriously. Not about the book, that's just an example. It's about your inability to predict the future use to which you will want to put your content.

WP does some post-processing of content now. It does things like making quotes into curly quotes, and paragraph formatting, etc. The data itself though, in the DB, remains unaltered. It's more or less exactly what you submitted in the first place (ignoring TinyMCE for the moment).

That's the point. You want that content to remain unaltered and useful no matter where you put it or how you use it. If you have relative URLs in that content, then the correctness of the content is now dependent on the place it is displayed. This is the underlying problem I have with relative URLs.

> Relative URL's change. Sites change domain. Your entire DB is then out 
> of date.

You're correct, however URLs should not change often, and neither should domains. These are things which, in an ideal scenario, *rarely* happen. On the other hand, content is often displayed outside the context of the web site. RSS feeds are the most obvious example.

To optimize your methodology to account for the "almost-never-happens"
case while adding a bunch of new and extra code for the "happens-a-lot" case seems like a poor way to do things.

Basically, you're saying that because the domain *might* change, you should be using relative URLs. Then, because relative URLs don't work everywhere, you should add a bunch of code to detect the cases where they don't work and post-process the content to convert them to absolute URLs. But the domain changing is, or should be, infrequent, and pulling RSS feeds happens a hell of a lot more often. Which is it better to optimize for?

> Otto - how do you show clients your test site?

Simple: I don't write my code in a way that changing the URL will break the site. If I need to use "real" content, then I can process it to change the domain around and thus keep things working with just a few simple filters and the handy str_replace function.

> Do you want me to go round and change the DNS/Host files for *all* of 
> these users in often 4/5 different companies?

No, but that's not the same thing at all. A dev/staging/production environment is something used by a company to create a continual development process. It's not the same as a demo or test site that you would be showing clients. You're mixing ideas here.

-Otto
_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers