On the WordPress VIP Platform, plugins cannot be installed, updated, or deleted from within the WordPress Admin dashboard. Plugins can only be installed, updated, or deleted via the VIP site’s wpcomvip GitHub repository. On the VIP Platform, code is deployed from git, which makes it easier to roll back to a previous “known good” state if a site encounters issues.
- Install third-party plugins by adding them to the
/pluginsdirectory of an application’s wpcomvip GitHub repository. Archived plugin files should be decompressed before being added to the repository.
- Each plugin should be added in its own pull request in order to make any necessary reverts as easy as possible.
- Plugins can and should be code activated by a plugin loader file in
- Installed plugins can also be activated via the “Plugins” screen in the WordPress Admin dashboard.
Plugins added to the
/plugins directory are automatically scanned by Codebase Manager for security vulnerabilities and available version updates.
Plugin activation for WordPress multisite
By default, users with an Administrator role do not have the permission to activate or deactivate plugins for an individual network site on a multisite environment. To grant this permission to Administrators, a user with a Super Admin role must enable this option at the network level.
- Navigate to: My Sites > Network Admin > Settings.
- Under “Menu Settings“, toggle the “Enable administration menus” checkbox.
Enabling this option will allow all Administrators on all sites on the network to access the Plugins dashboard for their site.
A user with a Super Admin role can also network activate a plugin for all sites on the multisite.
Because the WordPress VIP Platform workflow is git-based, GitHub subtrees can be used to pull in third-party plugin code.
By using the Git subtree workflow, a copy of the referenced code is pulled into the site’s repository. This makes it possible for the VIP Code Analysis Bot to run automatic code reviews on subtree code when subtree code is added or changed in a pull request.
VIP does not recommend the use of submodules, especially for branches deploying to a production environment.
Using submodules has several disadvantages. The VIP Code Analysis Bot is unable to analyze code in submodules. In addition, if the submodule’s code changes in a negative way (e.g., becomes inaccessible, has its history changed, or otherwise becomes invalid) it creates the risk of breaking a site during deployment without warning.
If submodules are used they must meet the following requirements:
- Submodules that reference private GitHub repositories or those that require authentication are not supported on the VIP Platform.
- Submodules must be referenced in a
.gitmodulesfile placed in the top-level directory of the repo. Failure to include this file can result in unexpected issues with builds and deployment.
Plugins can be treated as PHP dependencies, and Composer can be used on VIP to pull in runtime dependency packages—such as plugins—during a local or continuous integration (CI) builds
Some plugin repositories, such as AMP for WordPress, contain unbuilt versions of code. In these cases, running the command,
composer install is required for the plugin to work properly. Repositories like this one cannot be referenced as submodules as VIP does not run these build commands on the server.
Last updated: January 31, 2024