WordPress.com VIP Platform
This document is for sites running on our WordPress.com VIP platform.
All WordPress.com code is managed using the Subversion revision control system. Subversion (SVN) is the only way to access and update code on VIP Hosting.
Accessing SVN #
To get SVN Access to your theme, please first make sure you have Two-Step Authentication enabled.
Two Step Authentication drastically reduces the likelihood that someone could gain unauthorized access by adding a second, very hard-to-guess log in requirement to your user account. To learn more about Two Step Authentication, read the support page or contact VIP.
Once that’s all set, you can request for SVN Access via your VIP Dashboard, under the “VIP” tab:
Once read-write access has been granted, you’ll receive an email with the subversion repository URL, which is specific to your site. You’ll also receive read access to our shared VIP plugins. For more details about our shared plugins, please see the plugins section of this site.
All code development and testing should be done in your own local development environment. Only tested code should be committed to WordPress.com.
Committing Code #
Once you have read-write access, you can commit your code directly. Once you do, it is spot reviewed for security and performance concerns, and then deployed to server clusters in all of our data centers. Should you not want the commit to be deployed directly after a satisfactory review, please follow the instructions for how to schedule your deploy.
For your benefit, we take code quality, security, and performance very seriously. Every commit is spot reviewed by someone on the VIP team before it can be deployed. It’s really important to include a detailed commit message to help expedite your review. Please take a look at our deploy review guidelines. Code changes are usually deployed within a few hours during US business hours, but usually much faster (within two hours).
We do expect all committed code be thoroughly tested and follow our best practices guidelines. If we see repeated mistakes, we will revoke write access.
Please check with us before committing very complicated or large chunks of code. As a general guideline, commits should include fewer than 1,000 lines of changes or modifications to PHP and unminified JS.
If in doubt, it’s best to check with us first by submitting a ticket. It’s a lot less work for everyone (including you) if we’re able to take a look at it before committing than having to revert the change later. We also greatly appreciate if you commit often and with each functionality as a separate commit (if possible) rather than waiting and pushing a bunch of code to us all at once. It makes the code easier to review if we’re reviewing things in chunks.
We also like to review all plugins prior to committing them to your VIP repo. We have reviewed a small, but growing list of plugins, and modified some of them to make them more stable, secure, and perform better. Since these plugins have been pre-approved, we would prefer you use these plugins if possible if you need functionality similar to what they provide. Please see the Plugin Review Process if a solution isn’t yet available.
File Types That Are Auto-Deployed #
We auto-deploy commits that consist entirely of static CSS or image files. If there are no other pending deploys for your theme, your CSS design changes and image commits will be deployed almost immediately with no review. If you want to ensure that a commit is auto-deployed, be certain that it only contains the file types listed below and does not have any non-auto-deploy commits in front of it. It’s worth noting, too, that even adding a new directory to a commit will prevent it from auto-deploying. So if you commit all image files inside a newly added directory, that commit will not auto-deploy.
File types that auto-deploy:
Deploy Status #
At VIP → Dashboard (
/wp-admin/admin.php?page=vip-dashboard), you can see the current deploy status.
Commit Messages #
All commits on the VIP repo should be accompanied by a Good Commit Message.
Reverting Code #
A detailed document on how to revert via svn can be found here, Rolling Back / Reverting Changes to Your Theme Using Subversion.
If you’ve committed code you’re not happy with and would like to revert, you can do so from your local checkout. Simply use the command “
svn merge -c-64320 .” where “64320” would be the revision you’d like reverted. After running that command, you’ll need to commit your revert. You’ll want to use a commit message similar to “Reverted r64320 because [explain your reasoning]”.
Note that the revert will need to be deployed as well and you can open a ticket requesting that.
Shared Accounts #
We don’t allow generic usernames or shared user accounts to have write-access to your VIP code repositories, as it obfuscates which developer wrote the code in the first place, and also encourages insecure password management. Please use a unique user account for each developer on your team.
Occasionally VIP development teams prefer to have a single lead developer responsible for managing their team’s code and committing to VIP on their behalf. We would like to know if this is the setup you are using and who the lead developer is. We’re happy to support this workflow so long as the person committing is themselves a developer, and takes responsibility to review the code against our guidelines before committing. If that isn’t happening, and/or we see repeated issues around code quality, we’ll need to insist that each of your developers have separate VIP accounts and support seats.
Commit and Deploy Notifications #
When a code commit is deployed to WordPress.com, an email notification is generated to every WordPress.com user who has access to the theme’s SVN repository.
In addition, we support the use of webhooks for both commits and deploys. These allow you to customize the kinds of endpoints you use to receive notifications about activity in your theme code. Note that these only work for theme repositories, not shared plugin repositories.