Ok, as someone who's battled with this... feature... of WP I am super curious as to the very good reason for storing the domain in the DB. Why couldn't links be relative (no need to know the domain), or set only as a sitewide variable in wp-config.php?
edit: and just discovered the 'guid' column on the posts table is hardcoded as the URL of the post -- the domain you're on at the time you create the content + the post ID. Seems like a nightmare for content staging on a non-prod environment.
> just discovered the 'guid' column on the posts table is hardcoded as the URL of the post
It comes up every so often. The WordPress devs are well aware of the platform's warts & WTFs. People have talked for a while about replacing it with a proper UUID, but there are way too many themes & plugins that use the guid field to get the post's URL instead of calling, say, get_permalink( $post_id ).
So now the devs are stuck. You can deprecate "guid", but you can't get rid of it. You can't replace the URL with a UUID because of backwards compatibility with third-party code. Do you add a "uuid" column? Now you have a guid column & a uuid column and people are going to get even more confused.
Right now, content staging is a bit of an edge case and folks who need it are able to store a UUID in a post_meta field. So it's not a really critical issue. But it would definitely be nice to see a proper UUID in core.
Certainly there are configuration options that are appropriate to store in the database, but I'm trying to understand why domain is one of them. The site knows what domain it is on by virtue of being hosted on that domain.
Storing the domain in the DB may be reasonable if it's done once, but WP does it multiple times: WP_SITEURL ("the address where your WordPress core files reside"), WP_HOME ("the address you want people to type in their browser to reach your WordPress blog") and of course GUIDs for every post have the domain hardcoded into their values (that can mess up links in a weird way, where you're on your local environment, click a link, and now you're silently on prod).
I could definitely be missing something, but I can't for the life of me figure out why this is a good idea.
There are only two places where the URL should be stored. Anywhere else is an issue with the plugin or theme storing them incorrectly. Both are contained within the wp_options table for home URL and site URL. Those are the only values required to be changed. If you have a development environment, you should not be migrating the wp-config.php file anyway as it has sensitive information for product sites thus on your dev site you can have a separate wp-config.php file to take into account the new values for home and site URL's.
You aren't missing anything. This problem has been there in WP for a long time, and it makes staging/testing/migration setups a horrible pain (as others have suggested, lots of search & replace).
But, it's stored all over the place, not just a single table or file. All of the URLs on the site get put into the DB as fully qualified. Just today, I had to do a search-and-replace with wp-cli on 26k instances of the domain name in the db.
Giving users everything they want is a surefire way to build a disaster of a codebase. I have no knowledge of WordPress, that's just a general principle. Users are a bit too silly to trust.
edit: and just discovered the 'guid' column on the posts table is hardcoded as the URL of the post -- the domain you're on at the time you create the content + the post ID. Seems like a nightmare for content staging on a non-prod environment.