In addition to the
/mu-plugins directory that loads by default into all VIP environments, a dedicated
/client-mu-plugins directory is available in the root of your site git repository. This directory works similarly to
WP_CONTENT_DIR . '/mu-plugins/' in a self-hosted WordPress installation.
Plugins added to the
/client-mu-plugins directory are installed as MU (“must use”) plugins. We strongly recommend that only custom (and not third-party) plugins are added to the
/client-mu-plugins directory, depending on the preferred loading behavior. Specifically,
/client-mu-plugins should be used for code that should be auto-loaded or run earlier in the WordPress load process.
Plugins contained within a directory in the
/client-mu-plugins directory will need a “loader” file in the root of this directory to require the main plugin file.
Example content of the plugin loader file:
<?php require WPCOM_VIP_CLIENT_MU_PLUGIN_DIR . '/my-plugin/my-plugin.php';
MU plugins behave differently than plugins installed in the
/plugins directory, so be sure to read up on the pros and cons and make a measured choice.
It’s recommended to load third-party plugins from the
/plugins directory as many of these plugins utilize the activation / deactivation hooks, both of which are not executed for MU plugins.
If you use non-production environments for canary or beta-testing Jetpack updates and WordPress release candidates or for pre-production testing of your own code, you can opt into testing any updates and changes VIP makes to MU plugins ahead of their rollout to production. These changes may be “staged” anywhere from a few hours to a few days in advance of production release.
You can see which changes from our mu-plugins repository have been deployed to “staging” by checking for the
[Status] Deployed to staging label in our MU-Plugins Repo.
If you’d like to switch any of your environments to use this setup, please open a support ticket, and we will be happy to assist.