2.0 Release Notes 🍸¶
VersionPress 2.0 brings the basics of the sync feature, new GUI stack, resolved db.php dependency and a handful of other things.
Released on 12-Oct-2015, read the announcement blog post.
Note: this is an EAP release
Early Access is a period during which VersionPress is reasonably stable but still young, limited in scope and an external backup is recommended at all times. Learn more about EAP.
New in 2.0¶
Synchronization between multiple environments a.k.a. staging, implemented as a set of WP-CLI commands. They are:
vp clone– creates a new site instance.
vp pull– pulls the changes from another clone. Creates a merge commit if the two environments had concurrent changes.
vp push– pushes the changes to another clone. (Does not do a merge.)
Also, these other WP-CLI commands have been added:
vp restore-site– when the only thing you have is a Git repository.
vp apply-changes– refreshes database to reflect the current state of a site. Useful e.g. after a conflict has been resolved.
New GUI stack built on top of technologies like React.js, WP REST API and TypeScript. See the blog post VersionPress 2.0: New User Interface.
- New GUI features, namely:
- Clickable table rows, showing details of every change. The panel will first show a quick overview of changes (for example, a list of updated properties) with the option to show a full diff which is a bit technical but displays all the details (for example, the option values).
- UI for manual commits. This is useful in scenarios where VersionPress couldn't commit the change automatically, e.g., after a FTP upload or after a manual change.
- Merge commits are visually marked in the main table.
- Notification of new commits. If new commits are detected, a refresh link is displayed.
- Times in the main table refresh automatically so they will now display correct time even if you don't refresh the page.
- Other minor UI updates like an inline warning about the need to fully activate VersionPress or the explanation why commits done pre-activation cannot be undone / rolled back to.
- Resolved db.php dependency. VersionPress no longer requires the
db.phpdrop-in to be available, enabling compatibility with various caching, monitoring and other WordPress plugins. See also blog post with the details.
- WordPress automatic background updates are no longer affected by VersionPress. In v1, if VersionPress was activated, WordPress stopped doing background updates. v2 maintains auto-updates if they were enabled before VersionPress activation.
- Fixes / updates in automatic change tracking. Specifically:
- The biggest one are translations which weren't tracked properly in v1.
- Certain bulk changes now better report what has changed.
- WordPress update is no longer a "commit everything" operation, we try to be more selective about it (as we are with other types of changes). Also, there were rare cases where WP update could have been tracked as other kind of update, e.g., an options update, which was fixed.
- Some changes via the Customizer were not tracked correctly.
- Improved menu change tracking.
Internal format update:
- Options now use a multi-file storage as other entity types, lowering a chance of merge conflicts.
- Certain special characters (backslashes, quotes) are stored differently now
The updates are not huge but mean that VersionPress 2.0 is not upgradable from 1.0 (or beta versions of 2.0) – see notes on that below.
New rollback implementation that works across merge commits.
- Plugin compatibility is reported live in the plugins list. When VersionPress is running, it will add indicators in the main plugins table and in the search/install page, utilizing the white- and black-lists available since 1.0-rc3.
- Major performance improvements during the initial activation. On some larger test sites, we saw dramatic improvements like the time necessary for the activation dropping down from 130 to 4 seconds. Large sites will always be a challenge when it comes to activation (because all needs to be indexed at once) but at least we now do the indexing as efficiently as possible, or very close to that.
- Compatibility fixes for WordPress 4.3. Relatively minor but we've found and fixed a few issues around favicons and menu updates.
General system requirements:
- PHP 5.3.4 or later
- WordPress 4.1 or later (should work on 3.9+ but it's only officially tested on 4.1+)
- Git 1.9 or later
proc_open()enabled on the server
System requirements for sync / multi-instance workflows:
- For 2.0, we recommend custom server / VPS as most hosting providers will pose further restrictions on creating site clones.
VersionPress 2.0 is not upgradable from 1.0 and beta versions of 2.0, full re-activation is required. The recommended procedure is:
- Put the site under maintenance mode
- Deactivate VersionPress 1.0 (just deactivate, do not uninstall)
- Delete the contents of
wp-content/plugins/versionpressand extract VersionPress 2.0 there
- Activate & initialize the plugin again
- Disable maintenance mode
Beta / RC notes¶
The 2.0 release is undergoing a much shorter release cycle than what we had in 1.0 but still, there will be some differences between betas which this sections documents.
Released on 5 Oct 2015. Main changes:
options.inisplit into mutli-file storage
- New rollback implementation that works across merge commits
- WP-CLI commands
rollbackare now done under the maintenance mode
- Fixed WP update action with language other than en_US
- DB synchronization is run automatically after manual commits
- Other minor fixes and UI improvements
Released on 3 Oct 2015. Just a small fix to the original beta, see below. (This version isn't tagged in Git, it was a quick manual fix.)
Released on 18 Sep 2015. The main missing features are options.ini split and general polish of the WP-CLI commands; other than that, this release closely represents the final 2.0 state.
admin/index.phpon line 22,