Skip to content

How-to Guides

Technical References

Plugins /

Installing plugins

Before reading this, it will be useful to read our documentation on your VIP Go codebase.

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

  • Add the plugins to your plugins directory
  • Activate the plugins via a plugin loader file in client-mu-plugins

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

If you are familiar with developing for hosted VIP sites, you no longer need to bundle your custom plugins inside your theme and we would encourage installing to the plugins directory in your site’s repository.

Installing plugins

On VIP Go, 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 VIP Go, 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 Go workflow is git-based, you can also reference subtrees (preferred) or submodules in your repository which will make maintaining third-party code easier.


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


Using submodules for code dependencies uses a reference to the code to check it out and include it in your 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 Go 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.

VIP Go 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.

“Shared” plugins

On, a shared plugins directory contained certain commonly used third-party plugins, and these could be loaded in a theme with the loading function above.

On VIP Go, there is no equivalent; these plugins need to be installed and maintained the same as other plugins, in your repository. If you have any questions, please get in touch.

Last updated: November 23, 2020