The server environment must match certain requirements, some of which are checked automatically on VersionPress activation. We also recommend some other setup steps below.

Pre-activation check performed by VersionPress

Important

VersionPress is a lot more involved than most other WordPress plugins. Please pay attention to this section before proceeding with installation.

Minimum system requirements are (as a general rule, we recommend using the latest versions of everything):

WordPress 4.8 or higher

PHP 5.6 or higher

Git 1.9 or higher (2.13 or newer recommended)

Apache, nginx or IIS 7+ web server

proc_open() enabled

Write permissions in the site root and everywhere under it

Standard WordPress configuration system (wp-config.php)

On top of that, if you want to use the multi-instance / sync features of VersionPress 2.0, probably even more control over the requirement will be required. In practice, this means that a custom server / VPS is your best bet. See also the section on hosting providers.

VersionPress takes a strategic dependency on Git which provides many benefits but also requires this tool to be installed on the server and accessible from PHP. Make sure that proc_open() is enabled on the server and that the Git installation is in the PATH (if it's not, you can tell VersionPress where to find the binary via Configuration).

Git 1.9 and newer are supported. Do not attempt to make VersionPress run with older releases (1.7 and 1.8 are still quite popular), there are known issues with them.

We recommend Apache or nginx (as WordPress itself) but almost any web server should work. Just pay attention to two things:

Write permissions. The user that runs PHP and the eventual Git process needs to have write access into the locations listed below and the sys_get_temp_dir(). Initialization page checks this automatically and the system info page has a dedicated section on permissions if you need more info.

Access rules. The locations listed below should be protected against direct requests.

The sensitive locations are:

/wp-content/vpdb

/wp-content/vpbackups

/wp-content/plugins/versionpress

/.git

We ship .htaccess rules for Apache, web.config rules for IIS and wp-content/plugins/versionpress/versionpress-nginx.conf template for nginx but please confirm manually that direct access to e.g. yoursite/.git/config is prevented.

WordPress can run on an old and long unsupported PHP 5.2. We also started with this version but eventually dropped it so that we could use the newer language features and some 3rd party libraries. We recommend using one of the actively supported PHP versions.

Since VersionPress 3.0, the simplest way to update is to run the wp vp update command, e.g.:

wp vp update ./versionpress.zip

This will keep the Git repo and continue tracking the site fine, however, keep in mind that the original history becomes unactionable: you will not be able to undo old changes or roll back to previous states. (Full migrations are on our roadmap).

If you cannot use the WP-CLI update method, these are the manual steps:

Put the site in a maintenance mode.

Deactivate VersionPress (just deactivate, do not uninstall).

Delete the contents of wp-content/plugins/versionpress and extract the new version there.

Activate & initialize the plugin again.

Disable the maintenance mode.

The difference from the automated method is that the internal representation of the database has been regenerated from scratch so you won't be able to track the history of database entities easily. We will improve the GUI update method in the future.

If you didn't deactivate the plugin via admin screens and manually removed the wp-content/plugins/versionpress folder (which is NOT recommended), you have to manually restore the wp-db.php file from wp-db.php.original.

Optional: Manually download or delete a repository backup which was created under wp-content/backup.

There are two important things to note:

Once VersionPress is deactivated, it cannot be fully reactivated again on the same repository. This means that while you can initialize VersionPress again and the presence of the old repository will not be a problem, features like Undo or Rollback will only be available for new commits, created by the current activation of VersionPress. This is technical limitation that is not easy to overcome.

On uninstallation, the Git repository is moved to a backup folder under wp-content/vpbackups. You can download or recover it from there manually.

Note: VersionPress will only remove / backup the repository if it detects that it was VersionPress-initiated repository. If you created the Git repository manually before installing VersionPress the repository will not be touched.

To sum up the previous text, here are the states that the site can be in:

State

Git repo exists?

VersionPress tracking changes?

WP site without VersionPress

No1)

No

VersionPress installed

No

No

VersionPress activated on the Plugins screen

Still no

Still no

Activation finished on VersionPress screen - the plugin is active

Yes

Yes

Deactivated (on plugin admin screen)

Yes

No

VersionPress reactivated on the Plugins screen (similar to step 3)

Yes (but obsolete)

Still no

Fully activated again (similar to step 4)

Yes

Yes

Uninstalled

No (backed up)

No

1) The repo might exist if you created it manually or if VersionPress was previously installed. It is not a problem – VersionPress will happily add commits to the existing repository but a common scenario is that there is no default Git repository and VersionPress creates one.