Running late with this blog – partly due to external factors, partly because I have disappeared down in interesting but intricate VersionPress-related rabbit hole. I’ll show you round some of it!
Although I found that getting VersionPress up and running with my custom structure was relatively straightforward – things became a lot more complicated as soon as I tried to follow the clone process. My fault of course for mixing up experimental software with a non-standard set-up.
To cut an overly long story short, for the sake of this exercise, I (temporarily?) jettisoned my non-standard location for
wp-content. I did, however, keep WordPress in a subdirectory – because I don’t want to lose that layer, even to win a superior workflow.
Now that I’ve performed a trial run, I’ll work through the set-up and clone process again and document it here.
First of all, after some reasonably bitter experience, I remove my pre-existing git configuration. According to the documentation, VersionPress plays well with pre-existing repositories, but I’d like to keep any noise to a minimum. For the same reason, I disable all other plugins. I move
wp-content back to its default position.
So now my directory structure looks a little like this:
gistaging gistaging/site/ gistaging/site/wp gistaging/site/wp/wp-content gistaging/site/wp/wp-content/plugins gistaging/site/wp/wp-content/themes
My web root is
gistaging/site/wp but my WordPress installation is at
Because the object of this game is cloning, I need to make an amendment to the
wp-config.common.php file. I previously had the
VP_PROJECT_ROOT constant (necessary for a subdirectory WordPress install) hard-coded to a filepath. That will confuse things mightily on clone (as I found out during the dry run). The fix is easy:
VP_PROJECT_ROOT to the path of the
wp-config.common.php file’s containing directory, which is what we want. (Remember
wp-config.common.php is an uber-configuration file that only contains shared directives and can therefore be checked into git. I covered it in the previous VersionPress article).
I cleared down my old VersionPress set up, so I reinstall it now. Since I already have the correct version of Git compiled and referenced in my
wp-config.php file, and I’ve managed my file permissions, it’s pretty much a three click process.
I have set up a subdomain:
gidev which will eventually point to my clone. In order to generate it, I need to run a special wp-cli command:
wp vp clone.
Be warned that there seems to be an assumption built-in to the clone process that you both have the wp-cli executable in your path and that it is named
wp (I had to alias my local wp-cli script – easy enough to do).
I am going to run
wp vp clone from the
gistaging/site directory (my web root). Here goes:
$ wpcli vp clone \ --name=gidev \ --dbname=gistaging \ --dbuser=gistaging \ --dbpass=u9yuhjnj8t \ --siteurl=http://gidev.getinstance.com Success: Site files cloned Success: Clone added as a remote Success: Enabled pushing to the original repository Success: Enabled pushing to the clone Success: wp-config.php updated Success: Copied VersionPress Success: Database tables created Success: VersionPress tables created Success: Git merge driver added Success: Database synchronized Success: All done. Clone created here: Path: /var/www/gistaging/gidev URL: http://gidev.getinstance.com
Note that I had to delete a few files from the plugin code to get my clone to work. This seems to be related to some symlink weirdness and it may be a local issue — I will have to investigate further. Also, beware of that
--siteurl flag. In fact it’s the
home url. In other words, there’s no need to specify the subdirectory.
As you can see, the command has assumed that my web root directories will sit side by side.. so it has put the new
gidev directory at
gistaging/gidev, parallel with my
site directory. That’s not too much of a problem, I’ll just move it across to the location I want (
$ cd /var/www $ sudo mkdir gidev $ sudo mv gistaging/gidev/ gidev/site $ sudo chown -R mattz:mattz gidev
There is another gotcha here, however. VersionPress generates git configuration to maintain the relationship between the new clone and the origin. Now that I’ve moved the clone directory, I must update the
.git/config file for both installations.
For the clone, I can now find the file at
/var/www/gidev/site/.git/config. Buried away in there is a hardcoded path that points to the old generated location of the gidev clone. Since I’ve moved things about, that’s no longer correct. Here’s what it looks like now:
[core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = /var/www/gistaging/site [branch "master"] remote = origin merge = refs/heads/master [receive] denyCurrentBranch = ignore [merge "vp-ini"] name = VersionPress ini merge driver driver = /var/www/gistaging/gidev/wp/wp-content/plugins/versionpress/src/Git/merge-drivers/ini-merge.sh %O %A %B recursive = text [user]
I change that path so that it’s correct.
[merge "vp-ini"] name = VersionPress ini merge driver driver = /var/www/gidev/site/wp/wp-content/plugins/versionpress/src/Git/merge-drivers/ini-merge.sh %O %A %B recursive = text
There’s a similar change to be made in the gistaging environment (my original site). During the clone process, its git configuration was updated to point to the new gidev installation – and again that’s now pointing to the wrong directory. The file is at
/var/www/gistaging/site/.git/config. Here it is:
[core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [merge "vp-ini"] name = VersionPress ini merge driver driver = /var/www/gistaging/site/wp/wp-content/plugins/versionpress/src/Git/merge-drivers/ini-merge.sh %O %A %B recursive = text [user] [remote "gidev"] url = /var/www/gistaging/gidev fetch = +refs/heads/*:refs/remotes/gidev/* [receive] denyCurrentBranch = ignore
That path is going to have to change:
[remote "gidev"] url = /var/www/gidev/site fetch = +refs/heads/*:refs/remotes/gidev/*
Hopefully a future version of the
wp vp clone command will support a custom directory location.
I have already configured my webserver to point the gidev subdomain to
/var/www/gidev/site so am I good to go? Let’s take a look:
Not a bad start. Something is up with the panels on the front page – I’m seeing the same one presented over and over again. It looks as if I’ll have to investigate the Twenty Seventeen theme’s settings. Also the
.htaccess file was not copied across from origin to clone – which means the permalink scheme did not work right away. It’s easy enough to copy over the file by hand and my links work again.
There may be an image path issue too but I’m not entirely convinced that this isn’t due to the battering I’ve given my sample post data during the testing process – I’ll table that for further investigation.
Minor issues aside, it looks like I have my parallel sites. How will they interact? That’s for the next article.