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

[Marcus Pope]

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

> So basically, your solution is to process the content differently depending on where that content is going to.
> For the love of god man, *why*? A whole bunch of code doing detection or post-processing, just so you can leave out the
> domain name? I can think of no greater maintenance hell.

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

> Multiple country TLDs - So your solution to not having to post-process URLs is to post-process URLs? Seriously, changing
> example.com to example.co.uk is a simple filter. Making everything root-relative and then post-processing to add in domains
> later is a much more complex filter, and one you'll have to use more often.

Sure, add a filter to change example.com to example.co.uk, then try to administer that site from both urls.  Have your UK admin add content from that url, and your US admin add content from the other.  See what happens to your user experience when those URLs are hard-coded in the content.

Replacing ^(/.*)$ with $_SERVER['HTTP_HOST'] . $1 is the easiest filter ever.  Replacing example.com with example.co.uk is far more complex if you follow the complete rfc for domain names. And it leads to a slew of other problems I previously mentioned that you failed to address.

> Internal v external NAT rules - Should be worked around by creating proper NAT environments or using internal DNS servers
> for correct internal address resolution.
> Debugging load-balanced servers by IP address - Easily solved with DNS tricks or hosts files.

Sometimes you don't get to create a proper NAT environment.  Sometimes you are forced to adhere to a company's intranet regulations.  If you work on ANY defense contract you WILL be presented with having to host www.dod.gov, and access it via internal.dod.server1.net if you are on their intranet.  This is obviously a made up example, but the example is pervasive in enterprise industries, not just government networks.  DNS tricks are not allowed and therefor are not a solution.  Relative root urls solves this.

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.

> Accessing internal dev environments on an iPhone - Has nothing whatsoever to do with relative/absolute URLs.

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 have to publish it to a production URL before you can test any of your admin features via the iPhone.  In some cases it's not even your WIFI network, it is your client's and for security reasons related to PCI compliance you are SOL because you can't hack, let alone access their DNS configurations.

> Following DRY & KISS principles - The KISS principle would state that it's better to use the same content everywhere rather
> than try to post-process the crap out of it based on friggin' context detection methods.

Root-relative urls do not require post-processing the crap out of anything.  They actually reduce the total amount of post-processing that WP core currently does - see the HTTP/HTTPS point.  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.  Using the same content everywhere is not possible, as expressed by the multitude of problem areas I'm pointing out.

> is str_replace('http','https'...) too complicated?

No, it's not complicated it's just unnecessary.  We call that post-processing the crap out of your url because you violated DRY principles.  Adding complexity to the system (KISS) and ultimately has led to dozens of bugs that still exist in the WP core trac database.

> Look, bud, you can rail on me all you want to. I've been programming for my entire adult life. I have 13 years professional
> experience, and I've been coding for the web since 1997. My viewpoint is not "narrow", and if you want to be a dick and rag
> on me, that's fine. I don't care. I'm just stating it like I see it. You're free to disagree, but you're *not* going to convince me
> with silly arguments like these.

I've been programming enterprise software for 16 years and started systems programming in 1993, and web programming in 1994, does that mean I'm right? No, years of experience has nothing to do with it.  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.

> If you're going to do that sort of thing [htaccess rewrites], then why need relative URLs in the first place? Rewrites work just
> fine. Or a simple filter to change the domain.

Again, you don't understand that it is not possible without root-relative urls, when the WP core validates your domain against a hard-coded value in the database and redirects you to that domain as a result.  Htaccess solves the every so rare use case that you are moving sites AND changing site structure as well.  URL rewrites were invented to solve this very problem.

> Bud, if you're not going to write your code to account for *what actually exists*, then we already have a un-compromising
> difference of opinion.
> Yes, in theory, they work fine. In actual fact, they don't. So call me crazy, but I'm working on facts, not theories.

And yes in actual fact, you would post process content in this very isolated case, along with emails and any other EXPORT of content.  You could write ONE function call it EXPORT_CONTENT(), route everything through this and call it a day.  Real world solution to a real world problem.  A plugin could do this and still reduce overhead that exists in the WP core.

>> But root relative URLS are just as easily parsed by search engines, so stop preaching your misinformation.
> Oh, so you know that all search engines that exist, and have seen their code, and know that they all work absolutely
> perfectly? Bully for you.

I do know that any search engine that matters or is functional HAS TO DO THIS because over half the internet does.  If it didn't do this, they wouldn't just be lost on my site, they'd be lost on A MAJORITY OF SITES that are built on reputable frameworks that you think suck.  It's called logic and programming for reality a point you made yourself.

> Again, call me crazy, but I'm not the kind of person to take other people's code working perfectly on faith. I prefer to assume
> that other people write crap code, because then I can write my own to attempt to work regardless of that. I'm not always
> successful with this approach, I grant you, but it's still a better way to work. IMO.

