This is weird. I’ve never really heard people in the WordPress developer world talking about “environments”, and suddenly everyone is doing it (or, possibly, suddenly I’m aware that everyone is doing it).

I’ve been thinking about this myself for a little while.  Let me first explain what I mean by “environments”.

Often with medium/large WordPress projects you have a dev/staging/test site (or more than one of those) and a live site. These will be mostly identical, but may have things like different plugins enabled, or different settings/options (like a Google Analytics ID).

I’ve just started thinking this week about how to automate stuff like this and it was great to see in the “Call for features” for WordPress 4.4 on the Make blog lots of people suggest some kind of environment system in core. This was then followed by Devin Price blogging about the same topic.

I’ve left a comment there, but thought I’d post some details of my thinking here.

It occurs to me that there’s a number of ways to achieve this:

  1. Actual environment variables on the server
  2. Constants in wp-config.php
  3. The options table

But what I think would be REALLY handy is a combination of stuff in wp_options and wp_config.php.

I don’t know precisely how this would work out. Maybe an extra column in wp_options would be best. But I envisage that there is a default environment, and all settings in this default environment are used unless they are overridden. And then there are specific environments; so if an options entry has an environment specific option then it takes precedence over the default.

Then you just have a simple constant in wp_config.php that sets the environment.

The cool thing about this is that it lets you set things up using the WordPress dashboard if you want to. You make the test/dev environment your default, and then you set the live environment up before you put the site live as a set of option overrides. You can do that by temporarily changing the environment using wp_options.php, setting the site up in its live config, and then changing the environment back.  You can then push your whole database to the live server safe in the knowledge that it will get the live config.

It’s also worth noting that this includes which plugins are enabled, because active plugins is just an option.

I’m sure this isn’t thought through and there will be things like serialised data to take into account, and there will be some kind of UI, but something like this seems like a great concept.

But I’m also sure that it would be really simple to code this up in this form really easily. In fact, you could probably just filter the option name as you save/retrieve it and prepend or append a prefix based on the environment name.

Perhaps I’ll have a go at this at some point. Interesting though. I wonder how other people have solved this problem and if plugins already exist.