Now that I have two sites that mirror one another with VersionPress (gistaging – the origin and gidev – the clone) it’s time I tried out this plugin’s ability to manage post data across my installations. To recap, yesterday I simplified my WordPress file structure somewhat (though not enough to make my VersionPress set up entirely plug and play). Then I successfully generated a clone. Now let’s see how the two sites play together.
First of all, I will create a post to work with.
As we have already seen, VersionPress tracks the change:
My mission today is to see how the change might be shared. Over in my gistaging environment (in the directory /var/www/gistaging/site) I am ready to try it out. I run a custom wp-cli command – wp vp pull.
$ wp vp pull --from=gidev
Success: Maintenance mode turned on
Success: Pulled changes from 'gidev'
Success: Synchronized database
Success: Maintenance mode turned off
Success: All done
Remember, I set up the gidev label when I ran wp vp clone – and the label is embedded in the local .git/config file. The command line feedback looks positive. What does gistaging’s VersionPress screen show?
Oh my, and there it is. Let’s see if it appears on the site.
So how about some push-back? I’ll edit the new post on gistaging (I’ll let you imagine that) and then push the changes across to gidev.
$ wp vp push --to=gidev
Success: Maintenance mode turned on for 'gidev'
Success: Changes successfully pushed
Success: Remote database synchronized
Success: Maintenance mode turned off for 'gidev'
Success: All done
And lo! Over in gidev, VersionPress sees the update
Let’s check out the page.
Finally, it’s conflict time. For my next test, I will edit the same post at either end. First I add a line on the gidev side:
Whilst, more or less at the same time I add text in the gistaging interface:
Well that can’t end well. Sure enough in gidev, when I pull, things go awry:
$ wp vp pull
Success: Maintenance mode turned on
Warning:
Warning: CONFLICTS DETECTED. Your options:
Warning:
Warning: 1) Keep the conflicts. You will be able to resolve them manually.
Warning: 2) Abort the process. The site will look like you never ran the pull.
Warning:
Choose 1 or 2: 1
Success: You've chosen to keep the conflicts on the disk. MAINTENANCE MODE IS STILL ON.
Success:
Success: Do this now:
Success:
Success: 1. Resolve the conflicts manually as in a standard Git workflow
Success: 2. Stage and `git commit` the changes
Success: 3. Return here and run `wp vp pull --continue`
Success:
Success: That last step will turn the maintenance mode off.
Success: You can also abort the merge manually by running `git merge --abort`
That looks like a bad situation. In fact, it’s exactly what we want to happen. Two people have changed the same post – so the conflict must be resolved. If we weren’t using VersionPress, the only way forward would be for one instance to blindly overwrite the other.
So the next stage is to fix the conflict. If you’re familiar with git, these steps will be pretty standard. From my gidev environment (at /var/www/gidev/site) I run git status:
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 2 commits.
#
# Unmerged paths:
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: wp/wp-content/vpdb/posts/CD/CD5858A8A3AA4CF386F7488F39419F53.ini
#
no changes added to commit (use "git add" and/or "git commit -a")
This tells me where the conflict can be fixed. It also gives us some insight into the way that VersionPress works – it’s busily representing the work I do in WordPress in the wp/wp-content/vpdb/ directory. Let’s look at the file in question – or at least some of it:
post_content = "Created in gidev.^M
^M
But edited in gistaging.^M
^M
<<<<<<< HEAD
Edited again in gidev."^M
=======
Edited again in gistaging."^M
>>>>>>> ac18c249602434abd96494583dca58651e1b3e33
post_title = "Another VersionPress test"^M
post_excerpt = ""^M
post_status = "publish"^M
comment_status = "open"^M
ping_status = "open"^M
post_password = ""^M
post_name = "another-versionpress-test"^M
to_ping = ""^M
pinged = ""^M
<<<<<<< HEAD
post_modified = "2016-12-24 00:37:10"^M
post_modified_gmt = "2016-12-24 00:37:10"^M
=======
post_modified = "2016-12-24 00:38:32"^M
post_modified_gmt = "2016-12-24 00:38:32"^M
>>>>>>> ac18c249602434abd96494583dca58651e1b3e33
post_content_filtered = ""^M
Well, that’s clear enough. I need to manually merge those edits. When I’ve finished the file looks like this:
post_content = "Created in gidev.^M
^M
But edited in gistaging.^M
^M
Edited again in gidev.^M
Edited again in gistaging."^M
post_title = "Another VersionPress test"^M
post_excerpt = ""^M
post_status = "publish"^M
comment_status = "open"^M
ping_status = "open"^M
post_password = ""^M
post_name = "another-versionpress-test"^M
to_ping = ""^M
pinged = ""^M
post_modified = "2016-12-24 00:38:32"^M
post_modified_gmt = "2016-12-24 00:38:32"^M
post_content_filtered = ""^M
Having applied the edit, I tell git I’ve resolved the conflict
$ git add wp/wp-content/vpdb/posts/CD/CD5858A8A3AA4CF386F7488F39419F53.ini
And now I have to inform VersionPress that I am good to go (using the syntax specified by the VersionPress conflict message):
$ wp vp pull --continue
Success: Synchronized database
Success: Maintenance mode turned off
Success: All done
Over in gistaging (/var/www/gistaging/site) I’m ready to acquire changes from gidev:
$ wp vp pull --from=gidev
Success: Maintenance mode turned on
Success: Pulled changes from 'gidev'
Success: Synchronized database
Success: Maintenance mode turned off
Success: All done
Let’s look at my two environments. First gidev:
And then gistaging:
Reconciled!
So far, so fantastic.
There are a few things that need ironing out. I haven’t yet dug into how to integrate this with my wider git strategy. Out of the box, VersionPress’s clone strategy assumes that you are running installations on the same machine in very particular locations. There is obviously no reason why I can’t set up configuration to support my wider git strategy with a central repository, remote installations, and a git-flow style process – it will just take some additional work.
There is also a major issue with file permissions. Part of that is my problem. I still haven’t properly got to the bottom of managing co-existence between Web and CLI. But VersionPress does not currently report particularly well when it fails to write a change to its file store (wp-content/vpdb/). The change quietly fails to appear.
I’ll need to develop my strategy to deal with this (I can’t keep on running a chown/chmod script every time I want to perform a crucial web or cli task – a step I glossed over in writing this article). For its part, VersionPress also needs to be more strident about write failures. When my permissions go awry, the error log tells me something like this:
[Fri Dec 23 19:11:10 2016] [error] [client 51.6.158.8] PHP Warning: file_put_contents(/var/www/gidev/site/wp/wp-content/vpdb/posts/CD/CD5858A8A3AA4CF386F7488F39419F53.ini): failed to open stream: Permission denied in /var/www/gidev/site/wp/wp-content/plugins/versionpress/src/Storages/DirectoryStorage.php on line 89, referer: http://gidev.getinstance.com/wp/wp-admin/post.php?post=72&action=edit
But in GUI-land everything seemed fine – until the changes that failed to get written to wp/wp-content/vpdb/ are clobbered by an incoming update. The results can be perplexing without log diving and general debuggery.
These are minor quibbles, though. There is little doubt that VersionPress is an amazing step forward in professionalising the WordPress development process.
