lunes, 15 de septiembre de 2014

evironment specific wordpress configuration

Everyone who has ever setup Wordpress knows the wp - config.php file and all settings that you can define there, this works fine to configure your wordpress instalation on any given environment but there are times when we have to work on different environments or stages as your applications is developed, tested and installed on production.

I have worked on companies that have one local environment per developer, then one for QA(quality assurance), another for staging and finally other one for production, in some cases there is a development environment where all development code is merged so developers can test their changes with what others have done, there is not a right answer here but one thing is for sure you don 't have the same settings on each of those environments and you don' t want to, here are some reason why that is the case :

  1. your local working copy: you want to be able to do just anything and you don 't care about database access rights so is usual to setup for example mysql root account without password.
  2. staging environment: you want to configure your database and the settings of your application to be as close as production as possible but this environment is accessible to a lot of people like: QA, software architects,  system administrators and perhaps even developers so you want to keep things simple and share easy to remember passwords with those who need them.
  3. production: this is the place that you want to keep protected, very specific user access rights, security policies, strong passwords, and so on. Maybe only certain sys admins whose are trust worthy can access here and see the application event log and change/install/update any required software.

With all of that being said here a simple example of a possible configuration of database users and privileges using MySQL 5.5.x, see here for a complete list of all supported Privileges and how to grant them.

environment user name permissions
local root ALL
staging root ALL
production root ALL
production app_user SELECT, INSERT, UPDATE, DELETE

Now let's say that you want to use root on your local without password, on staging you want to configure qa and use app_user for production.

Here is an example of your wp-config.php file for production, is very likely that you will just provide an example with place holders, then a sys admin will replace with actual values and deploy the final file to production environment.

Now the questions is: how do we allow different settings on staging and local environments? some people will just edit the config file to adjust it for every environment however this is very dangerous because you could end up overwriting one or more of those files and if you do override production your site will not work.

My suggestion/solution
inspired on this wordpress plugin I got the idea of defining an stage constant and then use that constant to load an environment specific configs file, another way could be just checking if an environment specific file existed but I think using a constant is better.

So we need to update our wp-config.php file making sure that it contains the WP_STAGE constant and that this is used to load the right configs file, here is how it looks like:

And this is how the wp-config-local.php looks like:

As you can see if you define some value for WP_STAGE constant and you create a file named like: wp-config-{WP_STAGE}.php the original (production settings in this case) will be ignored and your stage specific settings are loaded instead.

You may use local settings as default and create an specific version for production and staging. In my example I am loading and external file OR what is defined on wp-config.php so If something is required in many environments I will have to redefine it as many times as it is required, you could "move" this common setting to wp-config.php outside of the if block. In the worst case scenario if by accident you upload any of your environment/stage specific configs to production it will not be used unless your WP_STAGE constant is also changed and your production files are not going to get overwritten.

No hay comentarios:

Publicar un comentario

Deja tu comentario :D