Today I began my evaluation of the VersionPress plugin Setup is not without its wrinkles, but then it’s alpha software and covers some quite complicated ground, so that’s to be expected.
A quick reminder of my objective here. One of the problems with WordPress is the fuzzy distinction between platform and content. During initial development, a traditional model with a development environment, a staging server, and a production install is easy enough to maintain. You simply clobber along the chain, overwriting as you go. Life immediately becomes more complicated once more than one person is working at the same time, or once your site has gone live and content is produced there while development continues upstream. There will probably never be a perfect solution to his problem – database merging is notoriously tricky and error prone. But we may be able to improve matters somewhat. This is what VersionPress promises.
First of all, I need to acquire the current stable-ish version from github. No Composer or wp-cli tricks for me today. I simply unzip the archive and copy it into my plugins directory.
$ unzip versionpress-4.0-alpha1.zip
$ mv versionpress/ site/wp-content/plugins/
I head to the plugins admin screen and I see an unusual message on activation.
That link ‘please finish the activation’ is my first clue that this will not be an entirely straightforward procedure. Let’s click on it.
Quite a lot to fix before we can proceed. It needs write permissions in all sorts of places – that’s easy enough to grant. The trickiest part for me is the minimum 1.9 version of git the plugin requires. My staging server is running 1.7.1 and upgrading the common git would be difficult for various reasons invoving other projects in progress. In fact, compiling a standalone version of git is pretty straightforward. I follow some instructions for setup on CentOS, and run the basic
$ make
$ make install
compile/install process. I copy the git executable from the default location of ~/bin to somewhere accessible (/tmp for this example). Then I have to tell VersionPress where to find it. This is a matter of adding a constant to the wp-config.php file:
define('VP_GIT_BINARY', '/tmp/git');
Just as I created separate ini file for configuration, VersionPress needs to manage the problem of committing site specific values to version control. It handles this by requiring its own shared configuration file: wp-config.common.php – which should sit beside wp-config.php. Because I have a non-standard directory structure I need to tell VersionPress where the project root is to be found:
define('VP_PROJECT_ROOT', '/var/www/getinstance/site');
Unless every development site uses the same location, that hardcoded path may be problematic in future since the purpose of using the wp-config.common.php file is to allow non-site-specific values to be pushed to a shared git repository. It will be easy enough to fix the path to something relative, though. With some judicious use of chgrp and chmod to make my installation writeable, I should be ready to go. I hit the activate button and let it do its thing:
So far so good. Now to add a test post and see whether VersionPress tracks it.
Well, that’s very nice – the version control equivalent of Hello World! More experimentation to come!
