site_url(),home_url(), get_stylesheet_directory_uri(), get_template_directory()

I’m trying to figure out the rationale behind site_url(), home_url(), get_stylesheet_directory_uri() and get_template_directory_uri() override the values of WP_SITEURL and WP_HOME defined in wp-config.php with the corresponding values from the wp_options table.

Here’s my situation. I’ve got a production site set up at, say, https://www.example.com, with WP_SITEURL = WP_HOME = https://www.example.com.

I’ve also got a development site set up at, say, https://dev.example.com, with WP_SITEURL = WP_HOME = https://dev.example.com. Both the development and production sites use the same database (eventually I’ll get around to having a separate development database, with the ability to have the development site switch between the 2 databases, see my third question below).

When I set up the development site yesterday I was shocked to find out that when I accessed the development site all resources (e.g., things accessed via wp_enqueue_style() and wp_enqueue_script()) where using the production URL. I had assumed that since I defined WP_SITEURL and WP_HOME separately in the development site’s wp-config.php that all URL’s generated by WP would use the development site’s URL.

So, my first question is: can anyone explain (or point me to an explanation of) why WP does things this way? I was prepared for absolute URLs in post_content, attachments and such…but not for enqueued scripts and styles.

What I’ve done to get around this is add filters for site_url, home_url, stylesheet_directory_uri, and template_directory_uri (and the_content) that are like:

function
my_site_url ($url, $path, $orig_scheme, $blog_id)
{
	if (my_is_dev_env ()) {
		return (str_ireplace ('www.example.com', 'dev.example.com', $url)) ;
		}

	return ($url) ;
}
add_filter ('site_url', 'my_site_url', 1, 4) ;

where the my_is_dev_env() function consults $_SERVER['SERVER_NAME'] to know whether it is running in development or production.

So, my second question is: are there any other filters that I should/must define in a similar manner to cover cases I haven’t thought of yet?

My third question is about extending the development site to be able to switch back and forth between a development and production database. That is, what I’d like to have is the development site default to a development database, but write a plugin that allows me to dynamically switch it over to the production database (i.e., without having to manually modify wp-config.php). Does anyone have any advice about the best way to write such a plugin? There’s gotta be a better way than having the plugin rewrite wp-config.php, but since wp-config.php gets loaded so early in the WP initialization process (it’s the first thing, right?), there are no hooks that a plugin could exploit to redefine DB_NAME, etc (since plugins are loaded when wp-config.php is loaded).

One Idea I have I got from looking at require_wp_db() in wp-includes/load.php, where I see the following:

if ( file_exists( WP_CONTENT_DIR . '/db.php' ) )
	require_once( WP_CONTENT_DIR . '/db.php' );

but I can’t find any documentation on what that file is supposed to be used for. That is, is it safe to have my plugin just rewrite that file, defining DB_NAME, etc. None of the other plugins that I am currently using on my site counting are counting on wp-content/db.php containing anything specific, but it doesn’t seem safe since other plugins that I might decide to use in the future might be counting on something specific being there.