Absolute urls can be such a headache especially when a site needs to be accessible from multiple domain names.
A site should never, ever be accessible at two URIs. The one URI should redirect to the other one. This not only provides a canonical location, but it is a lot more search engine friendly, as having the same content under more than one URI will incur a duplicated content penalty.
On an internal vs. external network
The two networks should be configured properly to map the domain name correctly on both sides of the network. If it needs to use an internal IP for that domain on the inside, then the internal DNS server should be configured appropriately.
or a lot of people like their site to be accessible from both mydomain.com and http://www.mydomain.com. Or what about a site accessible via https and http?
Both of these cases should use 301 redirects to redirect one of them to the other of them. www to non-www, for example. In the specific case of https, the server should only use https for the pages which need to be secured, as use of SSL encryption incurs an overhead which should be managed to be as low as possible.
But more importantly it makes the site really difficult to move from one domain to another.
a) It's really not that difficult. Using a simple search and replace tool which can handle multiple files is rather trivial. And your database backup is just a text file, search and replace works fine on it too.
b) You really should never change domains. I mean, not after the initial phase. All you're doing by changing domains is making it harder for your audience to find you after the move. Your domain is your identity, why would you shift it to somewhere else once it has become established?
This is really common for professionally built sites that involve continuous code development. You'll have development servers, a stagging server and the live server. Granted you'll hardly ever move data between dev and production, but it's not that uncommon to move data between dev -> stage and also stage -> live.
As a person who writes just such servers (my latest one handled $1.5 billion in transactions last year), I can say with authority that in no circumstance would data ever, ever, *ever*, move from a dev box to the production system. That would be just cause for getting fired. Period.
The other way (production to dev) would be acceptable. You have to test problems in dev, and sometimes production data is the only way to do it. But the dev data stays in dev. Nothing, and I mean nothing, moves into production without rigorous testing and no data ever moves in that direction.
I'm currently working on my first real wordpress customization site and the absolute url thing is proving to be a pain.
In what specific way? I've always found relative URLs to be a massive pain, because they cannot be trusted. The actual relative URI of an item will change extremely often on a dynamic site, because the URI is not linked to a specific directory structure.
A URI is an item's absolute location. It should never, ever change. Or, at least, changing it should be a big deal, to be considered and planned for in advance. A relative URI however, is relative to the current URI. What relative URI do I use for an image when my main page is http://example.com and my single page is http://example.com/2008/03/03/post-name and my category archive page is http://example.com/category/cat-name/ and all three of these can contain the same content? Sure, I can use a root-relative path, but using the absolute URI makes way more sense.