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

[Dagan Henderson]

Just got a reply with good info, but it came to my person address instead of the mailing list. In case that was intentional, I'm omitting the sender's address, but I thought it should be shared with the list:

>Remember, a _lot_ of content gets shared via cut-and-paste these days. Relative URLs break that 100 percent of the time.

I just did some simple tests and my browsers corrected the URL when cutting and pasting. That is, even though the link was relative when I cut it, it was absolute when I pasted it, if that makes sense.

surprised me.

-Bill

-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Dagan Henderson
Sent: Friday, October 28, 2011 1:16 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...

A lot of the points here are rather interesting, but I'm starting to feel like, for some, the conversation is getting a little heated.

Marcus, you may not intend it, but your tone (at least to me) is unnecessarily aggressive. This isn't a debate over whether or not Jesus Christ walked the earth. It's a question of whether absolute or relative URLs make more sense for the typical WordPress install.

Personally (and I do think it's a matter of preference/ evironment) I side with absolute URLs. If it's merely a question of staging vs. production, I think it makes a lot more sense to run a plugin on the staging/dev environments that filters absolute URLs from the production domain, ideally to absolute URLs for the dev/staging environment.

Remember, a _lot_ of content gets shared via cut-and-paste these days. Relative URLs break that 100 percent of the time.

-----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:05 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 2:33 PM, Marcus Pope <Marcus.Pope at springbox.com> wrote:
>> Sure you can. <img src="/root/relative/url.png"> works fine in a post.
>
> Otto, I see you understand less about this problem than I first thought.  Yes you can add root-relative urls in a post if you do it manually, or via a plugin that adds a filter to strip out the domain.  However you cannot login to a wordpress multisite via the following:
>
> http://127.0.0.1/wp-admin
> and
> http://localhost/wp-admin
> and
> http://mycomputer/wp-admin
>
> because wordpress core uses absolute urls.  In doing so, if you attempt to login to that site, regardless of any dns or htaccess tricks up your sleeve you will be stuck in an infinite loop.

Of course you can't. If you have the site on a different URL, then you need to tell WP what the new URL is.

Is that all that this is about? The Site and Home URLs? Jeez... just set the WP_SITEURL and WP_HOME defines in the wp-config.php file.

> It is very simple.  You only every process the content if you are exporting it.  You don't process the content if you are hosting it.

"Exporting" the content is what happens a large portion of the time.
You're exporting it to a feed, to somebody's feed reader, to somebody's *browser*, which can be any of dozens of different types of devices.

Viewing something in a browser is "exporting" it from the database to the browser, because you don't necessarily know the context in which the content is being viewed or used.

> As it stands wordpress processes the content hundreds of times in both situations (exports & hosting.)  There is zero maintenance with root-relative urls.  No host file hacks, no dns tweaks, no spoofing production urls in dev and staging. NO MAINTENANCE.

No, it's *constant* 100% all-the-time maintainance, because now I have to add a filter to change those relative URLs you want in the database to absolute URLs so that the damn things will actually work where the content is displayed.

Something just under *half* of the views of the content I write are not actually viewed on my websites themselves. So, how do your relative URLs work then?

> Sure, add a filter to change example.com to example.co.uk, then try to administer that site from both urls.

Why in the hell are you trying to administer this site from both URLs?
Why should a site even HAVE multiple URLs for the same content? This makes zero sense.

> Sometimes you don't get to create a proper NAT environment.  Sometimes you are forced to adhere to a company's intranet regulations.

Convince them otherwise. Seriously, when presented with a stupid rule, stand the heck up and tell them that it's stupid. You may not get every contract, but you'll feel better about yourself at the end of the day.

And sometimes, you can convince them otherwise. Then the world improves.

> Explain how with wordpress on a load-balanced setup, you could use a DNS trick, to access server4 by IP address, click links, administer content without being redirected back to the gateway when wordpress hard-codes www.gatewayhost.com in every link ever sent back to the browser.  IT CANNOT BE DONE.  If it's so easy, just publish a really simple step by step example for others to understand how.


1. Edit the Hosts file.
2. 1.2.3.4 example.com
3. Done.

Seriously, the load balancer is directing traffic, but only if you hit it. If the directly line to the server is available, then simply bypass the load balancer. How you do that depends on your setup, but assuming it's doing DNS-based balancing or even HTTP traffic forwarding, then you can just hit that server directly instead of hitting the load balancer. Hell, I've used this method before. On a java server I set up, the load balancer was doing traffic forwarding (all HTTP), but to hit the individual servers, all I had to do was use their IP address directly.


> Again, you don't understand the problem domain if you think this has nothing to do with how WP sends url's to the browser.  When on a WIFI network that doesn't support DNS Tricks, you CANNOT ACCESS WP ADMIN WITH YOUR iPhone.

You cannot access wp-admin if you're using the wrong URL of the site, period. And that's as it should be, because anything else is a security issue.


> Root-relative urls do not require post-processing the crap out of anything.

They requite converting the relative URLs to absolute ones for half of my readers. How is that not post-processing?

> And nice to see that you ignore the DRY aspect of not repeating your domain name in a URL when it doesn't need to be repeated.

The domain name absolutely DOES need to be repeated. DRY doesn't enter into it.

The whole point of an absolute URL is that it is *absolute*. That is *intentional*. That is a *good and desirable thing*. That's the whole bloody point I'm making. Absolute URLs work in contexts outside of the website. Relative ones don't.


> Using the same content everywhere is not possible, as expressed by the multitude of problem areas I'm pointing out.

Using the same content works fine as long as you don't tie the content tightly to the context in which it is displayed.


On Fri, Oct 28, 2011 at 2:49 PM, Marcus Pope <Marcus.Pope at springbox.com> wrote:
> 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."

No, it works in both places, because the URL shouldn't change just because the content moved. I want a link to point to a specific place, and I want an image to come from a specific place. If I move the content, but not the image, and the URL changes, then the content is now broken.


> 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're making the assumption that staging.* and production.* are using the same dataset, unaltered. They should not be. The staging environment should be wholly separate from the production environment.
If you need to write a script to re-up staging every so often, then you can filter/alter your data there as needed. But the content between them should absolutely not be shared. In companies I've worked at, it explicitly could not be such. That'd get you fired, as well as being against the law in some ways.

Production data *stays* in production. You don't use it for testing.
You don't use it for staging. You can copy it for testing on the copy, but you never ever operate on it live from another system.


> If you think considering your viewpoint as narrow is me being a dick, then I'm sorry you took offense.  But that doesn't mean you're any less of a dick.  I'm not here to convince YOU, I'm here to convince OTHERS who read both of our comments and may not necessarily have the technical skill sets to understand who's right and who's wrong.

No, I consider your attitude to be what is making you out to be a dick here. You're espousing a point of view, and that's fine. But you're completely ignoring what I see as the VAST MAJORITY of uses of the software.

Yes, okay, you move sites around a lot. I get it. That's great and maybe your ideas help you. Fine.

But most people *don't* do that. Most people write content in order to have that content read by other people. And your ideas make that a) harder and b) broken. That's what I'm trying to get across to you.
Your viewpoint is your own, and by far not the correct viewpoint for the majority of people.

That's what I want you to see here. You think that relative URLs are some kind of fucking godsend idea, whereas I'm trying to tell you that using relative URLs would *not work* for me or the majority of people who aren't building sites but are instead just publishing their content. They cause myriad problems and make things fundamentally broken. They screw up the whole notion of portable content, and require a metric fuck-ton of code and CPU work for post-processing. In other words, for the case where people aren't moving sites around constantly, relative URLs are a total bitch and a half. That's what I'm trying to explain to you.

Also, everybody on these mailing lists knows that I'm a dick already.
So I have no problems there.


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


Feel free to not use WordPress then.


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