Make WordPress Core

Opened 2 years ago

Closed 2 years ago

#25029 closed feature request (wontfix)

Multisite Installations in Multiple Environments

Reported by: wesrice Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.6
Component: Multisite Keywords:
Focuses: Cc:


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.

Change History (2)

#1 @jeremyfelt
2 years ago

  • Keywords close added; 2nd-opinion ux-feedback removed

From the description above, it sounds like a sunrise.php may 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_blog variable 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.

#2 @jeremyfelt
2 years ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.