Root Relative URLs

There was a long outstanding support issue regarding these problems that I think is resolved from my plugin perspective.

The core issue (https://core.trac.wordpress.org/ticket/21824) is still not fixed, and the temporary workaround for that problem is to go into Admin > Settings > Permalinks, and click “Save Changes” twice in a row, letting the page reload between each save.

This should fix the rewrite rules used internally to WordPress to route URLs to custom post content, more links.

A root-relative URL is a special type of relative URL that always starts with a forward-slash (/)

Traditional relative URLs are bad because any change to your directory structure can change where the content is relative to.
But Root-Relative URLs are good because you’ll always know where they start, and search engines support their usage so you’ll have no problems with SEO.
In fact, over 93% of the top 100 websites (according to Alexa) use root relative urls. Including Wordpres.org, WordPress.com, Facebook.com, Twitter.com, Google.com, Wikipedia.org, Yahoo.com, Youtube.com, Amazon.com, Fickr.com etc.
Most RSS Feed readers handle them appropriately (notable exceptions include FeedBurner and FeedBlitz) but my plugin takes into account their lack of HTML specification adherence.

In fact, root relative URL support was established in the very first HTML specification (where it remains today) by Tim Berners-Lee (the real inventor of the World Wide Web) way back in 1993:

“Where the base address is not specified, the reader will use the
URL it used to access the document to resolve any relative URLs.”

Some WordPress core developers think this is “doing it wrong” and “may not be supported in future content platforms like books.” But I can assure you they are a core & valued aspect of the web and are not likely to go away. (I’m currently trying to explain to FeedBurner & FeedBlitz how it’s their responsibility to improve their support for the RSS format and not that of others to adhere to an archaic practice like absolute urls.)

Good question. There are a number of core developers who think the design decision makes an end-user’s life easier. But that’s only for those who maintain
one site and make all of their edits on that public site. Professional web developers would never consider making changes on a production site because if a mistake
were made (yes even professionals make mistakes) then you have an immediate problem in production. Instead changes should be made on a development or staging
server first, thoroughly tested, and then migrated to production as a best practice.

With root-relative URLs you can make and test your changes on a staging server and then, when the changes are completely vetted, move your changes to your production
server. You could do this with absolute URLs as well, but that adds an extra step of doing a search / replace of all http://staging.com/ links to http://production.com/.
This extra step is not required in most content management systems. And a step that can potentially break your site depending on what widgets and plugins you are using (http://www.interconnectit.com/719/migrating-a-wordpresswpmubuddypress-website/)

Additionally, unless you are a network administrator, testing your staging URL on an iPhone or other mobile device is really difficult because the recommendation for
staging environments by WordPress core members is to edit your hosts file. Only you cannot edit hosts files on a mobile device, so you’d have to resort to complex
router configurations that many people don’t have at their disposal on typical WIFI networks.

Unfortunately no, this plugin is designed to correct new content as it is entered via the administration panel. It will still work with your current site,
but it will not alter links you have already embedded.

Absolutely! Just because you have only one site now doesn’t mean you won’t have a staging site in the future. If you ever decide to contract out professional
development services you’ll want to work with someone who does follow this process. And at that point in time it will be a nice time-saver if you have already
developed content that works with root-relative links.

Sort of. It will work for path-based MU sites, but not for domain-based sites due to an architectural flaw in the WordPress core. However, for it to work with path-based installs you
will need to patch a WordPress core file – or wait until the WordPress core team implements this fix – https://core.trac.wordpress.org/attachment/ticket/18910/ms-blogs.php.patch

Until then this plugin will not work out of the box for MU installs. I have discovered an approach for resolving this problem without a core hack but I will need to research it before implementing the update. It will be a big ol nasty hack but it will work.