Test versions of Jetpack

Automattic tests Jetpack releases against a diverse range of environments and sites, to assess performance with various levels of data and traffic. There is also an automated Jetpack test suite, run on Travis, which you can follow. As the Jetpack code is a significant proportion of your VIP Platform site, we recommend you test your particular functionality against betas and release candidates of Jetpack as they become available. In advance of a Jetpack release, the WordPress.com VIP team will post in the Lobby to keep you informed; we’ll post to our @wpvipstatus when Jetpack or WordPress are updated on the VIP Platform.

For more information on available Jetpack actions, hooks, filters, and features, see Jetpack Developer Resources.

This document describes how to switch your VIP Platform site(s) and development environment to use the current beta or release candidate version of Jetpack. You may also wish to read about VIP Platform sites and environments.

Pinning to a version

By default, the VIP Platform will load the current version of Jetpack from the MU plugins directory. Using the VIP_JETPACK_PINNED_VERSION constant, you can instruct the VIP Platform to load a specific version of Jetpack, maintained in parallel in the MU plugins directory. Simply add the constant with the version number you’d like to the site’s vip-config.php file.

define( 'VIP_JETPACK_PINNED_VERSION', 'x.y');

Note that sites can only be pinned to minor (x.y) versions. For example, if you want to test version 9.0-beta, just use 9.0 in the constant. When 9.0 is released, it will be updated automatically. Point releases containing security patches and/or bug fixes will automatically be applied to each version.

In the case of a constant specifying a Jetpack version that does not exist in the MU plugins directory, the default (current) version of Jetpack will be loaded.

Using Jetpack in client-mu-plugins

This method allows a site to load its own Jetpack version that is committed to client-mu-plugins/jetpack in the site repo. Generally we recommend using the VIP_JETPACK_PINNED_VERSION constant as described above, but the WPCOM_VIP_JETPACK_LOCAL constant may still be used if you need to run Jetpack from client-mu-plugins.

Step 1: Add the version of Jetpack to be tested

Commit the version of Jetpack you wish to test into your VIP Platform site GitHub repository. Add it as a directory inside the client-mu-plugins directory (only add the directory, do not add an additional file referencing the plugin directly into client-mu-plugins).

Each beta can be downloaded from the Jetpack page on the WordPress.org plugins repository. Scroll to the bottom of the page and under “PREVIOUS VERSIONS” choose the beta you need from the select box dropdown, then click “download”. To be certain you bring across all files, delete any previous jetpack directory and add it from the download you just made. If you have any questions, please contact us.

Step 2: Load the “local” version of Jetpack

By default, the VIP Platform will load Jetpack from the MU plugins directory. Using the WPCOM_VIP_JETPACK_LOCAL constant, you can instruct the VIP Platform to load Jetpack from the client-mu-plugins directory. Be sure to make this change in a separate commit to avoid conflicts/fatals.

define( 'WPCOM_VIP_JETPACK_LOCAL', true );

If you want to avoid testing on your production site, for example during the beta period (you may choose to run the release candidate on your production site):

$disallowed_jetpack_test_envs = array(
    'production',
);
if ( ! in_array( VIP_GO_APP_ENVIRONMENT, $disallowed_jetpack_test_envs, true ) ) {
    define( 'WPCOM_VIP_JETPACK_LOCAL', true );
}