Installing plugins

On the WordPress VIP Platform, plugins cannot be installed, updated, or deleted in 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 /plugins directory 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 /client-mu-plugins.
• 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.

Drop-in plugins

Drop-in plugins are designed to replace, add, or enhance specific WordPress core features.

The sunrise.php, db.php, and object-cache.php drop-in plugins are provisioned for WordPress environments on the VIP Platform by VIP MU plugins. Customers are able to modify sunrise.php by creating and editing a client-sunrise.php file in their application’s wpcomvip GitHub repository.

No other drop-in plugins can be added. If a drop-in plugin is added to an application’s GitHub repository, it will be ignored by the environment.

Subtrees

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.

Submodules

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 .gitmodules file placed in the top-level directory of the repo. Failure to include this file can result in unexpected issues with builds and deployment.

Composer

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.