3.0 Release Notes 🍸¶

VersionPress 3.0 is a major usability and reliability release. It is also the first release available on GitHub as an open source project.

Released on 28 April 2016. Release blog post.

New in 3.0¶

Usability improvements¶

• Searching (filtering) site's history (#586). You can search commits by authors, dates, commit messages, WordPress actions, etc. It's quite powerful, see the documentation.
• Undo multiple commits at once (#201). Say that you trashed a post and then deleted it. To fully undo these two actions, you can now select both of them using checkboxes and restore the post in one go.
• Environment tracking (#609, #459). VersionPress 3.0 tracks where a change originated, for example, in staging, production or Bob's PC. Environment names are customizable and displayed using a visual hint in the UI.
• Other UI improvements. For example, the main table now displays an avatar of users who made the changes (#853) and there have been some improvements to the full diff view.
• Customizer changes produce nicer messages (#432). The generic "Customized theme XYZ" message is now replaced by more descriptive messages like "Updated title ...", "Updated menu ...", etc.
• Service panel updates (#732). It now links to the System Info page and the GitHub support repo.

Core versioning improvements¶

Most of the development time was spent improving the core versioning engine. As a result, VersionPress 3.0 supports various scenarios better than the previous releases.

• Serialized data are diff- and merge-friendly (#619, #829). This automatically improves things like IDs in widgets (#814) or sticky posts (#819).
• Custom merge driver was implemented to handle some tricky scenarios. The two specific improvements are:
  • Date modified field are now handled correctly (#588). Before VersionPress 3.0, post_modified and post_modified_gmt fields were ignored because tracking them created a lot of merge conflicts and we thought we could compute the values from Git history anyway. Unfortunately, that was not true for posts created before VersionPress was installed. VersionPress 3.0 tracks date modified's in a repo and avoids merge conflicts at the same time.
  • Changes on adjacent lines no longer create conflicts (#719). For example, if Alice updated post_title and Bob updated post_content, merging their work no longer creates a conflict.
• Shortcodes with IDs work across environments (#654). Shortcodes like [gallery ids="2,3,4"] will now update these ID correctly across environments. New *-shortcodes.yml file format was developed to support that.
• Frequent DB writes no longer create excessive number of commits (#512). Things like view counters, Akismet spam count etc. are now committed once in an hour (configurable) or before actions like cloning or merging. This avoids floods of not very useful commits.
• Configurable entity ignoring and, specifically, better spam comment handling (#511). Some entities just should not be part of the repository, e.g., transient options or spam comments. Previously, some of this was hardcoded (e.g., transient options) or not handled very well (e.g., spam comments). VersionPress 3.0 introduces a better, extensible ignoring mechanism that will be user-configurable in the future.
• Ignoring of specific database columns (#902). Similarly to ignoring entities (database rows), VersionPress can also ignore database columns. These columns are either plain ignored (for example, VersionPress doesn't care about option_id, only option_name) or ignored with a reference to a PHP function that computes the values (for example, post's comment_count is computed dynamically).
• Initial support for custom directory layouts (#565). WordPress location, wp-content, plugins or uploads directories can now be customized. The support is initial, for example, the structure needs to be defined before VersionPress is activated, more complex setups like Bedrock are not fully supported yet, etc., but it's a good start.
• Data updates via query() are now understood (#510). Previously, VersionPress handled data updates via the insert(), update() and delete() methods which are quite straightforward to support and cover 99 % of the changes. However, that last 1 % was missing, and VersionPress 3.0 adds it by also supporting the query() method.
• Common (shared) config (#630). Most things in wp-config.php are environment-specific, for example, database connection, so VersionPress gitignored this file since 1.0-beta2. However, some config values should be shared, like the custom folder constants WP_CONTENT_DIR or WP_PLUGIN_DIR. So VersionPress 3.0 adds a config file called wp-config.common.php which is committed into the repository and require'd from the standard wp-config.php file.
• General reliability improvements. We've improved how VersionPress stores and parses the internal data formats and added some more tests around that. VersionPress 3.0 should cover anything and everything that vanilla WordPress 4.5 does, in a reliable fashion.

Other notable changes¶

• Better update method that keeps the same INI files and VPIDs across VersionPress releases was added (#906). This makes inspecting history much easier. Note that this will only become useful after 3.0, for instance, when updating to 4.0. Right now, we're only shipping the necessary underlying code. There's also a convenience WP-CLI command wp vp update available (PR #931).
• vpconfig.neon (custom configuration format) was replaced by the standard wp-config.php constants (#566).
• NEON file format was replaced with a similar but more common YAML (#703).
• PHP 5.6+ is now required (yes, we don't want our users to run on unsupported versions of PHP; #726).
• VersionPress underwent a security review and general code review by @danielbachhuber – thank you Daniel!

See all the changes in the 3.0 milestone on GitHub.

Upgrade notes¶

VersionPress 3.0 is not upgradable from previous releases, full re-activation is required. The recommended procedure is:

1. Put the site in a maintenance mode.
2. Deactivate VersionPress (just deactivate, do not uninstall).
3. Delete the contents of wp-content/plugins/versionpress and extract the current version there.
4. Activate & initialize the plugin again.
5. Disable maintenance mode.

System requirements¶

General system requirements:

• PHP 5.6.0 or later
• WordPress 4.4 or later
• Git 1.9 or later
• proc_open() enabled

System requirements for sync / multi-environment workflows:

• Custom server or VPS is recommended.