We wanted to do this for a long time and finally managed to. VersionPress is now free & OSS on GitHub.
It is my great pleasure to announce that VersionPress goes fully Open Source today. While the software itself has been GPL’d since the first releases, we’ve been developing it privately and Early Access was a paid-for program. All of that goes away today. VersionPress’ new home is now on GitHub are we’re not just making it freely available there, VersionPress will truly be developed out in the open and run as an open source project, hopefully with the help of a broader WordPress community over time. We encourage you to star / watch the repo and join us in the mission to turn WordPress into a fully versioned platform.
Oh, and “by the way”, we’re also releasing VersionPress 3.0-beta today.
This is a big moment in the project’s history so let me share a bit of a background story.
The early days
VersionPress started as an internal research project between me and Jan a couple of years back. We were solving our own workflow issue where we couldn’t easily synchronize WordPress sites between environments because database merging was virtually impossible. We decided to use Git (not SVN) as an internal engine of what we started calling VersionPress, and the results were pretty amazing. This tool
A sister project to VersionPress is coming in July. It is a fully hosted platform with great staging, speed and developer UX.
I’m happy to announce that VersionPress is getting a sister project: VersionPress.com. It is a hosted WordPress platform (a managed WordPress host if you will) that takes the best ideas from VersionPress and packages them in an easy to use interface and adds things like backups, security and world-class infrastructure. It has full compatibility with WordPress plugins and doesn’t require Git so it’s a perfect place to host almost any WordPress site. The platform will fully launch in July 2017 with pre-orders available today. Go check it out at https://preview.versionpress.com/.
We started working on VersionPress in 2014 to bring full version-control to WordPress. The benefits if this is achieved are immense: undo button for everything, the possibility to merge databases between environments (staging <-> live, developers between themselves, etc.), keeping track of who did what and many others. It feels almost magical.
We also learned that there will be two major challenges:
WordPress plugins. They can do almost anything to the database and boy they do. Even those well-written must be explicitly supported and while we’re building an infrastructure
Calypso is probably more important than just a new UI. Written down some thoughts on it.
Calypso is the big news of the week and here are some random thoughts on it. 1. This is awesome
First and foremost, I am personally extremely excited about this. Not only because the new UI is really nice and pleasant to use but also because this finally shows the modern side of WordPress, or at least starts to. With VersionPress, if you abstract from all the technicalities and specific features, what we are trying to do is to modernize WordPress workflows, and I am always very pleased when I see a project in the same camp, be it this new UI, WP-CLI for a great scripted experience, roots.io always pushing for best practices, testing tools like WP_Mock and many other projects and initiatives. WordPress needs this and it’s great to see such a huge contribution from Automattic.
Technically, I am also very happy that Automatticians chose React. There are a myriad of options available today but I personally believe that React is the best bet in the long term (well, you could probably guess that as we use React for our UI too ).
2. But there’s more to it
After the initial reaction, about a hundred of different thoughts went through my head. What does this really mean? How will this change
Probably the most significant release of VersionPress since 1.0, introducing support for plugins (any plugin can hook into the version control process), Composer workflows etc.
We’re happy to announce that after months of development, VersionPress 4.0-alpha1 is ready and available on GitHub. It brings plugin support which means that even complex sites like WooCommerce shops, large magazines etc. will be able to enjoy version control benefits soon. There are also some other nice features like an awesome Slack-like search, branching & merging visualization, support for Composer workflows and more. VersionPress 4.0 will undergo a full alpha / beta period to gather feedback on the plugin support and this really is the first alpha. Not all planned features are in it but it’s a good start.
To get a good idea what v4 is about, let’s look back at the previous releases:
1.0 was about a basic Git version control. The internals were already prepared to handle database merging but there was no real way to tap into it.
2.0 exposed the DB merging functionality to the users via a set of WP-CLI commands.
3.0 was a large maintenance release, handling things like serialized data, shortcodes and other things much better.
In all these releases, if a plugin added a custom database table or even stored custom data in tables like wp_options or
I just thought we'd be stuck at 90% done forever. So glad VersionPress 3.0 is finally finished!
In January, we were pretty confident VersionPress 3.0 would be released by the end of that month. In February, we were pretty confident… you get the idea. It’s the end of April and I’m really happy to announce that VersionPress 3.0 is finally ready! It’s a major technical release and we’ve done some crazy stuff to support every possible quirk and nuance of WordPress (until we find some new ones, of course!). How often do you write your own Git merge driver? Also, VersionPress 3.0 is the first version available as a fully open-sourced release on GitHub. We’ve transitioned to this new model earlier this month and are very happy with it. For instance, we could get rid of PayPal
The concept was interesting when it was just something I'd heard of, but now that I've seen the walkthrough here, wow! This is powerful. I want this. Badly.
In this blog post I’m going to show how VersionPress 1.0 works and how it can help you manage your WordPress sites. It is a lot of screenshots so let’s get rolling. Installing VersionPress
VersionPress ships as a standard plugin so the installation is just a matter of uploading a ZIP file and clicking a few buttons as usual. Once VersionPress is activated, it shows a prompt to start tracking the site:
This takes you to the pre-activation screen:
It seems a bit unwieldy at first but we prefer to do automated checks rather than activate blindly on a site that might cause issues later. If all checks passed VersionPress can be fully activated:
This creates the initial state (version) of a site and all is set.
An important, albeit somewhat invisible feature of VersionPress is the automatic change tracking. Let’s demonstrate it by doing some actions on a site. This is what I did:
Trashed the “Hello World” post
Installed a new theme
Customized it to my liking
Created a new post “Hello VersionPress”
Updated the blog name (“Test Site” -> “Demo”)
The VersionPress admin page now looks like this:
The user interface is currently quite basic (big improvements are coming in the 2.0 release)
Interesting plugin that brings Git version control to the WordPress database
It’s here! We’re glad to announce the availability of VersionPress 1.0, the first stable release of what we hope to become an amazingly useful tool for WordPress admins around the world. What is VersionPress
If you’re new to this project, VersionPress basically brings the power of Git version control system to WordPress. It versions both files and the database, enabling things like site-wide reverts, easy staging, team workflows, efficient backups and more. Importantly, VersionPress is not just for developers – we strive for simplicity so most actions are tracked automatically and for non-technical users, VersionPress is simply a table with undo-able history:
Yet, with all the power of Git behind its back, it is easy to integrate with custom development tools and workflows, commit changes manually, push to hosting sites like GitHub or BitBucket, etc. We manage a couple of our sites this way and it’s really a huge step forward.
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’s better to think about VersionPress as a long-term project and of v1 just as a
GitHub workflows, having staging and production environments on different machines etc.
Currently, the commands for cloning and merging only work locally, meaning that you cannot, out of the box, create a staging environment on a different server. That is often desirable so I’m going to show how you can achieve that today with a little bit of scripting. By the way, if you want staging for your WP site to be really easy and don’t want to mess with CLI scripts, we’re close to releasing a beta of something interesting in this space. Email me at email@example.com to join the Insider program.
Understanding the (non-)magic
Even though seeing two databases merge seamlessly feels like magic, the process is quite straightforward:
Git repositories are pushed / pulled between the two site clones, e.g., production and staging.
wp vp apply-changes is called to update the database on the target environment.
That’s it. Whenever you’re going to script remote workflows, keep these two core steps in mind.
Now let’s move on to some real-world examples.
Example 1: Team work via GitHub
You are a developer and have a colleague, Jane, who helps with design and copywriting. You both want to work on the site in parallel and manage the team work via a private
VersionPress v4 is closer with this beta that brings user-editable plugin definitions and a lot of stability improvements.
We’re happy to announce the availability of VersionPress 4.0-beta. It brings significant stability improvements over the alpha and a couple of new features. You can download 4.0-beta from GitHub and read the full release notes there.
User-editable plugin definitions
The prime feature of v4 as a whole is extensible plugin support: when a plugin is described by a couple of files called plugin definitions, VersionPress starts providing change tracking, undo or database merging automatically. The genesis of this since v1 is described in the alpha blog post.
4.0-alpha1 brought support for plugin definitions that ship with plugins. For example, if WooCommerce shipped with a .versionpress folder in it (fake news, fake screenshots), VersionPress would pick it up:
4.0-beta expands the support to a user-editable location in wp-content. If you create a folder WP_CONTENT_DIR/.versionpress/plugins/woocommerce and put definition files like schema.yml or actions.yml there (full specification here), VersionPress will use and actually prefer it over the bundled definitions (if they exist):
Post-beta, we will be creating an online repository for plugin definitions, see #1243. Right now, we’re
Includes React-based dev stack and a couple of new UI features
Share this:TwitterFacebookGoogleRedditLike this:…
Info on a new database merging service & how it compares to VersionPress
The hardest thing about VersionPress is database merging; everything else is relatively simple. Very few dare to take on this problem so I was excited when Delicious Brains announced their newest project, Mergebot, yesterday. I’d like to share some early thoughts on it. BTW, it has not really been that much of a surprise to anyone who follows this space closely. Brad talked about the then called “Data Hawk” / datahawk.io in this episode of Apply Filters and I’ve personally chatted with the devs at various WordCamps in person. Don’t expect any secrets though; I didn’t invest enough beers into learning the dark magic they use and know not much more than is publicly available.
First of all, I have to say that Mergebot is the only solution I know of (other than VersionPress) that really tries to tackle the problem properly. For example, people often mention Revisr but its goals were always much simpler. Here’s a table from last year that’s still valid:
Mergebot, on the other hand, checks the “database merge” column which is exciting. So, how does it compare to VersionPress?
(Just to repeat, I don’t have any hands-on experience
New version of VersionPress released, includes staging / DB sync & new UI.
One of the hardest things in WordPress is to handle multiple instances of a site. For example, you would ideally want to have a dev version of a site, then probably some sort of staging and then the live site. It is easy to create all these environments but really hard to merge between them. Why? Because of the database. Some tools help with that to some degree but it is generally an unpleasant task, until VersionPress 2.0.
Database synchronization is a culmination of our work so far. I’ve written a detailed blog post on it which I encourage you to read but the TL;DR is:
VersionPress can clone sites & merge them back together effortlessly. Not just their files but also their databases.
The merge is the killer feature here, as it just works most of the time. VersionPress
How was 2017 for VersionPress and what are the plans for the next year
It’s the end of another year, let’s look back at 2017 and talk about our plans for 2018. The two most significant things from us in 2017 were:
Release of VersionPress 4.0 beta with support for WordPress plugins and themes.
Introduction of VersionPress.com, a hosted platform that includes content merging (“staging that works”) and other productivity features.
4.0 is a significant update of VersionPress’ internals to support plugin and themes in a flexible way. WordPress core itself is treated as a “plugin” and you can view its definitions on GitHub: schema.yml, actions.yml, shortcodes.yml and hooks.php. It’s quite amazing that the entirety of WordPress can be described in a relatively few lines of code, and typical plugins are of course much smaller. Here is an example of WooCommerce definitions.
4.0 is currently in beta and the two key things remaining are:
Implement some remaining issues and wrap up the final release
Create an online repository for plugin definitions (#1243)
But even with that, we recommend you use 4.0-beta over 3.0 stable as it passes the same set of tests and is generally better prepared for the future.
The issue with db.php drop-in and how we dealt with it in VersionPress 2.0
In VersionPress 2.0, apart from sync / staging and revamped UI, we also took a look at a long-standing issue we have with the db.php drop-in. This blog post will be a bit technical but the TL;DR is that we will now be able to run side-by-side with some popular plugins like W3 Total Cache or Query Monitor and generally work on sites that need to use the database drop-in for some reason. The problem
VersionPress needs to observe database operations quite closely because whatever goes there, also needs to be potentially stored in the Git repository. Some other plugins like VaultPress depend solely on WP hooks & filters but that was not good enough for us for two main reasons:
Hooks don’t cover everything. While they might cover a lot, maybe something like 95%, we need to track the site as a whole, i.e., 100%.
Third-party plugins are a problem here because they usually don’t provide hooks, or not many of them.
So we need to be quite close to the database and observe the traffic that goes into it. Unfortunately, while WordPress provides many extensibility points at a higher level, there are very few of them at the low, database level. In fact, there are only two, both added way back in 2007
This year's SOTW has been quite surprising, WordPress is about to change quite a bit during 2017
Yesterday, Matt Mullenweg delivered his annual State of the Word speech at WordCamp US in Philadelphia. At about 54 minutes in, he started a section that I found quite fascinating and means that WordPress 4.7 (to be released on Tuesday) might be the last release as we know it. If this sounds too strong, let me explain why I believe we’ve just witnessed a true milestone in WordPress’ history. “What got us here, won’t get us there”
You generally don’t make big changes when things go well. It’s easy to get the perception that things have been going very well for WordPress recently. 4.7 is a great release, the market share is growing, community maturing and businesses thriving. Overall, everything seems to be going in the right direction and that’s what the first 50 minutes of SOTW were about.
But then you can go deeper. I have recently had a chance to watch a friend trying to build a site on WordPress without any previous exposure, and it was painful. Even I don’t build WP sites that often and when I do, I am amazed how “2000” some things still feel, from basic UX to plugin / theme quality to development workflows. In a
A brief summary of the FeelingRestful ("A Day of REST") conference in London
Pardon the stupid pun but I’m just traveling from the amazing #feelingrestfull conference and am really feeling that way (apart from being tired – don’t ask me why they’d call it “A Day of REST” ). Let me share a couple of thoughts. 1. The API thing is going to be huge
With some examples like fetching data from WordPress and using Ghost themes (!) to render the site one just cannot stop thinking what’s going to happen in the next couple of years. Big players like The New York Times and Wired are already using “APIzed” WordPress installations as part of their platforms but the idea of small API endpoints everywhere personally excites me.
2. What core cannot fix, projects around it can
The REST API is going to be merged into the core soon but it started as an external project and I still feels to me that way (the team working on it, the infrastructure on GitHub etc.). WP-CLI is another external project, VersionPress another one etc. They all bring something different to the table but the problems they encounter, internally, are surprisingly similar or related.
For example, Daniel Bachhuber talked about how WP-CLI will auto-expose REST API endpoints as WP-CLI commands which is great. But
Quick recap of what happened with VersionPress during 2015 and what's planned for 2016
…, you’ve been a good year to us. Let me briefly look back and also sketch out our plans for 2016. 2015 in review
2015 has been an all-important year for VersionPress. I know we’re still in the Early Access mode which many of you would like to see changed but a lot of good things happened throughout the year nevertheless:
In January, we launched the Early Access Program. Even though it was a kind of a paid beta, it was confirming again and again that you guys are excited about the vision and want to support it even if the production version it not ready yet.
In April, VersionPress 1.0 was released, allowing you to have a site automatically versioned in Git, including database changes. From the user perspective, it was a simple “undo button for WordPress” which allows you to be much more confident in actions such as updating plugins or deleting things.
In summer, we closed a seed round of funding from Credo Ventures and 4 other investors in Prague. I know this sounds more like an internal thing but was really significant for the future of the project.
In October, we released VersionPress 2.0 with sync / staging features. You have to see it to believe that VersionPress can merge two databases
If you're a plugin developer and want to integrate with VersionPress one day, here's a draft of the plugin support in the upcoming VersionPress 4.0
VersionPress 4.0 introduces one significant feature: support for plugins and themes. It’s a complex task and a pull request so large that GitHub barely handles it but we’re close to merging it. Before we do so and release the first alpha for 4.0, we’re looking for feedback on docs/Plugin-Support.md document. It’s not a short read but hopefully an interesting one.
Specifically, we’d like your feedback on:
Is it generally clear how plugin support works and what should be done to create a definition for a new plugin?
Does the document read well? Would you suggest any changes to its structure?
Is the terminology clear and consistent? There are terms like “actions”, “entities”, “scopes” etc., do they make sense?
Please read the document and then leave a comment inside the pull request #1075, here in the comments, on Gitter or via this Google Forms survey.
Many thanks, your feedback helps a lot!
Cloning & merging, database synchronization and easy staging are coming in VP 2.0
As we’re getting closer to a release of VersionPress 2.0, I’m going to blog about a couple of features that are coming as part of that release. Probably the biggest one is database synchronization which enables things like painless staging, team workflows, etc. This area is one of the biggest challenges when it comes to managing WordPress sites and I think we have a pretty interesting solution in v2. A brief introduction
Although the sync / staging functionality is only coming out now, it was actually this very thing that got us started on VersionPress a couple of years back. My personal experience with WordPress has always been that it is a great CMS as long as you can afford to stay in a single instance scenario, but I didn’t quite know how to quickly clone the site to a safe environment, test the changes there and merge them back to the live site again. I stress the last part because that is the really tricky one.
Cloning is relatively easy as you can just copy all the files and the database, tweak some settings like the site’s URL and that’s basically it. The copy & paste approach works well here. Where it doesn’t work well, if at all, is the opposite direction. When you have some
Summary of the lessons learned from a failed Kickstarter campaign.
Last June, VersionPress went through a crowd-funding campaign and it was a very interesting experience. I’ve long wanted to blog about it because I believe that crowd-funding is a great option for WordPress plugin developers and software projects in general. There have been some external analyses of our campaign, most notably this one on WP Tavern, but there’s nothing quite like going through it all yourself. I’d like to share my personal experience and add some data from the campaign to the mix. Basic facts
Our campaign ran from 10th to 30th June 2014
The goal was $30,000
We raised about $13,500
Looking at these numbers alone it seems that the campaign was not successful but it’s hard to see it that way after spending the last few months working hard on VersionPress What I’ve learnt is that it’s tricky to judge the campaign only by looking at the numbers. For example, there has been a campaign for Pods Framework 2.0 back in 2011, receiving almost 300% of the funding asked, but in this “Crowd-funding Roudtable” podcast episode you can hear how things were much more complicated for the framework author. (By the way, that episode is one of the best resources on crowd-funding in the world
We're looking for a couple of knowledgeable folks to help us shape VersionPress through an Insider program
As mentioned in the last post we’re working on a couple of things around VersionPress and would like to know your feedback through the “insider program”. It won’t take up a lot of your time – probably a couple of minutes a month via occasional surveys, one-on-one chats etc. – but would be very useful to us and we’ll offer sneak peeks and discounts in return. These new projects would be targeted more at WordPress professionals among you so ideally, you would be a freelancer / agency owner, managing client sites, generally knowledgeable about WordPress, etc. Git knowledge, on the other hand, is not required at all
If this sounds like you please become an insider by filling out this form (web link if the embed below doesn’t work for you):