VersionPress 1.0 Released(blog.versionpress.net) |
VersionPress 1.0 Released(blog.versionpress.net) |
This send shivers down my spine.
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...
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.
https://wordpress.org/plugins/revisr/
will take a look at this to see how it compares
http://blog.versionpress.net/2015/01/versionpress-vs-revisr/
https://wordpress.org/plugins/revisr/faq/
How does Revisr handle the database?
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.