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 /gistaging/site/wp.
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:
define('VP_PROJECT_ROOT', __DIR__);
That sets 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 (/var/www/gidev/site).
$ 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.
