I won't go into detail on that here but know that there's a very good reason for it. Plugin and theme developers should be using for example `esc_url( home_url( '/' ) );` when requiring the URL of the site.
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.
Domenic_S|10 years ago
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.
csixty4|10 years ago
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.
Some relevant Trac tickets:
Guids No Longer Have Permalink Format (discusses changing the format) https://core.trac.wordpress.org/ticket/6492
Non-URL GUIDs are stripped on post update https://core.trac.wordpress.org/ticket/18395
ereckers|10 years ago
URLs delivered to the browser should be root-relative https://core.trac.wordpress.org/ticket/17048
WP Development & Production Sites http://lists.automattic.com/pipermail/wp-hackers/2010-Novemb...
Relative vs. Absolute URLs stored in db http://lists.automattic.com/pipermail/wp-hackers/2010-Decemb...
deckiedan|10 years ago
1) Users want to be able to update site-name (etc) from the admin interface.
2) We therefore need to store it somewhere.
3) We have a database!
The alternatives are:
- Storing in wp-config.php (which is also done...), but then it's not user-editable from the admin interface.
- Storing in a INI or JSON or similar document, which has only marginal if any benefits over storing in the database.
For deployment, since the location of the database values is fixed, you can set the variables with your deployment scripts.