Opened 10 years ago
Closed 10 years ago
#25029 closed feature request (wontfix)
Multisite Installations in Multiple Environments
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | 3.6 |
| Component: | Multisite | Keywords: | |
| Focuses: | Cc: |
Description
Background
Assume that there are four environments that a site needs to exist in: local, dev, uat and live.
The Problem
For single sites, it is (fairly) easy to control url settings (WP_SITEURL and WP_HOME) that vary from environment to environment, based on facts about the environment obtained via $_SERVER properties. This allows for defining all environment based settings in single file that can be track via version control and pushed up through local, dev, uat and live.
However, since multisite environments ignore WP_SITEURL and WP_HOME definitions, developers have to manipulating the database when switching from environment to environment. Moreover, these changes are typically not reflected in any version control system that might be in place for the build.
The Solution
I believe these site settings should be allowed to be overridden in files before checking with the database. Beefing up environment based configurations needs some love in general, but especially for multisite installations.
Before I dig into this, I'd like reassurance that this is indeed an area that is lacking and needs improvement in. Also, if there are any suggested ways of handling this, please make suggestions.
From the description above, it sounds like a
sunrise.phpmay help a bit. See http://plugins.trac.wordpress.org/browser/wordpress-mu-domain-mapping/trunk/sunrise.php for an example of how the WordPress MU Domain Mapping plugin does its own checking to set the$current_blogvariable based on the requested domain. I'd imagine something similar could be done with environment checking. If it's truly important that the URLs are modified in the database, I would start with a script that does so during your deployment process between stages.There are probably several discussions to be had on how to approach this. I would recommend sending something to the wp-hackers list or starting a topic on the forums as it isn't likely to be something that core can account for properly.