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

[Otto]

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