I just spent a bunch of time reading old arguments
about whether WordPress should support root-relative URIs to assets and content. It boils down to:
Web developer: Relative URIs would make it much easier to test my site on a different host before I make the changes live.
WordPress developer: Absolute URIs everywhere is better than relative URIs everywhere because there are cases where relative won't work.
Web developer: Yeah, but absolute URIs make testing and migration a pain in the ass.
WordPress developer: Just edit /etc/hosts to think that your live webserver runs on your workstation. Or run a find and replace on the SQL export of your database.
There's also, apparently, config values for base URLs, but just setting those on a site you're trying to migrate apparently doesn't have any effect because the real problem is that WordPress stores internal links as URLs
. The proper solution would be for all links to other WP content to be stored as a reference, then turn references into URLs at render time. This, for example, is the approach of every wiki system: [topic] turns into a link to http://example.org/wiki/Topic
Unfortunately, this isn't the sort of problem you realize WordPress has until you've already built a site and need to move it around (like, say, to the production server) and you discover that you've just built your site on a platform that doesn't prioritize release processes. But by then, the cost of rebuilding on some other system is probably much higher than doing something hacky and limping along on a platform with dorky production hygiene.Update:
The handy wp-cli command line utility
can do a global search and replace for your host name:wp search-replace badidea.example.com bettername.example.com
Of course, if you've got a post like "Update your old links; we're no longer badidea.example.com" then it'll say "we're no longer bettername.example.com." But at least this is an automatable process.