On the VIP Go platform, the codebase essentially core WordPress. In fact, the only modifications made are via a handful of MU plugins that are available via GitHub. All other custom code will be your own and committed to your Git repository. When developing your site, it is vital that you use the same MU plugins in your test environment.
What can I put in my VIP Go repository? #
When we create you a new VIP Go site, we will provide a GitHub repository under the wpcomvip GitHub organisation. The repository for each VIP Go site has the following directory structure.
- plugins — for your plugins (required, do not delete)
- themes — for your themes (required, do not delete)
- vip-config — for custom configuration changes (required, do not delete)
- languages – for your translations (required, do not delete)
- private – for any files which must not be web accessible (optional, add if required and let us know in a ticket)
The plugins and themes directories are mapped to
wp-content/themes/ and should be treated like any other WordPress install.
vip-config directory contains a file name
vip-config.php. This is where you put things you’d usually find in
wp-config.php. Not all settings can be changed as we have optimised certain aspects of the WordPress install but it is handy if you need to define an API key or something of that nature.
languages directory is mapped to
wp-content/languages, and should contain the .po and .mo files which specify the translated strings for your site.
private directory is mapped to
/chroot/private/, which is not web accessible; you might use this to store files you stream via PHP, e.g. a commercial plugin which you are charging for, and for which you need to check a purchase record before starting the download.
You can take a look at vip-skeleton to see an example of this structure.
You can read accessing your code to understand how to get access to your repository.
How does the code get deployed? #
Each VIP Go site or environment tracks a specific branch of your repository. For example, the production and staging environment will both track the
master branch, if you have requested other sites they will each have a specific branch they are tracking.
When you push a commit to a tracked branch on GitHub it will either immediately be deployed or, for the production site, the changes will be queued for review and deployed on approval. For example, if you push a commit to the
master branch that code will be immediately deployed on the
staging site and it will be queued for review, then once approved it will be deployed to the production site.
What about MU plugins? #
All VIP Go sites use the same MU plugins (
wp-content/mu-plugins/). A public repository of the current code is maintained at https://github.com/Automattic/vip-mu-plugins-public/. You do not need to commit this directory to your VIP Go repository, but you will need it in your local VIP Go development environment if you’re not using VIP Go Quickstart.
How do I access my code? #
See Accessing your code.
How do I manage my plugins? #
You no longer need to bundle your custom plugins with your theme and we would encourage keeping them separate as per the directory structure above. As the VIP Go workflow is Git based, you can also reference submodules in your repository which will make maintaining third party code easier. VIP Go currently only supports public submodules, e.g. you cannot submodule a private GitHub repository or a Git repository hosted elsewhere which requires authentication.
Each time we review a plugin (or a new version), we update this list of Reviewed Plugins. Choosing an already reviewed plugin will make it quicker for that plugin to be deployed and make it through our review queue. If you are wanting to add new functionality to a site, this list is a great place to start.
Plugins can either be activated via the WordPress admin interface or with code. It will be your responsibility to ensure plugins are up to date and compatible with your theme.
What versions of WordPress and Jetpack does VIP Go use? #
Your website will be running the latest stable version of WordPress and Jetpack at all times.
In advance of a major version update for WordPress core or Jetpack (e.g. from 4.1 to 4.2) to VIP Go, as the beta testing period begins, WordPress.com VIP will post to the VIP Lobby. The deployment of minor versions will not receive a Lobby post. Security updates will be deployed as soon as practicable, and will not receive a Lobby post.
We provide the facility to test beta and release candidates of Jetpack of Jetpack on VIP Go.
During the run up to a new version of WordPress, we invite our clients to run their non-production sites against
trunk (here is the core WordPress project explanation of
trunk and other SVN terms. If you’d like one or all of your non-production sites to track
trunk, please get in touch. Sites tracking trunk will be updated to the latest
trunk revision at least once a day, but we cannot guarantee the timing of this update.
How do new versions of WordPress get released? #
As a new release is tagged on WordPress.org we will begin rolling it out to our customers. This is a rolling upgrade process and is normally completed within 48 hours of an official release. A small subset of sites are tested before the wider release to ensure stability. WordPress.com VIP continually monitors all VIP sites to ensure they are up and serving a reasonable response code, and this process continues as we roll out releases to our customers.
As a release approaches, you should test your site against WordPress core betas and release candidates as they are released, to ensure the upgrade process goes smoothly.