Skip to content

Backgrounds

How-to Guides

Technical References

Plugins /

Installing plugins

This is the preferred approach for installing and activating plugins for the VIP Platform:

Plugins can also be activated via the “Plugins” screen on your WordPress admin area.

Note

If you are familiar with developing for WordPress.com hosted VIP sites, bundling your custom plugins inside your theme is no longer necessary and we encourage you to move them to the /client-mu-plugins directory in your site’s repository.

On the VIP Platform, all plugins must be installed by adding them to your git version control repository, hosted on GitHub. Having the plugin code in git version control allows multiple developers in your own team, and of course in the VIP team, to work on your code together, maintain and improve the site, and debug issues. On the VIP Platform, we deploy the code from git, which also allows us to roll back to a previous “known good” state, if the site encounters issues. (Please note: adding plugins via the WordPress admin area is not supported.)

As the VIP Platform workflow is git-based, you can also reference subtrees (preferred) or submodules in your repository which will make maintaining third-party code easier.

Subtrees

A subtree workflow for dependencies will pull a copy of the code into your repository. The VIP Code Analysis Bot will run automatic code reviews on subtree code when subtree code is added or changed in a pull request.

Submodules

First, we discourage submodules… please review GitHub’s discussion of how submodules work before deciding to use them.

If you don’t control the submodule source, we don’t recommend using a submodule structure, especially on production.

Submodules are a method for you to reference the GitHub repository of code dependencies so that they are then checked out to your own GitHub repository. This process is dependent on the submodule existing and being available, as it maintains a reference, but not a copy, of the code. The VIP Code Analysis Bot will not run automatic code reviews on code from an added or updated submodule, as a submodule is only a reference to another repository.

If your organization controls the submodule source, a submodule structure can be an option for you to include dependencies.

If you don’t control the submodule source, we don’t recommend using a submodule structure, especially on production. If the third party code changes upstream (becomes inaccessible, has its history changed, or otherwise becomes invalid), your submodule reference runs the risk of breaking functionality on your production site.

The VIP Platform currently only supports public submodules; i.e. you cannot submodule a private GitHub repository or a git repository hosted elsewhere that requires authentication.

Note that some plugin repositories, such as that for AMP for WordPress, contain unbuilt versions whereby the command, composer install needs to be run for the plugin to work properly. Repositories like this one cannot be referenced as submodules as we do not run these build commands on the server. In such cases, developers should use one of the other methods outlined on this page.

Composer

Plugins can be treated as PHP dependencies, and can be pulled in using Composer. This should be done by either running composer install locally, and committing all of the new files to the git, or by including composer install in the automated build and deploy step. In either case, you’ll need to configure the root composer.json to install the dependencies in the correct directory within the codebase, rather than in the default root /vendor directory.

Last updated: August 04, 2021