Staging with database merging is one of the key features of VersionPress.com, allowing you to work on your site updates in a safe, separate environment and then push live effortlessly. You can also undo any push.

Before you start

Here are some key things to know:

• Staging works best in short cycles: create staging, do some well-scoped work there and push to live. Leaving staging alive for weeks will likely lead to large diffs and make the eventual push harder.
• Certain items are ignored from staging, for example, cache files, large logging tables etc.
• Staging is limited to sites with 50,000 non-ignored database rows or less.
• Staging and open-source VersionPress are two different technologies. The ".com staging" is much more user-friendly, for example, the plugin compatibility is sorted and you don't directly work with Git.

Using staging

On the site detail screen, click the Create staging button:

After a short while, staging will be created for you:

The staging site is completely separate so feel free to experiment there.

When you log in to your staging site using the link provided, you will see a clear indication of the environment:

After you make some work in staging and want to push it live, you'll first click Compare:

You can review each and every change, and resolve conflicts (more on those):

When all conflicts are resolved, click Push:

This will deploy a new version of your live site and create a saved state:

At this point, the staging environment has been discarded but you can still click Undo to revert the whole process.

You could also use Pull instead of Push to bring the live changes to your staging environment first, which is often a good idea.

Resolving conflicts

Conflicts need to be resolved before Push / Pull. Here are some tips for dealing with them:

• Some conflicts are just WordPress noise, for example, auto-drafts. In rare cases, they might be important which is why we cannot automatically discard them but there's a pretty good chance that you can just overwrite them.
• Conflicts in options (e.g., blogname) are quite straightforward to deal with, just choose which version you'd like to keep.
• The hardest conflicts are on IDs. For example, if you created a post in staging and someone else did the same in production, those two might conflict. We cannot currently auto-resolve this and you have to do it manually, e.g., by re-creating the post manually in the other environment.

VP_ENV environment variable

Sometimes, it is useful to distinguish live and staging environments in your code, for example, to enable WP_DEBUG only in staging. You can use VP_ENV environment variable for that:

// wp-config.php

if ( getenv( 'VP_ENV' ) === 'staging' ) {
    define( 'WP_DEBUG', true );
}

Possible values of VP_ENV are 'live' and 'staging'.