Converts all URLs to root-relative URLs for hosting the same site on multiple IPs, easier production migration and better mobile device testing.
A WordPress plugin that converts all URL formats to root-relative URLs to enable seamless transitioning between staging/production host environments and debugging/testing from mobile devices, without the use of hackish tactics like textual find-replace strategies or risky hosts/NAT spoofing strategies.
With Root Relative URLs you can browse your development site from http://localhost/ or http://127.0.0.1/ or from a named network resource like http://mycomputername/ without worrying about links redirecting you back to your site's URL.
This plugin also modifies the tinyMCE hooks so links and media embedded with built-in tools will only insert URLs from the first forward slash after the domain (i.e. the root of your site.) This means when you push content changes to a staging or production environment they are guaranteed to reference the correct target instead of accidentally referencing a production resource in development or, worse-yet, a development-exclusive resource in production.
It supports path-based MU Installations, but does not support domain-based MU sites due to architectural deficiencies in the WordPress core.
Version 1.5 fixes an infinite redirect problem that is a result of a core bug in WordPress. If you have problems with the <!--more--> tag or permalinks for custom post types, please read the FAQ or new Install Steps for support.
Version 2.2 allows for adding certain URL's or partial URL's to a blacklist, meaning I won't use root relative urls, but dynamic absolute URLs instead for displaying content. This will fix problems with 3rd party plugins, and can be configured on the General Settings page.
FAQ
Installation Instructions
- Upload the plugin to the
/wp-content/plugins/ directory
-
Add the following entries to your wp-config.php file before the “That’s all, stop editing!” comment:
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST']);
define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST']);
define('WP_CONTENT_URL', '/wp-content');
define('DOMAIN_CURRENT_SITE', $_SERVER['HTTP_HOST']);
-
Activate the plugin through the ‘Plugins’ menu in WordPress Admin
- Save your permalink settings twice in a row (Admin > Settings > Permalinks : Save Changes) x2
- You’re done! Now you can happily browse and manage your site from any URL, including an IP address if you wish.
Infinite 301 Redirects, Custom Post Type Content and –More– links
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.
What is a Root-Relative URL?
A root-relative URL is a special type of relative URL that always starts with a forward-slash (/)
Aren’t relative URLs bad?
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.)
Why doesn’t WordPress use root-relative URLs to begin with?
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.
Will this plugin correct URLs that are already embedded in my site’s content?
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.
Should I use this plugin if I only have one production site and I make all of my changes in production?
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.
Will this plugin work with MU sites (Multi-user installations)?
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.