And you are welcome to your opinion.

-----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:23 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 12:25 PM, Marcus Pope <Marcus.Pope at springbox.com> wrote:
> Otto, you are just wrong.  You cannot use root relative urls in wordpress multi-site.

Sure you can. <img src="/root/relative/url.png"> works fine in a post.

> You are certainly presumptuous too, I have considered other medium as well (as has the entire enterprise development community), when you generate a book you prepend the domain to the root relative url in the same way a browser does it...

So basically, your solution is to process the content differently depending on where that content is going to.

For the love of god man, *why*? A whole bunch of code doing detection or post-processing, just so you can leave out the domain name? I can think of no greater maintenance hell.

> There are dozens of reasons to use root-relative URLs - here are SOME of them: multiple domain single IP hosting, Multiple country TLDs, accessing content on staging dev & production sites, reverse-proxies, internal v external NAT rules, debugging load-balanced servers by IP address, accessing internal dev environments on an iPhone, following DRY & KISS principles, Not HARD-CODING and wasting hundreds of processing cycles trying to deliver HTTPS urls to the browser when you store them all as HTTP.  Please understand that the technology world is not as narrow as you think it is.  Enterprise web software has been using these techniques for almost two decades now, you are just wrong and a trillion dollar industry does exist out there that proves it.

Multiple domain single IP hosting - Virtual Hosting works fine, and having relative URLs matters not one whit.

Multiple country TLDs - So your solution to not having to post-process URLs is to post-process URLs? Seriously, changing example.com to example.co.uk is a simple filter. Making everything root-relative and then post-processing to add in domains later is a much more complex filter, and one you'll have to use more often.

Accessing content on staging dev & production sites - You're doing your staging wrong. I've written about this before, but suffice it to say that your dev, staging, and production sites should all have the same domain names on them, not different ones. Furthermore, you can use DNS trickery or hosts files to then switch between them easily. I know this works, as I use exactly this method. It works fine.

Reverse-proxies - Reverse proxies don't care about relative URLs vs absolute ones, so this makes no sense at all.

Internal v external NAT rules - Should be worked around by creating proper NAT environments or using internal DNS servers for correct internal address resolution.

Debugging load-balanced servers by IP address - Easily solved with DNS tricks or hosts files.

Accessing internal dev environments on an iPhone - Has nothing whatsoever to do with relative/absolute URLs.

Following DRY & KISS principles - The KISS principle would state that it's better to use the same content everywhere rather than try to post-process the crap out of it based on friggin' context detection methods.

Not HARD-CODING and wasting hundreds of processing cycles trying to deliver HTTPS urls to the browser when you store them all as HTTP. - is str_replace('http','https'...) too complicated?

> Please understand that the technology world is not as narrow as you think it is.  Enterprise web software has been using these techniques for almost two decades now, you are just wrong and a trillion dollar industry does exist out there that proves it.

A trillion dollar industry does exist out there *and most of them do it wrong*.

Look, bud, you can rail on me all you want to. I've been programming for my entire adult life. I have 13 years professional experience, and I've been coding for the web since 1997. My viewpoint is not "narrow", and if you want to be a dick and rag on me, that's fine. I don't care.
I'm just stating it like I see it. You're free to disagree, but you're
*not* going to convince me with silly arguments like these.

> Why do you think every major legitimate MVC framework uses
> root-relative URL techniques by default (J2EE, MVC.NET, APS.NET even,
> Zend, ROR, Django etc)

Because they suck.

Seriously, MVC frameworks *suck*, for a lot of reasons. This is only one of them.

I do not use, and will very likely never use any form of MVC web framework again. I stopping using them specifically because of the maintenance nightmares.

> They do not limit you, have you ever heard of htaccess url rewrites?  That's how you solve that problem if you want to change the structure of your site without changing the content.  Even wordpress has a rewrite api module that could handle this.

If you're going to do that sort of thing, then why need relative URLs in the first place? Rewrites work just fine. Or a simple filter to change the domain.

> Actually, root-relative URLs work everywhere in theory, it's only in practice where people make poor programming decisions (like feed readers that ignore the channel-link element) that it fails, or import/export systems that fail to include base domains in processing logic.

Bud, if you're not going to write your code to account for *what actually exists*, then we already have a un-compromising difference of opinion.

Yes, in theory, they work fine. In actual fact, they don't. So call me crazy, but I'm working on facts, not theories.

> But root relative URLS are just as easily parsed by search engines, so stop preaching your misinformation.

Oh, so you know that all search engines that exist, and have seen their code, and know that they all work absolutely perfectly? Bully for you.

Again, call me crazy, but I'm not the kind of person to take other people's code working perfectly on faith. I prefer to assume that other people write crap code, because then I can write my own to attempt to work regardless of that. I'm not always successful with this approach, I grant you, but it's still a better way to work. IMO.


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