Photo by rawpixel on Unsplash

Wordpress on different environments with Versionpress

Is basic for any development team to know how to work in different environments, without it, is completely impossible to organize your workflow, and soon or later, the catastrophe will come.  

Sorry for the newbies, but I am not going to talk about how much important it is, if you are reading this is because you know how much WordPress sucks by his self, as for add multiple developers into a project. But this is how it is, and at the end of the day everybody needs a team, so if it this can be done with other CMS, it can be done with WordPress too.

Before everything, the main problem is: The database dont travel with git. 

Yeah, don't think more about that, is impossible and is the worst practice in the world to upload a database from one environment into other. Just the code travel.

So, we need something to transform the database into code. Imagine, all the configuration of the database storage into a couple of .txt files that will be reimported automatically into the database of the desired environment. There are many solutions, but the concept is the same. Today I am gonna explain how to do all that with versionpress


First of all, versionpress still in development, and have some issues. The community is active and you can find them on Gitter if you have any question. 

Second, it depends on some obvious tools that you need, and need to have access from your terminal, console or cmd. 

So, please, check that you have these little tools: 

$ mysql --version
$ php --version
$ git --version
$ wp --info

So, you need to have access from the command line to PHP, MySQL, GIT, and WP client. Later we will run an extension from the wp-cli command that will create your entire site (with PHP and MySQL) and synchronize with your development/production site. In the backstage, it will be using all those commands. 

From the development site "A":

Okay, let's imagine that you are the developer "A"  and will start with the project. The first step is like anyone, in fact, you can add versionpress to your current project, the beginning is normal, installing WordPress, adding some plugins, your custom theme, some PHP functions, etc etc. In some point (is better at the very beginning cuz you have commits from the minute 0) you have installed versionpress, it is not on the plugins libraries from WordPress so, you need to download from GitHub, and manually install it. After that, your site will transform and shows you a new window. 

commits from versionpress

Now, forget about WordPress for a second, and upload your code. And when I say, upload your code, with versionpress that also means, upload your database, cuz in the exact right time that you installed versionpress, it transforms all your database into .ini files. And with a couple of git commands you have your entire code up:

$ git init
$ git add . 
$ git commit -m "init"
$ git remote add origin
$ git push

And that is all form the developer "A". The code is on the cloud, and the database too. So anyone who accesses into your repository can clone your site, and without the database recreate it!. 

From the development site "B"(or production site if you want):

Here we have another perspective. First of all, we don't have the database or the config file. And both of them are necessary for any WordPress site. 

First, get the code: 

$ git clone "" 

Now, create a new database, you need a place to put your changes. 

$ mysql -u root -p
Enter password: *****
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 2677
Server version: 10.1.33-MariaDB binary distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> create database newVersionpresTest ;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> exit;

Now create the config file (inside of our WordPress directory). This will create a wp-config.php file without Database password. 

$ wp core config --dbname=newVersionpresTest --dbuser=root

We also need the versionpress plugin installed on our WordPress. Our site is not working yet, so let's do it manually, and include the versionpress plugin in the plugins directory. 

Now is time to restore-site, which means fill the database with all the .ini files. 

$ wp vp restore-site --siteurl=http://localhost/mysite --require=wp-content/plugins/versionpress/src/Cli/vp.php

The siteurl param don't need '' and if you are on a specific port, include it, for example, http:localhost:8080/mysite

So, that is all, both sites are synchronized, all the things for one point are in the other. So happy coding! 

Now what?

Now comes the interesting part, the ping-pong game!. Cuz we need to send information from one environment to the other one, without recreating it, obviously, and taking care with the merges!. I will write a blog about that later.