VersionPress – Version Control Plugin for WordPress(versionpress.net)
versionpress.net
VersionPress – Version Control Plugin for WordPress
http://versionpress.net/
13 comments
Looks interesting! I already use Git to manage version control for my WP sites, so it's probably not for me, but it could be very helpful for those who aren't tech-savvy enough to use Git directly -- i.e. 99.999% of the WP-using population.
Did you read the website? It's version control for the database as well. I don't suppose you could undo deleting a post with just git haha
I did, but I missed that bit. Which is bad! Having database versioning rolled in makes it interesting to people like me as well.
If the developers are reading this: move that info up to the top of the page! Currently it's buried down in the "Features" section, making it easy to miss. Don't hide your light under a bushel :-)
If the developers are reading this: move that info up to the top of the page! Currently it's buried down in the "Features" section, making it easy to miss. Don't hide your light under a bushel :-)
Very valid point, we have just updated the website. Thanks!
I usually add a commit hook to run 'mysqldump'. Then you get a matching database snapshot along with the source code.
TIP: For better diff's use "--skip-extended-insert --skip-dump-date".
A nice gui on top of that is welcome (although I'm not sure about the $30K).
TIP: For better diff's use "--skip-extended-insert --skip-dump-date".
A nice gui on top of that is welcome (although I'm not sure about the $30K).
Why mysqldump instead of using the binary log? Just dump the result of SHOW MASTER STATUS to a text file in your git directory, back up your binary log files on a regular basis, and then you just use the stop position feature of the binlog utility[1] to restore to that point in time from the binary logs. A lot faster than doing mysqldump and a lot less likely to lock tables or slow down your database.
[1] http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recover...
[1] http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recover...
mysqldump daily into the git repo folder?
So you're in the top 0.001% of WP devs because you use git? OK, sure.
No, he's saying most users of Wordpress are not devs. My clients sure don't use GIT, but they edit their own posts.
I'm both excited and worried about it shipping as a standard WordPress plugin. What failsafes are there to guarantee that this very plugin shan't itself break after a particular update?
Eventually you have to trust something. I think it's reasonable to keep backups and trust that VersionPress itself won't break. Furthermore, given the backup includes the database and the code, seems like you could test VersionPress upgrades fairly easily from the backup in a separate environment.
The biggest potential hangup I could see is something like a hacked-up theme or plugin that breaks in a way that makes the WP backend inaccessible (the infamous "white screen of death": http://codex.wordpress.org/Common_WordPress_Errors). In this case VersionPress wouldn't be able to save your bacon, because you wouldn't be able to get to its UI to back the change out.
But on the other hand, you'd have to do the exact same thing if you didn't have something like VersionPress installed, and VersionPress might save you from a host of lesser problems that would otherwise be annoying to deal with.
But on the other hand, you'd have to do the exact same thing if you didn't have something like VersionPress installed, and VersionPress might save you from a host of lesser problems that would otherwise be annoying to deal with.
We'll certainly have a way to restore the site even if it is so broken that you can't access the backend. Think something like external command line utility or, for hosting scenarios, a PHP script.
Would it be possible to add a git remote so it would push to my Stash server or Github?
Totally possible, we'll probably add that in some future release.
We use git based roll back and deployments at work. It works fantastic, but this looks like a very nice interface on top. the database versioning would be extremely useful. Definitely highlight that at the top of the page as someone else already mentioned in this thread.
Have you considered adding support for wp-cli commands with this. That would make automating some of the tasks very nice.
Have you considered adding support for wp-cli commands with this. That would make automating some of the tasks very nice.
Done that, thanks all for the feedback! wp-cli is something we'll definitely consider.
Great idea, supported it! More open source apps should do the same money collection techniques!
We outsourced our WordPress blogs to Pagely, and good riddance - but if they were still my problem, I'd be all over this.
(I still run my personal sites myself from sheer control addiction. But for almost everyone, outsourcing is the right answer, even just to a free wordpress.com site.)
(I still run my personal sites myself from sheer control addiction. But for almost everyone, outsourcing is the right answer, even just to a free wordpress.com site.)
This has been one of the biggest problems with using WordPress in a professional/team context.
Will you be able to branch everything so multiple people can build on it?
Will you be able to branch everything so multiple people can build on it?
Yes, the team scenario is something that we know we want to support and it will totally be possible.
This plugin seems to solve a problem and target a market that doesn't exist. It is also dangerous since it relies on WordPress itself being reachable in the event of catastrophe.
WordPress users that aren't developers don't use VMs or update their site's code frequently. Typically they either use simple hosts like Dreamhost/Media Temple or managed hosts like Pressable/WP Engine that already integrate forms of easy backup. If they don't there are a [plethora of backup plugins](http://premium.wpmudev.org/blog/free-wordpress-backup-plugin...) and [services](http://vaultpress.com/) that not only cover code but also the DB. And since these novice users rarely change their site's code, they have no reason to use version control in the first place.
At the other end of the spectrum, WordPress developers don't need this either. Git is pre-installed on most VMs and integrated into almost all the major cloud providers and staging sites take 10 minutes to set up. And most importantly they are abstracted from WordPress itself making them way more secure. For example, what if the admin becomes unreachable after a hack? Doesn't this defeat the entire purpose of Versionpress since you won't be able to access the plugin page to revert back? Combining backup and version control together in the WordPress admin is a recipe for disaster.
Lastly, whats the point of raising $30K since this is a premium plugin that's almost done anyway? If the picture isn't a rendering, then it seems like the plugin is already well under development. Isn't this more like a presale?
WordPress users that aren't developers don't use VMs or update their site's code frequently. Typically they either use simple hosts like Dreamhost/Media Temple or managed hosts like Pressable/WP Engine that already integrate forms of easy backup. If they don't there are a [plethora of backup plugins](http://premium.wpmudev.org/blog/free-wordpress-backup-plugin...) and [services](http://vaultpress.com/) that not only cover code but also the DB. And since these novice users rarely change their site's code, they have no reason to use version control in the first place.
At the other end of the spectrum, WordPress developers don't need this either. Git is pre-installed on most VMs and integrated into almost all the major cloud providers and staging sites take 10 minutes to set up. And most importantly they are abstracted from WordPress itself making them way more secure. For example, what if the admin becomes unreachable after a hack? Doesn't this defeat the entire purpose of Versionpress since you won't be able to access the plugin page to revert back? Combining backup and version control together in the WordPress admin is a recipe for disaster.
Lastly, whats the point of raising $30K since this is a premium plugin that's almost done anyway? If the picture isn't a rendering, then it seems like the plugin is already well under development. Isn't this more like a presale?
I am also skeptical of this plugin but I think almost all of your points are moot.
There is big market for a solution that lets users backup and restore the filesystem and a database on a more granular level. Not being able to easily and conveniently revert changes that are made easily is one of the biggest pain points in managing a WordPress site. If you update WordPress and find that a critical plugin doesn't work, there is no convenient way to undo the update. Of course, ideally, these kinds of things are tested on a staging server first, but the truth is only a minority of sites utilize a staging server in this manner.
A lot of pain around websites is dealing with changes to the filesytem and database. To have a simple way of tracking changes and reverting changes is a boon. Both normal end-users and developers will jump for joy with a unified tool for this.
You can't compare this with many of the existing backup solutions either. You get far more detail (which helps with debugging) and far more incremental control when you have something git-like managing it all.
I'm pretty sure the solution would not be dependent on being accessible from a site's WP backend. But then, I don't know the specifics yet.
I don't see the problem raising money through crowdfunding for this either, from their point of view. It's a sound business strategy that validates a market and provides some investment.
My hesitation is this, we have no idea if they even have the skills to pull something like this off. Because it's not going to be easy. The WP environment can really vary from one site to the next (different server setups/different plugins/themes etc) and you have to make it work on them all. That's just a huge undertaking. I think you'd need a pretty big team with a ton of experience and a lot more than 30k to get close to pulling it off.
There is big market for a solution that lets users backup and restore the filesystem and a database on a more granular level. Not being able to easily and conveniently revert changes that are made easily is one of the biggest pain points in managing a WordPress site. If you update WordPress and find that a critical plugin doesn't work, there is no convenient way to undo the update. Of course, ideally, these kinds of things are tested on a staging server first, but the truth is only a minority of sites utilize a staging server in this manner.
A lot of pain around websites is dealing with changes to the filesytem and database. To have a simple way of tracking changes and reverting changes is a boon. Both normal end-users and developers will jump for joy with a unified tool for this.
You can't compare this with many of the existing backup solutions either. You get far more detail (which helps with debugging) and far more incremental control when you have something git-like managing it all.
I'm pretty sure the solution would not be dependent on being accessible from a site's WP backend. But then, I don't know the specifics yet.
I don't see the problem raising money through crowdfunding for this either, from their point of view. It's a sound business strategy that validates a market and provides some investment.
My hesitation is this, we have no idea if they even have the skills to pull something like this off. Because it's not going to be easy. The WP environment can really vary from one site to the next (different server setups/different plugins/themes etc) and you have to make it work on them all. That's just a huge undertaking. I think you'd need a pretty big team with a ton of experience and a lot more than 30k to get close to pulling it off.
Thanks, that answers many points very well. VersionPress seems to interest many people so hopefully we'll get chance to properly build it.
You also seem to be very realistic about how large this undertaking is - you're right and we know how big of a thing we're trying to build. That's why we're realistic about our goals for v1 and don't promise more than we can deliver. To support all the complex 3rd party plugins and various hosting environments is something that will come over time. But we have to start somewhere and we believe that we are approaching the problem from the right angle. Thanks!
You also seem to be very realistic about how large this undertaking is - you're right and we know how big of a thing we're trying to build. That's why we're realistic about our goals for v1 and don't promise more than we can deliver. To support all the complex 3rd party plugins and various hosting environments is something that will come over time. But we have to start somewhere and we believe that we are approaching the problem from the right angle. Thanks!
So much hating.
If they don't meet the goal, then maybe you're right that there's no market for it. If they do, then you're likely wrong. Why not just wait and see rather than declare it a failure?
It's not "dangerous" in a catastrophe because it doesn't take away any options that already exist.
And presumably they're raising money because it costs them money to live and work on a project.
If they don't meet the goal, then maybe you're right that there's no market for it. If they do, then you're likely wrong. Why not just wait and see rather than declare it a failure?
It's not "dangerous" in a catastrophe because it doesn't take away any options that already exist.
And presumably they're raising money because it costs them money to live and work on a project.
My thoughts exactly. I feel the same way about the numerous GUI clients that are supposed to save you ever using git on the command line. Non-developers don't understand/want git, and developers, even ones that don't use the command line often, will find that the basics git commands are really simple.
Awesome idea. In case you don't meet funding goals, please consider open sourcing the code anyway, I have no doubt a collective effort will finish polishing that plugin.
I don't care how you slice it, versioning a DB in git is a broken process. If you have to do this to shore up a project, it indicates the project is broken.
This is sold as something for big sites: "70% of WP sites in Alexa Top 1 Million" but I promise you there is no conceivable way the amount of changes we make in our WP DB could not be handled in Git.
This is sold as something for big sites: "70% of WP sites in Alexa Top 1 Million" but I promise you there is no conceivable way the amount of changes we make in our WP DB could not be handled in Git.
There are certainly big technical challenges to solve, that's why we're running the crowd-funding campaign and that's why we repeat the phrase "realistic funding" quite often. However, although I'm not saying that VersionPress will work in every thinkable scenario and for every WP site out there, we will be able to cover a lot of sites and a lot of needs WP admins have today.
Thanks for your comment!
Thanks for your comment!
I'd be interested to hear how you plan to solve that problem exactly. There are several[1] existing[2] solutions[3] attempting to solve the problem of versioning binary files in git, but even then, the history of your code and the history of your data are kind of two separate timelines. I should be able to revert, say, a plugin installation or a configuration change without having to revert any posts or comments that came in during that time. And vice versa.
The only time you'd want to tie your data with your code is when the schema of your data changes. Existing frameworks like Rails use code-based migrations for this purpose, so you know at any point in your git history what the database schema should look like (if not how to migrate/revert your data to match that schema).
[1] https://github.com/apenwarr/bup [2] http://git-annex.branchable.com/ [3] http://caca.zoy.org/wiki/git-bigfiles
The only time you'd want to tie your data with your code is when the schema of your data changes. Existing frameworks like Rails use code-based migrations for this purpose, so you know at any point in your git history what the database schema should look like (if not how to migrate/revert your data to match that schema).
[1] https://github.com/apenwarr/bup [2] http://git-annex.branchable.com/ [3] http://caca.zoy.org/wiki/git-bigfiles
Hi Smudge, please see the answer above. Thanks.
Could you describe how you actually intend to version the database in any sort of technical language? There are existing methods of doing RDMBS versioning and I don't know of any that have tried using git.
If you want to do something that makes no sense, asking for money to do it doesn't make it more realistic.
If you want to do something that makes no sense, asking for money to do it doesn't make it more realistic.
VersionPress is a combination of hooks, own text format and custom PHP code that manages Git and makes it all work together. VersionPress extracts information from the database, stores is in a format that is suitable for diffing and merging and versions that in a Git repository. So we do not version control db files themselves but rather the information inside the database. Sorry if you find the term "database versioning" technically incorrect, we just had to call it something simple that would still be relatively close to the technical truth.
I'll prepare a blog post on how VersionPress attacks the versioning problem technically.
I'll prepare a blog post on how VersionPress attacks the versioning problem technically.
A conceptually simple way to version a relational database and keep the versions in Git (or any other VCS) is to reduce each version to a set of SQL scripts that build the database from scratch to its current state, and then commit those scripts to the Git (or other VCS) repository.
To make it tractable to do so with small, frequent, incremental changes to a DB, you'd need to be smart about tracking which scripts need to change rather than running a process to reduce the whole DB to scripts each commit.
To make it tractable to do so with small, frequent, incremental changes to a DB, you'd need to be smart about tracking which scripts need to change rather than running a process to reduce the whole DB to scripts each commit.
I need a CMS that versions media (images/video). Most just version text posts. It looks like this is one of the better options as I haven't found anything good elsewhere.
We will totally version images/albums because we version everything. Glad VersionPress will be useful to you!
The huge problem I see with this is going to be when people try to do this on shared hosting, which is the largest portion of WP sites, especially the sites not updating regularly.
Good luck explaining git setup, ssh keys, etc. to end users who aren't devs or sysadmins.
Good luck explaining git setup, ssh keys, etc. to end users who aren't devs or sysadmins.
Though we don't promise this for v1, VersionPress on a common LAMP hosting is certainly something we will do in the future and have prototypes of how it could be done. Of course, the end user will be completely abstracted from things you mentioned, it is our mission to provide version control in a way that everyone can use (i.e., if you don't know Git, fine, you don't have to).
Have you surveyed how many WordPress installations are on shared hosting?
I think that much of the success of WordPress is attributable to the fact it can be installed via Fantastico with the click of a button, I wouldn't be surprised if more than 90% of WordPress(.org) installations in the wild are on shared hosting.
The problem is that Git is not installable on shared hosting afaik, so it strikes me as a very weird match for Wordpress.
Hi muxxa, rest assured that we know about this and common LAMP hosting support will certainly come. It's just that to implement the support is relatively time consuming and we don't want to promise for v1 something that we know we will be able to deliver. But don't worry, it is our goal to run everywhere where plain WordPress can so common hosting support is coming.
If you want to use version control for your theme development, there's already Roots: http://roots.io/