Skip to content

Test versions of Jetpack

In advance of a Jetpack release, the VIP team will post in the Lobby and to @wpvipstatus when Jetpack is updated on the VIP Platform. As Jetpack code constitutes a significant proportion of a VIP Platform site, it is recommended that functionality particular to a site is tested against betas and release candidates of Jetpack as soon as they become available. For information on available Jetpack actions, hooks, filters, and features, see Jetpack Developer Resources.

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

VIP Platform environments and local development environments can be switched to the current beta or release candidate version of Jetpack.

Pinning to a version

By default, environments on VIP load the current version of Jetpack from the vip-go-mu-plugins directory.

Sites can be pinned to a specific version of Jetpack by defining the VIP_JETPACK_PINNED_VERSION constant with the desired version number of Jetpack in the application’s vip-config.php file.

vip-config.php
define( 'VIP_JETPACK_PINNED_VERSION', 'X.Y');

Sites can only be pinned to major (X.Y) versions. To test version 9.0-beta, 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.

If the constant is defined with a Jetpack version that does not exist in the MU plugins directory, the default (current) version of Jetpack will be loaded instead.

Adding a separate test version of Jetpack to client-mu-plugins

A site can load its own version of Jetpack by committing it to client-mu-plugins/jetpack in the site’s repository branch. 

Caution

  • This method is intended for non-production environments only.
  • To avoid possible conflicts or fatals, complete Step 1 and Step 2 in separate commits. Repositories that run a build process, should allow the first build to complete before making the second commit.

Step 1: Add the test version of Jetpack to the repository

Beta versions of Jetpack can be downloaded from the Jetpack page on the WordPress.org plugins repository.

  1. Scroll to the bottom of the page.
  2. Under “PREVIOUS VERSIONS”, locate the desired beta version from the select box dropdown, and select “Download“. 

In a locally cloned and checked out version of the environment’s deploying branch:

  1. If a jetpack directory already exists in client-mu-plugins, delete it before adding the new downloaded version.
  2. Commit the version of Jetpack to be tested to the deploying branch of the environment’s GitHub repository.
  3. Add the Jetpack plugin directory within the client-mu-plugins directory. Updates do not need to be made to  /client-mu-plugins/plugin-loader.php file to reference the file.
  4. Commit the above changes.

Step 2: Load the test version of Jetpack on the environment

Define the WPCOM_VIP_JETPACK_LOCAL constant as true in vip-config.php to load the test version of Jetpack from the client-mu-plugins directory. Make this change in a separate commit to avoid conflicts/fatals.

vip-config.php
define( 'WPCOM_VIP_JETPACK_LOCAL', true );

The custom function in this code example prevents the test version of Jetpack from loading on a 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 );
}

Last updated: June 01, 2022