> There is one important thing to understand about VersionPress: though it is technically a WordPress plugin, it is one of the most complex ones you can imagine.
"It is one of the most complex ones you can imagine. It may even be self-aware. We're honestly not sure. Things keep disappearing from the office in the middle of the night, replaced with laser-printed notes reading THE REVOLUTION IS COMING."
True! VersionPress looks promising and I hope it works well.
But it's sort of scary how many things are accomplished through workarounds/hacks in WordPress. Like deploying a site, where you need third-party scripts (or write your own) to change strings in the database without breaking WordPress' serialisation mechanisms...
To be fair many PHP + MySQL CMSses suffer from similar issues. At least WordPress was hackable enough for us to ship as a mere plugin which I think will be important down the road for user adoption.
Agreed. When we need to move things around we dump, find/replace and then re-serialize via https://github.com/rysi3k/Fix-Serialization. It's crazy there isn't a better way and the way WordPress handles URLs could be better.
Looking over this and revisr and gitium, and being already familiar with Drupal's "Features" and new CMI, I feel there is a general pattern here.
The pattern is that we build a tool that allows non-programmers to build more and more complex things, until they are actually programming, and then we find ourselves in a mess because we have "code" with all the complexity of such without the tools and practices to manage it.
I think I saw this decades ago as the community of Unix users I was with developed more and more complex dotfiles, and traded them around, they were modified more and more by non-programmers, until the day someone put them in CVS and shared them.
This definitely happened in the Visual Basic story arc.
I suspect this also happened in COBOL, which started out as a way to let non-programmers program, then became a programming language that non-programmers could at least read and understand, and then became a black art.
I believe this happened with PHP, as it started with a way for non-programming "html coders" to reference the same $footer across all pages, and as that group of programmers moved through their careers and became real programmers, the tools and PHP itself evolved with them.
I think this is happening with Javascript now, as a class of "front end developers" who mostly started out as non-programmer, non-technical graphic designers discovered the power of being able to tell computers what to do, and now are doing things like node.js.
In the CMS world, I think WordPress is a bit behind on this arc compared to Drupal. That's not a criticism, it's just an observation of where a much larger community with a different balance of site builder vs user vs developer is -- WordPress is much further along on arc of widespread adoption, though.
been using revisr, a free plugin that not only does the same thing and more but it has been out for almost a year now with regular upgrades and feature adds:
Really? Last time I checked it was manual commits only. Still, the way they track database is very different from how VersionPress does it. But as I said, I'm glad Revisr exists, it is a great tool for certain scenarios.
You have complete control, and can decide whether you want to track the entire database, just certain tables, or if you don't want to track the database at all. Then, during a backup, the tracked database tables are exported via "mysqldump". When importing or restoring the database to an earlier commit, Revisr first takes a backup of the existing database, creating a restore point from immediately before the import that can be reverted to if needed.
You can also set a "Development URL" that will be automatically replaced in the database during import- allowing for backups and restores that work on both your dev and live environments.
VersionPress' automatic change tracking means that new commit is created after every logical change to the site, e.g., after you update a post, update a plugin or just about anything. Revisr, if nothing changed recently, only creates commits when you manually say so. That's a difference.
The staging aspect of this is what I'm really looking forward to. Once this works I'm hooked. I'd also gladly pay for a plugin this complex and all the benefits it provides.
Honestly, this is what WordPress revisions should have been. In the age of git, there's no point in re-creating a versioning system that only covers elements of your system and not the entire thing. Just hook into git if it's available or even make a PHP implementation of git and use it.
There's been some discussion whether this should be in the core or not. I understand why they chose their current "simplistic" implementation, it has a lot of benefits but we try to go far, far beyond that.
This send shivers down my spine.