Code Management Workflows

The exciting new changes to our code review process will help empower teams with greater versatility for workflow setups. As of July 15th, 2020, there are several types of workflows that can be configured to best fit the needs of your development team.

There are many different combinations available with the workflow options provided below (since they are not mutually exclusive):

1) Continue with the default setup

It is possible that you won’t require any type of custom workflow, in which case this would be the “status quo” option. In short, when the development team desires a code review from the WordPress VIP team, they can flag it for review and our team will continue to review as we always have. More information available here.

2) Assign designated team members to merge code

As an additional safeguard, code repositories can be configured to grant only certain members of your team the ability to merge code into production. Team members will still be able to test code in staging environments, open pull requests, and request reviews from VIP. However, the final act of merging code into the production environment could only be done by members of a specified team.

3) Configure mandatory approvals from another team member

Before merging code into production, at least one other team member could be required to sign off on the changeset. This is similar to the previous option, except the ability to deploy the code is available to the changeset author after approval, as well as additional designated team members.

It would be possible to expand on this by configuring specific groups of team members and enforcing approval from each group. For example, one person from the development team and one person from the QA team could be required to sign off before allowing merges. Additionally, certain areas of the codebase could require mandatory approvals on a team basis.

4) Other options

If your workflow needs are not covered by the above options (e.g. if you have a specific workflow in mind not covered) or if you are feeling uncertain of your needs, please reach out to VIP Support and we would be happy to provide further guidance and address any concerns or questions.

Working with wp_options

WordPress has a built-in way to store simple key-value data known as the Options API.  This API is can be used to store data like a theme setting, a plugin setting, or even global site settings (e.g. Number of Posts to show on the homepage: 3). This data is stored in the wp_options table and has 2 unique keys: option_id and option_name.

Tip:  You can see all of your site’s current options on your dashboard using following path:

Reference: WordPress Options API Handbook

Working with Options

When adding an option to your wp_options table, there are a few things you should consider that will impact your site’s performance.

Large Options

If you want to store options that are large in size, please consider using WP Large Options.  This plugin will store options in a custom post type and prevent the wp_options table from getting too large.

Data that might be a good fit for using WP Large Options:

  • Large HTML fragments
  • Any CSS (though we recommend storing this in theme files instead)


You can use functions like add_option() and update_option() to create options in the wp_options table. Here’s an example of what the table might look like:

You’ll notice that the fourth column is titled autoload.  Whenever a request comes to WordPress, it has to make many complicated and quick decisions in order to serve the right information to a user. One well-known way to improve the speed at which this can be done is to define certain options as needed on every page load and others as not really that important.  The way you do this is by setting an option to autoload = yes.  When you do that, WordPress will store all of those options into a single object and load them on every page load.  On VIP Go, we optimize this by loading these options into Memcached to improve the speed at which WordPress can load and use these options.

One very important note is that our Memcached implementation has a limit of 1 MB per object.

One very important note is that our Memcached implementation has a limit of 1 MB per object.  That means that the size of the AllOptions cache object cannot exceed 1 MB (code reference). We do this intentionally because we know the severe performance impact that loading too much data in AllOptions can have. Our approach, instead, is to set a hard limit and to educate and help you understand how to best use this part of WordPress.

Warning: Both add_option() and update_option() will default to autoload=yes

Reference: add_option()

Reference: update_option()

Identify and resolve problems with AllOptions

The most common problem with AllOptions happens when its’ size reaches 1 MB. Letting your site’s option reach that size will have negative performance implications and can lead to the site being unavailable until the problem is fixed.

If you have an issue with your AllOptions size, we recommend the following steps:

  1. Identify which options are the largest
  2. Backup and audit the problematic options
  3. Delete or set the option to autoload=no
  4. Figure out the root cause for why the option got to it’s problematic size
  5. Fix the root problem to ensure site performance is not impacted further

Here are some tools and suggestions to help you with diagnosing and fixing a problem with AllOptions:

WP_CLI and the VIP CLI

Two tools you’ll be seeing us use are WP_CLI, a command line interface for WordPress, and VIP CLI, a tool to interact with your VIP Go applications through the command line.  Together, they can do some very powerful things!

Reference: Using WP_CLI on VIP Go

Reference: Using the VIP CLI

Using the VIP CLI to identify big options

With the VIP CLI, we have a command available that will show you in a table format which options inside AllOptions are taking up the most space:

vip @<app-ID or app-name>.<app-environment> -- wp vip alloptions find --big 

Running that command will return the following:

$ vip @12345.production -- wp vip alloptions find --big
Success: Big options for - Blog ID 1:
| name                            | size   |
| large                           | 512000 |
| rewrite_rules                   | 22387  |
| wp_user_roles                   | 7967   |
| jetpack_available_modules       | 1211   |
| jetpack_constants_sync_checksum | 1183   |
| subscription_options            | 529    |
Total size of all option values for this blog: 541 KB
Size of serialized alloptions for this blog: 555 KB
   use wp option get <option_name> to view a big option
   use wp option delete <option_name> to delete a big option
   use wp option autoload set <option_name> no to disable autoload for option

Saving a backup of your options

You can save the output from a specific option using WP_CLI.  Here’s an example of how I could save the output from rewrite_rules:

vip @12345.production -- wp option get rewrite_rules --format=json 2>&1 | tee rewrite_rules.json

Note: the JSON output will also contain some confirmation text about running the command on your site. If you intend to use this data later make sure you remove that from the JSON.

Disabling autoload for an option

To disable an option from autoloading, you can use vip @12345.production -- wp option autoload set <option_name> no to remove that option from AllOptions. Remember to make sure that this is also fixed where the option originally was added or updated.

Clearing the AllOptions Cache

When you’ve made changes to AllOptions you might still need to clear the Object Cache to make sure your data is now what’s being stored in the cache.   You can do that by running the wp cache delete <cache key> <cache group> WP_CLI command:

vip @12345.production -- wp cache delete alloptions options
+ command: wp cache delete alloptions options
✔ Are you sure you want to run this command on PRODUCTION for site (y/N) · true
Success: Object deleted.

Deleting an option

To delete an option you can use the WP CLI command:  wp option delete <option_name>

Other considerations

Be careful how often you change data in AllOptions.  Since AllOptions is stored in Memcached, when the data changes, WordPress will have to rebuild the cache for that key which could impact your site’s performance.  If you need some data stored for quick retrieval, you can just store it in the Object Cache without having to use AllOptions.

Only store the bare minimum amount of data in wp_options.  We can’t stress this one enough!  Instead of storing the whole HTML fragment, just store a Post ID for what you need and let your theme do the rest!

Widgets are stored in wp_options, so be careful to not store too much data in those HTML or Text Widgets!  Instead, use a custom post type for that kind of data.

Guide to Requesting Code Reviews

Code review will operate on a request-by-label basis for clients on VIP Go as of July 15th, 2020.  


  • To request a review from WordPress VIP, please add the label “[VIP] Review Request” to the pull request
  • A review is no longer mandatory, so branch protection rules have been removed
  • You can now leverage GitHub protection rules that work best for your team’s workflow

What has not changed

  • The PHPCS bot will continue to run on all new pull requests in any branch
  • Service level agreements regarding review timeliness remain unchanged
  • Branches, previously not reviewed by WordPress VIP, will remain un-reviewed
  • No changes for sites on (SVN)

Why the change?

This new process will empower developers to choose when and which pull requests should be reviewed by WordPress VIP, because we recognize that many updates do not require review.

Frequently Asked Questions

How do I request a review?

If you would like a review on your pull request before merging to production, add the label* “[VIP] Review Request“.  Please note that pull requests without the label will not be reviewed.

You can find the labels in the GitHub UI on the right sidebar of your pull request:

* This label will become available on all applicable repositories prior to July 15th, 2020.

Do I need to request a reviewer?

No, simply add the label from the available list of labels when your pull request is ready for review.

How do I merge without review?

After opening a pull request, you may merge to your production branch by clicking on the “Merge pull request” button near the end of the pull request:

Has anything changed in my GitHub repository?

Yes, we’ve added a new label ([VIP] Review Request) and modified the branch protection rules for your primary branch.  However, you are welcome to modify the branch protection rules as needed (e.g. to customize a workflow):

Pull request reviews are no longer required.

When should I skip a review?

We recommend reviews for pull requests with security or performance implications. Reviews are also helpful if your team has questions about development best practices.

For smaller and less complex changes, a review may not be necessary. For example:

  • CSS changes
  • Re-compiling of assets
  • Changes to readme, build scripts, ads.txt, and other non-code files
  • Third-party library or plugin updates (via composer, npm, etc.)
  • Reverts of previous pull requests
  • Immaterial changes such as changing strings or variable names, whitespace changes, reformatting, and other minor refactors

How do I set my own branch protection rules?

Branch protection rules are a set of configurations that allow repository administrators to enforce security policies (i.e. ensuring code is reviewed, preventing accidental branch deletions, etc.) and to require successful automated checks before pull requests can be merged.

Go to your repository branch settings ({myrepo}/settings/branches), choose a branch, and begin customizing.  More information about branch protection rules. Please note: rules can be customized after  VIP’s branch protection rules are removed on July 15th, 2020. 

What can I use branch protection rules for?

GitHub continually adds features to their protection rules, but here are some current potential use cases for imposing restrictions:

  • Ensuring that the PHPCS bot scans all changes by enforcing pull requests on certain branches
  • Internal code reviews on pull requests by requiring at least one approving review before merging
  • Restricting which users can merge pull requests

What types of workflows can I use for pull requests?

You may combine branch protection rules and GitHub’s pull request features with your own internal processes and/or tools to customize your workflow. Some examples:

  • If you have your own private repository and CI/CD creating pull requests in your VIP repository, you can automate selectively adding the label to pull requests (i.e. if your release manager gives it a “Needs VIP Review” label in the private repo, your automation adds the VIP label in the VIP repo)
  • If you would like to start (or already have been) requiring internal reviews on pull requests, you can re-establish the rules to require pull requests
  • If you have certain designated team members to decide when to merge a pull request, you can add their names to a list of people allowed to merge
  • WordPress VIP has a CI/CD option that can be used post-merge to run code builds, so that only source files are present in your main branch and built files are not part of a changeset during reviews

What if I want to require review on all PRs?

We understand that some WordPress VIP clients may wish to continue with the required review policy for the foreseeable future, or may not wish to change an existing custom review configuration (i.e. for dual-deployment). If these situations apply to you, please reach out to your Relationship Manager or VIP Support, and we’ll be happy to discuss your needs and ensure that your repositories reflect your requirements.

What if I have concerns or questions?

We realize everyone has a different workflow and we are here to assist you with this change. Please reach out to your account team or open a ticket with us.


Restricting access via Basic Authentication

Basic Authentication is the “pop up” prompt for a username and password which is displayed by your browser when you visit a site which is protected in this way.

While a site is under development, and for non-production sites, you can set up Basic Authentication via your VIP Dashboard.

It is not possible for launched production sites to use Basic Authentication, as this form of access control breaks various VIP Go platform services.




To enable Basic Authentication in the VIP Dashboard by visiting the Settings -> Basic Authentication -> Configure.

Select the desired environment from the dropdown, e.g. “production” or “develop.” Enter the username and password information for any user who should have access to your app via Basic Authentication. The password you enter will be encrypted when stored; you do not need to enter an encrypted version of the password. If you are using a multisite WordPress install, the Basic Authentication restrictions you create will apply to all subsites.

Once you’ve added credentials, you can remove them from the site by deleting the users. To completely remove all Basic Authentication restrictions, remove all users.

Removing a user from basic auth

Requests: VIP’s Unit for Traffic and Platform Utilization Measurement

VIP tracks a single metric in order to track usage of our platform across all site architectures, from a plain vanilla WordPress single site, to n-tier architectures, or single page applications: Requests. We define a Request technically as an HTTP Request and any associated response. 

Why VIP Uses Requests as Its Key Metric

Requests is the most meaningful way to measure the modern digital customer experience. The number of different types of digital interactions that now exist is dizzying — web pages, email, mobile apps, mobile messaging, social media, gaming platforms, in-store kiosks, content aggregators, and more. The most effective customer experience strategies drive content from a central platform into all those points of interaction. 

These touchpoints are so diverse that about the only thing they all have in common is that each one makes “requests” for the right content to display to each customer. A request is the closest thing to a universal metric that applies to all interaction points in the digital experience. In contrast, the age-old “page view” is a dated concept from the days when a web page was the main point of digital interaction. Focussing on requests allows us to capture all the opportunities for engagement in a modern digital experience.

The more requests for content made, the more customers and prospects a company is interacting with and engaging — and the more value is being created. So, by using requests as a key metric, VIP is aligning its value measures with what drives success for its clients. VIP clients should want to generate more requests for content, and the VIP platform will be ready to serve that content.

How VIP Calculates Requests

We define a Request technically as an HTTP Request and any associated response. 

We use the HTTP content type of the response to categorise the Request. The HTTP content type is a technical detail of HTTP (Hyper Text Transfer Protocol) that underlies all web communication, we use it to classify Requests into the following categories:

  • App Requests: Requests with a response content type of text/html or application/xhtml; these will be “web pages” (albeit just the HTML), redirection responses, “page not found” responses, etc.
  • API Requests: Requests with a response content type of application/json; these will mainly, perhaps exclusively, be REST API responses, GraphQL API responses, etc.
  • Static Requests: everything else

We further subdivide all Requests into originating on Automattic or WordPress VIP infrastructure, or not. This gives us the following final six categories:

  • Requests from inside Automattic or WordPress VIP infrastructure:
    • App Requests
    • API Requests
    • Static Requests
  • Requests from outside Automattic or WordPress VIP infrastructure:
    • App Requests
    • API Requests
    • Static Requests

We charge for App and API requests from outside Automattic or WordPress VIP infrastructure.

We do not charge for App and API requests from inside Automattic or WordPress VIP infrastructure.

We do not differentiate between HTTP Response Status Codes, i.e. all App and API requests from outside Automattic or WordPress VIP infrastructure count towards your utilization, regardless of the response status code.

Forecasting your Request volume

What volume of requests is likely for a given client? There’s no simple rule-of-thumb. But VIP works closely with each prospective client to understand the digital experiences that drive their business, and other factors that might impact request volume, such as seasonality. Together, VIP and the client can quickly arrive at a forecasted volume of requests, and agree to a contract under which VIP will support that volume.

Once agreed upon, VIP rarely charges overages in cases where unexpected business circumstances boosts request volume — such as a major news event increasing readership,  unexpected popularity of a new product or offering, or some other viral sensation. If a client undertakes a deliberate change in business strategy, such as launching a new business or entering a new geography, VIP will work with the client to adjust the contract as necessary.


We understand your need for stable costs during the period of a contract with VIP, so for the vast majority of our clients we do not charge overages or adjust pricing in mid-contract. Over the course of each contract your VIP Relationship Manager will work with you to understand your usage of our platform, and agree any adjustments required at renewal. Only for the situation that a Customer’s overages are egregious and sustained does VIP reserves the right to invoke the Resources clause in the VIP Master Services Agreement (section 2c).


Do you count requests from machine traffic, e.g. load tests, penetration tests, spiders, crawlers, bots, etc?

Bots and other machine traffic interact with your site and your organization in different ways than your native apps, or your human readers, but VIP considers that they still add value: Google Bot crawls your site to index it for search, Load and Penetration Tests allow you to validate performance and security of your codebase, and so on. On this basis, we count machine traffic towards your utilization of the VIP Platform.

Will a Denial of Service Attack attempt affect my tier at contract renewal?

VIP recognises that Denial of Service Attacks can result in very significant volumes of traffic against your applications on the VIP Platform. We recognize that this activity is malicious and that one key reason for many people working with VIP is our ability to mitigate even extremely significant denial of service attempts, we do record the traffic caused by an attack but we will not take this traffic into account when considering tier changes at contract renewal.

How do Requests compare to Pageviews?

Pageviews are a subset of App Requests (see definitions above). Request volume will always be much higher than Pageview volume. Our VIP Business Development team will be able to give you guidance on likely Request volume, and therefore tier, if you can provide your Pageview metrics.

Why don’t you use Pageviews?

Pageviews is a metric that has been with us for a very long time, and reflects a web that is no longer universally applicable. Pageviews does not allow for n-tier decoupled architectures. Pageviews does not allow for the use of WordPress to power mobile applications. Pageviews does not allow for using WordPress to power digital signage.

We believe that Requests allows us to measure the value and opportunity we see in the range of uses our innovative clients create on the VIP Platform.

Can I validate my Request totals?

We can provide you with your HTTP Request logs using our Log Shipping feature, and our logs include the response content type field. We provide a feed of our IP Ranges at Using these data and the definitions for Request categories above, you should be able to calculate the metrics.

HTTP Request Log Shipping on VIP Go

VIP’s Log Shipping feature allows you to automatically save HTTP request logs to an Amazon Web Services S3 bucket at 5-minute intervals. The logs are then available to your team and contractors for storage, process, or analysis. Logs are an important asset in understanding the use of your system, connectivity issues, performance tuning, usage patterns, and in analysing service interruptions.

Currently we only provide Log Shipping for your HTTP (web) Request logs.


You will need:

  • An AWS S3 bucket, make a note of the the bucket name and region
  • Access to create/update the AWS Bucket Policy configuration for the bucket


1. Get the name of your AWS bucket and region.

2. Enter it into the dashboard under Settings > Log Shipping

3. The dashboard will generate a config file in JSON format that you need to paste into your AWS Bucket Policy configuration. For the desired bucket, navigate to “Permissions,” then select “Bucket Policy.” The JSON file can be saved there.

4. Once the configuration information is entered into the dashboard, a test file will be sent to the bucket. Note that a test file is uploaded as part of the verification process, aptly named vip-go-test-file.txt. This file will always be present in a sites configured bucket and path, alongside the date folders that contain the logs themselves.

The path used to write to the bucket is [bucket]/[app_name]/[app_environment], e.g. my-log-bucket/my-app/production. This means that you can use the same bucket for more than one app or environment, should you choose to do so.

Objects written to the specified S3 bucket are done so with the bucket-owner-full-control canned ACL.

Restricting access by IP range

If you want to restrict access to your AWS S3 bucket via IP range, ensure your bucket access policy accounts for the dynamic IP range accessible at You will need to implement a system to auto-update the access policy, as the IP ranges are subject to change.

Log contents

The log files are written as a series of gzipped JSON files. Here is a sample record:

  "client_site_id": "000",
  "remote_user": "",
  "request_url": "/",
  "wplogin": "-",
  "timestamp": "19/May/2020:17:03:58 +0000",
  "request_type": "GET",
  "scheme": "https",
  "http_referer": "https://example/",
  "http_x_forwarded_for": "",
  "true_client_ip": "",
  "remote_addr": "REDACTED",
  "tls_version": "TLSv1.3",
  "content_type": "text/html; charset=UTF-8",
  "upstream_country_code": "GB",
  "sent_cache_control": "max-age=300, must-revalidate",
  "timestamp_iso8601": "2020-05-19T17:03:58+00:00",
  "sent_vary": "Accept-Encoding",
  "sent_x_cache": "hit",
  "request_time": "0.001",
  "http_host": "",
  "http_accept_language": "en-US,en;q=0.9",
  "http_user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36",
  "http_version": "HTTP/2.0",
  "body_bytes_sent": "8981",
  "status": "200"

Description of fields

  • body_bytes_sent: total number of bytes sent to the client
  • client_site_id: an internal ID unique to this environment
  • content_type: the media type of the resource, e.g.
    text/html; charset=UTF-8
  • http_host: the domain, e.g.
  • http_accept_language: the contents of the Accept-Language request HTTP header
  • http_user_agent: the contents of the User-Agent request header
  • http_version: HTTP protocol version
  • http_referer: the Referer request header, if available, containing the purported address of the previous web page from which a link to the currently requested page was followed
  • http_x_forwarded_for: a header that is a means of logging a client’s originating IP address
  • remote_user: the username if the request was authenticated with HTTP Basic Authentication (we don’t log the password)
  • request_url: the path of the resources that was fetched, not including elements that are included elsewhere, e.g. the protocol (e.g. http://, see `scheme`), and the domain (e.g., see http_host)
  • request_time: the time taken for the request
  • request_type: the HTTP method
  • sent_cache_control: the contents of the Cache-Control HTTP response header
  • sent_x_cache: a header from the VIP platform indicating whether the response was from a cache hit, miss, or pass
  • scheme: either http or https
  • sent_vary: The contents of the Vary HTTP response header, note that we do not allow free use of the Vary header, e.g. Accept-Encoding,
  • status: the HTTP response status code, e.g. 200, 404, etc.
  • timestamp: UTC date and time of request
  • timestamp_iso8601: UTC date and time of request in ISO format
  • true_client_ip: a request header commonly set by reverse proxies, including Cloudflare, to indicate the remote address of the client they are forwarding requests for, see also http_x_forwarded_for  there is no formally agreed specification and VIP Reverse Proxies documentation
  • remote_addr: IP address of the client making the request (see also true_client_ip and http_x_forwarded_for)
  • tls_version: TLS version used by the client
  • upstream_country_code: all requests are geocoded by country at the edge of the VIP CDN using the incoming IP address, e.g. “US”, “GB”, etc
  • wplogin: the login name (i.e. user_login) of the authenticated WordPress user, if any; requests where there is no authenticated WordPress user this field will contain -

Using Your Log Data

The JSON formatted log files are readable individually by humans, but to make full use of your logs you will need to ingest them into another service. Here are some examples of platforms that will help you make the most of your data, depending on your use cases:

  • ELK (Elasticsearch, Logstash, Kibana) will help you filter and view your logs
  • Splunk will help you search, monitor, and analyse the data from your logs
  • Data Dog will help you understand development issues within your logs
  • Botify will help you understand SEO issues revealed by your log data

VIP Go local development – Windows

For non-Windows-specific development, please see our local development documentation.

Everything in this task list assumes you have administrative access to the host machine. For Windows 10 hosts, any command prompt, PowerShell, VS Code instance which is run must be Run as Administrator.

  1. On Windows 10, install Git for Windows and the OpenSSH client.
  2. Enable the OpenSSH Authentication Agent service for automatic starting, which is disabled by default. Then add the SSH key associated with your Github account to the agent via PowerShell or command prompt. Create a key first if neccessary, then run:
    ssh-add {path_to_public_key}
  3. Configure Git to use OpenSSH, and increase the size of Git packages and buffers to allow large file and pack transfers. Add the following settings to your user profiles .gitconfig, the sections are listed, do not create duplicate sections, append if needed.
        autocrlf = true
        sshCommand = C:\\\\Windows\\\\System32\\\\OpenSSH\\\\ssh.exe
        packedGitLimit = 128m
        packedGitWindowSize = 128m
        deltaCacheSize = 128m
        packSizeLimit = 128m
        windowMemory = 128m
        postBuffer = 1024m
  4. Run the VVV installation. If you run into issues installing, try a previous, known good VirtualBox version. Follow through running vagrant up for the first time, additional sites can be added later.Later instructions will refer to the base installation folder for VVV, where you checked it out, as {vvv_path}.
  5. Create a new VVV site definition inside config/config.yml for the site with the custom site template, for instance this example creates a site at https://vipgo.test:
        - vipgo.test
        wp_type: subdirectory
          WP_ALLOW_MULTISITE: true
          MULTISITE: true
          SUBDOMAIN_INSTALL: false
          DOMAIN_CURRENT_SITE: "vipgo.test"
          PATH_CURRENT_SITE: "/"
          WP_DEBUG: true
          WP_DEBUG_LOG: true
          WP_DEBUG_DISPLAY: true
          SCRIPT_DEBUG: true
          VIP_GO_APP_ENVIRONMENT: true
          DISALLOW_FILE_EDIT: true
          DISALLOW_FILE_MODS: true

    Enable helpful utilities by modifying the config files utilities section:

        - memcached-admin
        - opcache-status
        - phpmyadmin
        - webgrind
        - trusted-hosts
        - tls-ca

    Finally, increase the resources, and optionally add a static IP to your instance. In my case, my VirtualBox network uses, and I am assigning the instance the IP Remove the private_network_ip and network_ip lines if not needed.

      memory: 4096
      cores: 2
  6. Copy the database dump SQL file you have to database/sql/backups directory, and change the name to match the site definition name, in this example vipgo. If you do this before you reprovision, it will load this dump file when provisioning as the sites database. You can do a find/replace on the file before loading (may be slow with a large file), or use WP CLI inside the instance to change the domain names.
  7. Reprovision the instance to create the new site:
    vagrant reload --provision
  8. Add an .htaccess file to support the multisite instance in {vvv_path}/www/vipgo/public_html/:
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
    RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
    RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
    RewriteRule . index.php [L]
  9. The VIP repository is hosted in the sites wp-content directory, you need to empty it first. In this example, find it at {vvv_path}/www/vipgo/public_html/wp-content/.
  10. Clone the sites VIP go instance repository, URL of {instance_url} the folder:
    git clone {instance_url} --recursive {vvv_path}/www/vipgo/public_html/wp-content
  11. Pull all of the VIP Go MU plugins into your VVV instance. Note: this only works if you have a SSH key associated with a Github account. If there are any failures, please check your Git configuration accepts the larger pack and buffer sizes specified above.
    git clone --recursive {vvv_path}/www/vipgo/public_html/wp-content/mu-plugins/
  12. Add the VIP Go configuration from your site repository into the VVV site configuration located at {vvv_path}/www/vipgo/public_html/wp-config.php. Locate the comment \/* That’s all, stop editing! Happy blogging. *\/ and place this block above it:
    if ( file_exists( __DIR__ . '/wp-content/vip-config/vip-config.php' ) ) {
        require_once( __DIR__ . '/wp-content/vip-config/vip-config.php' );
  13. If you run into any issues with missing plugins, either mu-plugins or from your site repository, you likely need to pull the Git submodule. To do this, clear the plugin directory then reinitialize the plugin. For instance, assume the plugin name is plugins/polldaddy, and from the command prompt run:
    git submodule update --init plugins/polldaddy
  14. Perform a WP CLI search-replace to update domain names and links. In this example, assume the initial domain name is prod-vip.go, which will be replaced with vipgo.test. From a command prompt, in a directory inside the {vvv_path}, SSH into the Vagrant instance:
    vagrant ssh

    Then switch to the site path, in this example, /srv/www/vipgo/public_html/, and run the following search-replace:

    wp search-replace 'prod-vip.go' 'vipgo.test' --recurse-objects --all-tables --skip-tables=wp_*users
  15. If you don’t already have a functional user for the site, you can add one using WP CLI, again via Vagrant SSH in the example directory of /srv/www/vipgo/public_html/:
    wp user create bobross happy@little.trees --role=administrator
    wp super-admin add bobross

    Make sure you record the password printed to the console so you can successfully login.

  16. In order to use VVV certificates and avoid security warnings, you need to add the certificate authority as a Trusted Root CA. You can find instructions to update your host system here. On Windows 10, this is done from a command prompt on the host using the following command:
    certutil -enterprise -f -v -AddStore "Root" "certificates/ca/ca.crt"
  17. For Windows 10 users hosting on VirtualBox and needing to cross-browser test in Microsoft Edge, there is currently an issue with connecting to the VirtualBox Host Adapter. You can disable this by modifying the *NdisDeviceType registry key of the adapter, and setting the value to 0 from 1. You need to identify the correct adapter, referenced in the following path by {adpater_id}:

    Reboot after changing this setting, make sure you vagrant up, then test. Do this at your own risk.


Thanks to Ryan Leeson of Trellist for the work in putting this guide together.

Restricting access via an IP Allow List

Using the IP Allow List you can limit access to each application environment to a specified list of IP addresses or ranges of IP addresses (aka subnets). Once you have applied the IP Allow List to an environment, any and all requests from an IP address list outside of the allowed list or range will be denied.

The IP Allow List applies to all requests:

  • Requests from logged in and anonymous users
  • Requests for files
  • Requests for a WordPress or Node application
  • Cached and uncached requests

The only exception is services within Automattic’s networks, as these will need access to support the operation of your application.

You control the IP Allow List separately for each environment of your application, e.g. the production environment has a separately controlled IP Allow List to the develop environment.

Viewing and controlling your IP Allow List

The IP Allow List for an environment is controlled from your VIP Dashboard. Anyone with access to the VIP Dashboard for your application can view the IP Allow List. Only users with write or admin roles on the GitHub repository for your application are authorized to add and remove IP addresses and ranges for your application environments. The UI for the IP Allow List is shown below:

IP allow list UI

To view the IP Allow List:

  1. Visit the VIP Dashboard
  2. Select the application from the list of applications that you have access to
  3. From the left hand menu for that application, choose “Settings”
  4. At the top of the “Settings” screen choose the environment you want to configure, e.g. “Production”, “Develop”, etc
  5. From the “IP Allow List” section, choose “Configure”

If your IP Allow List is configured, you will be able to see the details here.

If your IP Allow List isn’t configured, you will see a notice saying “No IP addresses have been added. Your site is accessible to everyone.

To add an IP or subnet (aka CIDR range, aka IP range) select the round “+” button top right and follow the directions. Adding the first IP address will immediately deny access from all other IP addresses. You can add a list of IP addresses separated by commas.

To remove an IP or subnet, select the “trash” (delete) icon to the right of the IP or subnet. Removing the last IP or subnet will make the environment accessible from anywhere on the internet.


  • Changes will take up to five minutes to take effect
  • A 403 Forbidden error is what you’ll get when trying to visit your app from an IP not on the IP Allow List
  • Amending the IP Allow List logs an event in our internal audit log

VIP Go IP Ranges

In some situations, it might be necessary to allow requests from your VIP Go environment to interact with private resources. For example, you may need to allow requests from your VIP Go site to an internal tool that’s behind a firewall.

We provide publicly accessible IP ranges for our origin data centers for these situations.

The IP range for each data center can be found at this endpoint:

Adding the provided IP range for a given data center will allow your site to communicate with a restricted platform/resource.

Precautions Around IP Range Updates

VIP Go IP ranges are subject to change at any time, and we do not provide advance warning of IP range updates.

For this reason, we recommend building your application in such a way that unexpected IP range updates are non-breaking either because the ranges aren’t required for vital site functionality, a fallback method is provided, or some other strategy.

There are a few mechanisms to monitor updates to the published ranges:

  • The serial JSON field within the response contains an epoch timestamp of the last change,
  • The updatedAt JSON field within the response contains an ISO 8601 timestamp of the last change,
  • HTTP response of requests made with the If-Modified-Since header. If the last modification date/time is newer than the value provided in the If-Modified-Since request header, the response will be HTTP 200 OK. Otherwise, the response will be HTTP 304 Not Modified.

Managing User Access

We encourage all VIP clients to manage user access to their websites and GitHub repositories. It’s best to designate primary administrators who will be in charge of adding and removing users. We recommend at least one primary administrator for each client, two would be even better in case one of them is unavailable. Primary administrators should feel empowered to add additional administrators as they see fit while following best practices.

Managing GitHub Access

A collaborator with admin privileges in your GitHub repository will be able to add or remove additional collaborators. Access to GitHub also authenticates access to the VIP Dashboard. Find instructions in GitHub’s Documentation. There are a few points to keep in mind when deciding on permissions for collaborators:

  • Please only add users with read or write permissions as required. Users who would need write access include those who will be committing code to the repository.
  • Admin collaborators can force push (which is blocked in VIP Go environments) after removing restrictions. If they do this, they should restore restrictions afterwards.
  • Please review the full description of every permission level in GitHub’s documentation.

Add a User to Your VIP Go Site

As an Administrator, you are able to add users to your website through wp-admin (also known as the WordPress Dashboard). Add users to your site using the default WordPress user roles, or customized roles unique to your business needs:

  1. Log into your VIP Go site to access wp-admin.
  2. From the sidebar, click on Users.
  3. Next click the Add New button to add a new user to your site.
  4. Fill out the form and select the role that your user should be assigned.
    • Check the Send User Notification option if you want the user to receive an email with a password-set link. If you do not select this option, the user will need to access the login URL ( and use the password reset feature to generate a password.
  5. That’s it! You did it!

Add a User to Your VIP Go Multisite

In a multisite, user management is done at the network (top) level. Only a Super Admin can add users to the network. Once users are added at the network level, Administrators for individual subsites can then add any of these existing users as required.

If you’d like to add a user to your VIP Go multisite as a Super Admin, follow the steps outlined here:

  1. Log into your VIP Go multisite to access wp-admin.
  2. In the admin bar, at the top, hover over My Sites > Network Admin > Users and then click on Users. Adding a user to a multisite through network admin
  3. Next, click the Add New button to add a new user to your site.
  4. Fill out the form. Note this will only prompt you for a username and email address. A password reset link will be sent to the user via email by default.
  5. Now that you’ve added the user, you will be able to edit the user profile. Click Edit user at the top of the screen. (You can also go back to the Users list in Network Admin and hover over the user.)
  6. Check the box that says Grant this user super admin privileges for the Network.
  7. Scroll down to the end of this page and click Update User. Now the user has Super Admin privileges for the entire multisite.
  8. Note, if you ever need to delete this user, you must first remove the Super Admin privileges. To do that, go into the user’s profile, unselect the super admin privileges option, and then update.

X-hacker and X-Powered-By HTTP Headers

By default, VIP adds two custom HTTP response headers to every application we host. These headers help us monitor our platform and can be useful when troubleshooting the origin of a request, but if required they can be removed.

HTTP headers are not visible when viewing web pages in a browser, neither are they visible when viewing the HTML source for a web page. HTTP headers are part of the HTTP protocol used to request web pages and request responses from API endpoints, and also to send the response, e.g. the web page or the API response.

HTTP headers added by our platform, along with all other request and response headers, can be inspected by savvy users using specific tools, e.g. cURL. Here is an example of the X-hacker and X-Powered-By HTTP headers added by our platform:

X-hacker: If you’re reading this, you should visit and apply to join the fun, mention this header.
X-Powered-By: WordPress VIP <>

How to change or remove the headers

To alter the headers, use the wp_headers filter to unset or modify them as desired. The source code contains the latest header keys and can be used as a reference.

The following snippet can be used to remove the X-hacker header:

add_filter( 'wp_headers', function( $headers ) {
    if ( isset( $headers['X-hacker'] ) ) {
        unset( $headers['X-hacker'] );
    return $headers;
}, 999 );

To change the value of a header, replace the value with a new one. For example:

add_filter( 'wp_headers', function( $headers ) {
   $headers['X-hacker'] = 'Follow the white rabbit over to to join our team.';
   $headers['X-Powered-By'] = 'WordPress VIP, an Automattic Production.';
    return $headers;
}, 999 );

These two snippets can also be mixed and matched as needed.

Launch day playbook

This playbook outlines the considerations, from VIP’s experience, to ensure a smooth and successful launch. The points below are a guide only, and the VIP team will advise on the specifics of each launch, including whether you are able to use our self-site launch process.


After the project has been kicked off with VIP, we schedule launches as outlined below:

  • VIP requires that all launches are scheduled at least 5 business days in advance.
  • The supported VIP site launch hours are Monday to Thursday, 9:00 am – 8:00 pm (09:00 – 20:00) UTC. Launching during this time provides the most support coverage to help ensure any issues you may encounter during the launch can be discovered and fixed as quickly as possible. If a launch is requested outside these hours, we require a minimum of 10 business days’ notice to arrange for appropriate resources. Please keep in mind that an alternative date and time may need to be arranged, based on availability and the complexity of the launch.
  • If a launch needs to be rescheduled, the same notice period applies for the rescheduled date. For example, if a launch that was booked for tomorrow needs to be rescheduled, it will need to move at least 5 business days in the future.

Launch steps

  • At the scheduled time and date, everyone will join a StormChat (a single-use live text chat room).
  • VIP will be expecting to update the site to the production domain at that time, with the goal of having the site live within a specified time period (typically, 30 minutes – 1 hour).
  • For a typical launch, the site’s primary domain will be set, followed by QA and then switching DNS.
  • If the site is not live by the end of that time period, we recommend rescheduling the launch and addressing any outstanding issues via Zendesk support tickets.
  • If more extensive QA is required, VIP may recommend that the site’s primary domain is set at a scheduled time, with the change being notified in Zendesk. Then, all parties will convene on a StormChat for the DNS switch. There is also the option to use Maintenance Mode or another form of access restriction if a soft-launch is desired.

Expected launch duration

  • Additional complexities such as those listed below can be expected to add time to the launch:
  • When planning the launch, a TAM will outline the specific launch steps and expected duration.

Pre-launch checklist

  • A site needs to be free of issues and performing well at least 2 business days before the scheduled launch. If there are outstanding issues, or bugs are still being worked on, within 2 business days before the launch, VIP will need to reschedule the launch.
  • If a final database and/or media import is required before the launch, it should be performed at least 1 business day before the launch steps are performed. If a 1-business-day editorial freeze is not possible, and double-posting new content is not possible, please work with your TAM to schedule an import closer to your launch time.
  • One week prior to launch, the DNS records’ TTL (Time To Live) should be lowered as far as possible.

Node.js Applications on VIP Go

Important Note

Hosting for Node.js applications is currently only available for customers with an existing arrangement for this facility.

The VIP Platform has first-class support for hosting Node.js (Node) applications.

Types of Applications

We currently support two types of Node.js applications on VIP.

Decoupled / Headless Frontend

The REST API allows WordPress to operate in a decoupled / headless manner. Rather than a traditional PHP-driven theme, sites can be run as a static single-page application (SPA) or a fully isomorphic application (with server-side rendering).

(Companion) Microservices

WordPress is flexible enough to support many different use cases, but not all of them. A companion microservice can be used to offload tasks that may not be well-suited for a typical WordPress app, such as a proxy for another API or service or a middleware layer like a GraphQL API.

Preparing your Application


For your Node.js application to work on the VIP Platform, it must adhere to the following requirements.

You can automate these checks as part of your CI process by running the following command on the application root directory:

npx @automattic/vip-go-preflight-checks

Note: Node 10 and npm 5.2 or higher are required for the preflight checks package.

Use the @automattic/vip-go package

Our helper package simplifies some of the boilerplate and makes it easier to integrate with platform features like logging. It currently handles the following:

  • Starts an HTTP server listening on process.env.PORT, which is dynamically assigned to each container.
  • Responds to GET /cache-healthcheck? with a 200 status code, which is used by our monitoring systems to verify the health of your application.
  • It also includes helpers for logging and integrating New Relic and Redis.
Use a CI Service

If your application requires any build processes like transpiling, compiling, etc. you must use a CI service (like CircleCI or GitHub Actions) to generate a built copy of the application.

The service should transpile, compile, and verify a build of your app and then push that to a “built” branch. Learn more about setting up Automated Build & Deploy.

Included npm scripts

On VIP Go, every time you push a new change to your application, we pull the latest code from the deployment branch and then run the commands below. Your application must respond with a non-error exit code.

  • npm install --production
    • This is triggered to install any production dependencies needed for the app.
    • All required production dependencies must added to package.json, including any packages that were not included in the built copy. Note that devDependencies are not installed.
  • npm run build
    • This is triggered to run any final build steps.
    • Any additional build steps that were not completed via CI should happen here.  If your app doesn’t need an additional build step, feel free to just echo something (e.g. echo "No build needed; skipping...")
  • npm start
    • This is triggered to boot up the app.
    • This should boot up the HTTP server.

If any of these commands are missing or fail, the application will not work correctly.

Stateless and Multi-container

All applications on VIP Go must be able to run across multiple containers and processes at the same time.

This means that the app must largely be stateless. If any data is stored in memory it will be lost on deploy or if containers are added/removed. If data needs to be shared across containers/processes or you need guaranteed persistence, you can use a data store like MariaDB or Redis, which we can enable for your app.

No Process Monitors

For production deployment, your application does not need any process monitors (like nodemon, PM2) to handle restarts. This is handled automatically by the VIP platform.


We also recommend following these best practices:

  • Keep the “dependencies” list small and lean.
    • Node.js containers will run npm install --production every time the app is deployed or a new container is added. This can take a significant amount of time if you’re using a large number of dependencies and slow down deployment time as a result.
  • Use npm audit or a service like Renovate or Dependabot to automatically keep your dependencies up-to-date, especially for security updates.

Creating your Application

A member of the VIP team will work with you to get your application up-and-running in our environment.

You’ll want to make sure that your application is set up according to the Requirements and Recommendations noted above.

We’ll also need the following details:

  • Domain name.
  • GitHub users.
  • The version of Node.js you’re hoping to use.
    • We currently support 10.x and 12.x
  • Any environment variables that should be added.
  • Any data stores you’ll need alongside the application.
    • We currently support MariaDB and Redis.

More about your Node.js Application


For logs generated by the application, the @automattic/vip-go package provides a wrapper around Winston, a popular logging library. Using this library will ensure that logs are accessible by the VIP team which will allow us to better support your team in case of issues (and will be directly accessible to your team in the near future). If you’d like to log to your logging system of choice, Winston has adapters for many popular logging services and APIs such as Sentry.

Two-factor Authentication on VIP Go

Two-factor authentication (also known as multi-factor authentication and 2fa) is a method of securing accounts which requires a user to know something (e.g. a password) but also that you possess something (e.g. your mobile device). This method of requiring multiple forms of verification is an easy to way to protect your sites against common account breaches due to leaked or guessed passwords. Two-factor authentication is integrated with all WordPress sites on the VIP Platform and easy to use and enforce.

Enabling Two-Factor Authentication

If you have a WordPress account, to enable Two-factor authentication, just visit Users > Your Profile and enable your preferred authentication methods in the Two-Factor Options section.

Enforcing Two-factor Authentication

Two-factor authentication is required on VIP Go for all administrators and custom roles with the manage_options capability. If you’d like to force two factor authentication for other roles, you can use the wpcom_vip_is_two_factor_forced filter. For example, to enable for all users that can edit posts:

add_action( 'set_current_user', function() { 
    $limited = current_user_can( 'edit_posts' );
    add_filter( 'wpcom_vip_is_two_factor_forced', function() use ( $limited ) {
        return $limited;
    }, PHP_INT_MAX );
} );

Or, to enable for all users on the site:

add_filter( 'wpcom_vip_is_two_factor_forced', '__return_true' );

Disable Two-factor Authentication Enforcement

If you’re using an external auth provider that already enforces two-factor authentication, you can choose disable enforcement for users on the site. You can add this to a file inside your client-mu-plugins folder. (Note that with this snippet, the built-in two factor options will still be available to users).

add_filter( 'wpcom_vip_is_two_factor_forced', '__return_false' );

If you’d like to remove the built-in Two-factor options completely, you can add the following snippet to a file inside your client-mu-plugins folder:

add_filter( 'wpcom_vip_enable_two_factor', '__return_false' );

Note: These filters will not work properly if placed in the theme.

Resetting Two-Factor Authentication for Locked Out Users

There are two primary methods available for both admin and super admin user roles to disable two-factor authentication for users that are locked out of their account.

Prior to disabling two-factor authentication, we highly recommend confirming that the user has indeed lost access to their account. Since emails can be faked, we recommend confirming with the individual in person or over the phone.

To disable two-factor authentication, you can do either of the following from the Dashboard under Users > Edit > Two-Factor Options:

  • Deselect all available two-factor methods. This will allow the user to login without needing any additional code.
  • Enable the Backup Codes option. Then, you can send a backup code to the user that they can use to login to their account.

Once the user regains access to the account, they can adjust any two-factor settings to prevent losing access moving forward (reset phone number, for example). We also recommend having them print out backup codes to prevent future lockouts.

The VIP Cache Personalization API

The VIP Cache Personalization API provides an easy way to customize the caching behavior of the VIP CDN, allowing personalization and segmentation of your audience without sacrificing stability and performance. The VIP CDN is a global network of servers owned and managed by VIP, and amongst other services, it provides caching for the VIP Platform.

What is Cache Personalization?

Web development is often about balances and compromises. When it comes to serving dynamic content within a CMS, there are two ends of the spectrum:

  1. Generate each page every time a user request comes. This is great for ensuring the user always has the most up-to-date copy but comes with a performance penalty as the code and database calls run each time.
  2. Generate a page once and then cache the content for future requests. This option offers fantastic performance but comes with the challenge of requests potentially displaying outdated content until it is regenerated manually or automatically

The VIP Platform has been designed to handle both. However, to achieve the high levels of scaling and performance that many applications expect, caching is essential. By serving the same cached content to as many users as possible, we can deliver on the promise of a platform that scales with your needs.

The default VIP CDN configuration works for most cases, but is insufficient when more control of the caching behavior is required (for example, serving different content to different groups of users). The VIP Cache Personalization API can help with that. It provides an easy way to customize the caching behavior of the VIP CDN while still leveraging the power and scale that it provides.

When should you use it?

Some common uses for the VIP Cache Personalization API include:

  • Tailoring content to the user’s location
  • Displaying different website features to a select group (e.g. Beta site)
  • A/B testing
  • Gating content until users opt-in (e.g. Accepting Terms and Conditions)
  • Content paywalls
  • Membership sites using custom authentication systems
  • 3rd party integrations that require uncached content/resources

How does it work?

We provide a variety of ways to segment your content at the edge, serving different audience segments different content from different “cache buckets”. This is achieved through the Cache Personalization API. The API includes three implementations that can be taken depending on use case:

Audience Segmentation

This is useful when you want to serve different cached content to different constituencies in your audience.The API provides an easy way to create a new cache group and assign users to specific segments within that group.

For example, if we were introducing new Beta features for our site and wanted to allow users to opt-in to those features, we would create a new group called “beta” with two user segments within that: users that have opted into the beta and users that have not.

You can define as many groups as you want and users can belong to multiple groups and segments as well. It’s important to note that the higher the number of groups, the higher the variance in caching responses, which can result in decreased cache efficacy and performance. As such, the API should be used with care.

At a technical level, when a user is assigned to an audience segment, the API sets a cookie defining the group or groups the user is part of.

Encrypted Audience Segmentation

Encrypted audience segmentation is similar to “audience segmentation”, but ensures that it is not possible for even for a very savvy technical user to assign themselves to change the segments they have been assigned to. Typical use cases for this are paywalls, authenticated content, and any other situations where you want to cache content based on encrypted credentials not visible to the user.

At a technical level, the cookie defining the group or groups the user is part of contains an encrypted string which cannot be read or altered by the user without scrambling the content.

Please note that encrypted audience segmentation requires activation by the VIP team; get in touch if you’d like to learn more or get started using this feature.

Cache Bypass (i.e. Disable Caching)

This gives you the ability to turn off all caching for a given visitor. This is useful for 3rd party services that consume data or content from your application and require uncached data. It’s also applicable when working with external authentication system. Learn more about the implementation.

Please note that disabling caching can have detrimental effects on the performance of your site. We’d be happy to help validate and verify your use cases before you implement them; please reach out if that’s of interest.

How do you use it?

We’ve put together some useful tutorials and examples that walk through how to implement various uses cases using the API.

If you have have any questions about the API or how to make it work with of one of your use cases, please get in touch and we’d be happy to help.

Testing your site

When you test your site, we recommend you run all tests on your production environment. Walk through your site using all the functionality of your dashboard, including plugins that you and your team will use on a regular basis. This could include creating test posts and widgets.

In addition to testing backend functionality, you’ll want to look at the frontend to ensure it functions as expected. If anything appears broken or is not working as expected, you might want to take a deeper look at your output and see which errors or warnings need to be addressed.

At a minimum, we recommend the following  tests:

  • Create a post as a user with the “editor” role
  • Create a post as a user with the “author” role
  • Upload an image to the media library
  • Edit a post
  • Delete a post
  • Create a new user
  • Delete a user
  • Change a user’s role
  • Add a widget
  • Modify a widget
  • Verify settings are correct for external services like Google Analytics, Twitter, Facebook, etc.
  • Any features of your editorial workflow that rely on plugins or theme functionality
  • 301 redirects, if any, still work

Single Sign On

Single Sign On (SSO, not to be confused with Jetpack SSO) is possible for clients using any identity provider (IdP) that supports SAML (or Security Assertion Markup Language). We do not support other SSO technologies at this time. We also cannot install any middleware required in some Shibboleth configurations. Most IdPs can support SAML.

Setting up the Identity provider(IdP)

SAML IdP’s require you to register the VIP Go application as a service provider. They have different ways of approaching this but the purpose is to:

  • Set up the application as a legitimate service provider.
  • Tell the IdP where and how to communicate with your VIP Go application.
  • Generate the certificate and URLs the IdP will use to send and encrypt communication with the VIP Go application.

Most IdPs have an application creation here’s the documentation for creating custom applications on major IdPs:

You will need:

  • The ACS location, usually (where is your domain)
  • The entity-id: php-saml

Once you create your SAML application, the IdP will provide the following:

  • Entity ID (a unique URL)
  • Single Sign-on URL
  • X.509 Certificate to setup WordPress.

Setting up WordPress

In order for our team to continue to provide support for your application, we have the following requirements:

  • You must configure your SSO plugin to create local user accounts
  • If you force SSO for all users, you must provide a way for support users to circumvent the SSO flow on login
  • If you force SSO on all pages of the site, you must expose the XML-RPC endpoints to Jetpack requests.

To allow users to circumvent the SSO flow, the easiest way is to provide a url parameter like wp-login.php?normal that directs users to the wp-login form. A more secure way is to detect if a user is accessing the site through VIP’s proxy servers.

Use one of these plugins:

  • OneLogin’s WordPress SAML
  • Human Made’s WordPress Simple SAML

Onelogin’s WordPress SAML plugin

OneLogin’s WordPress SAML plugin works with any IdP and is managed through a settings page where you can fully configure your application. If you’re using this plugin, make sure you also have our helper plugin installed to your client-mu-plugins directory which takes care of some of the required details above and also ensuring cookies and other SSO settings pass through our cache layers.

Options and Settings

You can mostly choose how to configure your own SSO. Some settings may be dictated by your IdP. If you’re doing a lot of custom configuration, we highly recommend you thoroughly test your SSO setup on your VIP Go application before launch.

Here are our recommended settings (these are under the “Options” heading of the OneLogin plugin):

  • Create user if not exists: This causes WordPress to create local accounts for users that sign in over SSO. Required
  • Update user data: This causes user attributes like first name, last name, and email address to change on WordPress when they change in your IdP. Recommended
  • Single Log Out: only useful if the client’s IdP supports it. Not recommended
  • Alternative ACS Endpoint: Not supported
  • Match WordPress account by: You can choose how to match your users to their IdP accounts.

There are many additional options and settings. For the most part, you shouldn’t need to change these unless your IdP requires it.

WordPress Simple SAML plugin

Human Made’s WordPress Simple SAML plugin also works with any IdP but stores the SAML configuration in code and facilitates SAML without extra settings screens. Because of how Human Made approached this and how our platform works, we require some extra code in your theme’s functions.php file. If you need help generating this code, reach out, and we’ll provide the code for use with this plugin. The helper code handles configuring the IdP and mapping your roles. Your developers will want to take a close look at this before launch. Loading the SAML configuration from an XML file provided by your IdP is currently not supported on VIP Go.

Notes on role mapping

Sometimes the role sent by an IdP doesn’t match a role in the WordPress install. If this is the case, you have three options for resolving the mismatch. Any users without a matching role will be assigned the default, usually “Subscriber.”

  • Create roles in your WordPress application that match your IdP.
  • Create roles in your IdP that match roles in WordPress.
  • Map your IdP’s roles to existing roles in WordPress. You do not need to map every role, and more than one role can be mapped to a given WordPress role.

Preventing unauthenticated site access with SSO

The only way to make a VIP Go site “private” is by requiring SSO authentication to access any page on your entire site. To do this, use the OneLogin plugin and enable the “Force SAML Login” option. You must still provide a method for VIP Support to circumvent SSO to access the site.

Requiring SSO to login

We require the creation of local accounts on the WordPress install so that we can more easily troubleshoot when users are having problems. This doesn’t prevent the client from requiring SSO to log in. If the client requires SSO for all logins from their users, enable the following options in the OneLogin plugin’s settings:

  • Prevent reset password: This will prevent users from resetting their WordPress account passwords.
  • Prevent change password: This will prevent users from changing their WordPress password.
  • Prevent change mail: This will prevent users from changing the email address in their WordPress account profile.

Exceptions for VIP Support

  • VIP Support must have a way to login, bypassing SSO. One way this can be implemented is by checking for requests from the Automattic network, as described here.

QA Recommendations

We have a few recommendations for clients to test their SSO configuration before launch.

Check users

  • Create test users within the IdP, create one for each role that mapped to WordPress to make sure users have the right role when they sign in.
  • Test any known role conflicts to make sure they are resolved as you expected.
  • Test whether users can successfully log in and out without affecting other SSO sessions in their organization

Test content protections

  • If the entire site requires authentication, make sure clients verify by anonymously access the site
  • Make sure all login requests go through the single sign-on process.

Retiring sites from VIP Go

When you wish to retire a site from VIP Go, we ask that you notify the VIP team via a support ticket 30 days in advance of the site retirement date. At the end of this period, we will normally retire the site(s) along with the non-production environment(s) and update your account’s billing details as per our agreement.

In the case of selective retirement of subsites within a Multisite, we will delete/archive the requested sites and production monitoring for these subsites sites will be disabled.

In order to archive or migrate the site to other hosting, you will need several elements, and we cover these below.

Codebase / GitHub repository

You may wish to first read  about the structure of your VIP Go codebase.

If the GitHub repository will no longer be used by an active VIP Go site, once the site(s) have been retired, the associated GitHub repository will be removed as well so please ensure you have a local copy of the repository saved. You can either download a copy of the code in your VIP Go repository as it is, clone a copy of the Git repository, to retain the version history and all changes, or we can transfer the repository to your GitHub account, to retain all version history, GitHub issues, GitHub pages, etc.

Download a copy of your codebase

  1. Navigate to your VIP Go repository on GitHub
  2. Select “Clone or Download” from the front page of your repository
  3. Select “Download ZIP”
  4. Check the contents, and save the file

Clone your repository

GitHub maintains documentation on cloning a GitHub repository.

Transfer a repository

If you would like to transfer your VIP Go repository to your GitHub account, please contact us; read more about repository transfers.

Files and data

If you would like an archive of all files that have been uploaded to your site, please contact us. The archive will be supplied with the same directory structure as the file uploads. The data will be supplied as SQL from the mysqldump client.

The VIP code analysis bot

When you create a Pull Request (PR) on a VIP client site repository in the VIP GitHub organization (, you may see a review from our automated VIP Code Analysis bot. The bot’s GitHub username is wpcomvip-vipgoci-bot, and you can see their GitHub user account.

What does the bot do?

The bot runs PHP_CodeSniffer (PHPCS) with the WordPress-VIP-Go standards, the PHP linter, and also checks SVG files.

The PHP linter will highlight code syntax and compilation errors. These are usually fatal and so need to be addressed before the code is deployed.

PHPCS is a tool that will help you write VIP approved code by ensuring it meets VIP coding standards. The rules are designed to identify where code will not work, and to help you follow VIP best practices for writing secure, performant, and future-friendly code. We recommend you install the PHPCS and the standards locally by following the documentation here, and this will give you even more immediate feedback as you develop.

The bot works by adding a GitHub PR review (or reviews) detailing the feedback based on our standard. A review with no issues will show no interaction from the bot, whereas if the bot finds either PHPCS or PHP linting errors the bot will comment on and review the PR:

What should I do about the bot feedback?

You should review the feedback from the bot, and decide how to act on it. You have several choices for each item of feedback:

  • Address the feedback by amending your code
  • Choose to ignore the feedback, and add code comments to instruct the bot to ignore the issue (see below)
  • Dismiss the review issue via the GitHub PR interface

Many issues will be correct and should be addressed, but as with all automated feedback there will be some wrongly flagged issues that it is safe to ignore (false positives). There may also be some issues that the bot feedback misses (false negatives). We aim to reduce false positives and false negatives over time, please feel free to open a ticket if you find such and we’ll be happy to discuss.

If you have any concerns about a review added by this bot, please open a ticket and we’ll be happy to help.

Code comments to ignore PHPCS feedback

You can configure the bot to ignore certain parts of a file when running PHPCS as described in “Ignoring Parts of a File” from the PHPCS documentation. Here’s an example:

// Ignore a single line:
$xmlPackage = new XMLPackage; // phpcs:ignore WordPress.NamingConventions.ValidVariableName.VariableNotSnakeCase -- reasons

// Disable the a check for multiple lines, and then enable all checks at the end:
// phpcs:disable WordPress.NamingConventions.ValidVariableName.VariableNotSnakeCase -- reasons
$xmlPackage['error_code'] = get_default_error_code_value();
// phpcs:enable

Read the PHPCS documentation for other methods to have the scanner ignore portions of a file or whole files.

Modifying the bot’s behavior

You can change the bot’s behavior by placing a configuration file named .vipgoci_options at the root of the relevant repository. This file must contain a valid JSON string for this to work; if the file is not parsable, it will be ignored. This file is where you can add code to turn off support messages as well as adjust PHPCS severity levels.

Turning support messages off

By default, the bot will post a support message to new PRs explaining what it does as well as what to expect next. This message can be turned off. (See the example in the next section.)

Adjusting PHPCS Severity

You can increase or decrease the number of warnings and errors generated by the bot by adjusting its PHPCS severity level.

By default, the bot runs at severity=1.

To turn off support comments and adjust the PHPCS severity level, use the following JSON snippet in your .vipgoci_options file:


Please note, while you can configure either parameter, you do not need to configure both. We recommend that you only configure the option that you need to configure. We also recommend that you only configure the PHPCS severity level if you understand how to use that PHPCS option and understand the implications of its use.

Skipping PHPCS scanning for specific Pull Requests

By default the bot will scan any new PRs with PHPCS and PHP Lint. However, in some cases you might not want it to scan the PHP code with PHPCS. To accomplish this, add a label to the relevant PR simply named skip-phpcs-scan without any extra strings or content. Only use this label if you do not want the code to be reviewed by the bot.

Skipping PHPCS scanning for specific folders

By default the bot will scan any relevant files found in PRs using PHPCS and PHP Lint. For PHPCS, both JavaScript and PHP files are scanned for issues, while for PHP Linting only PHP files are scanned for syntax errors. In some cases this can result in files being scanned that should not, such as unit-tests with deliberative syntax errors.

You can add files to the root of the repository indicating folders that should not be scanned. For PHPCS, the file should be named .vipgoci_phpcs_skip_folders. For PHP Linting the file should be named .vipgoci_lint_skip_folders. Please ensure both files are located in the root of the repository.

List each folder to be skipped on individual lines within those files. For example, to skip PHP Linting, you would list folders in the file named .vipgoci_lint_skip_folders like so:


With these two paths in the .vipgoci_lint_skip_folders file, no PHP files in those folders will be checked for syntax errors. The usage is analogous with PHPCS. Note that regular expressions are not supported at this time.

We encourage you to use this feature sparingly. We view the checks as a safety mechanism that can save your sites from serious errors.

GitHub API communication error

Occasionally the bot will post a message to PRs saying that there has been a GitHub API communication error and that a human should be contacted. This happens when the bot has a problem communicating with the GitHub API, and in most cases this is due to problems with the GitHub API itself. The message usually disappears when the PR is scanned again, which occurs when new commits are pushed to the PR.

If the problem persists, first check if there are any issues with the GitHub API (see here). If all systems appear operational, and the problem persists, please open a support ticket with us and we will investigate.

Interpreting your PHPCS report

When a codebase is ready for automated scanning, the repository is checked by PHPCS scan using the WordPress-VIP-Go standard.  The initial scan will include a report that categorizes the scan’s results based on the severity of the errors and warnings the scan found.

Errors with severity level 6 and above

An ERROR with severity level 6 through 10 may indicates code that may not function on VIP Go. This could be due to:

While some may be false positives, not addressing the valid ones in this category will likely result in a loss of functionality.

We don’t recommend fixing these errors found in third-party code like plugins and themes. Instead, consider looking for an alternative that provides the same functionality. If there isn’t an alternative that meets your needs, consider whether you truly need the code and thoroughly test its functionality if you do.

Errors at severity level 5

Code that triggers an ERROR with severity level 5 may have issues such as (but not limited to):

Especially with escaping errors, there may be false positives. The only way to know for sure is by inspecting these lines further. Errors at this level expose the site to security and performance problems.

Warnings at severity 6 and above

Code that triggers a WARNING with severity level 6 through 10 may expose the site to performance and security problems. This includes (but not limited to):

  • Custom Database Tables
  • Using $wpdb directly
  • Using wp_mail()
  • User provided data not properly sanitized

Warnings at severity 6 and above are addressed to prevent poor performance and security vulnerabilities.

Warnings at severity level 5

Code that triggers a WARNING with severity level 5 may cause problems in certain circumstances, such as high traffic events. This warning level includes issues such as (but not limited to):

  • Uncached functions
  • Functions with poor performance
  • Database queries with poor performance
  • Using strip_tags instead of wp_kses

VIP recommends that warnings at severity level 5 are addressed.

Warnings at severity level 4 and under

WARNINGs with severity level 4 through 1 are triggered when the code is not adhering to VIP’s recommended best practices. This includes issues such as:

  • Including files without a full path
  • Using loose comparisons
  • Having an undefined variable
  • Not enqueuing scripts

These warnings will be included in the report. Addressing them will help keep the code base clean and prevent unexpected bugs or side effects.

VIP Go glossary

  • Application: the application is delivered by your software codebase, you might also refer to this as the “website”, or “site”
  • Environment: your application can run in a variety of environments, eg: production or develop (or “local development”)
  • Environment ID: the ID number assigned to an environment, this can be discovered using the VIP CLI tool

How code is deployed on VIP

Each production environment tracks the master branch of a GitHub repository (access to this repository will be provided after the kickoff call). Child environments track different branches of the repository and auto-deploy.

Each site repository utilizes a webhook on GitHub that is triggered by pushing code to a branch. The GitHub webhook notifies the VIP Platform that new code should be deployed, the VIP Platform determines which applications and environments the code should be deployed to (if any). The VIP Platform then updates the code available to each affected environment. The deployment process generally takes less than 10 seconds from code push to completed deployment.

Deployments and code review

The master branch will auto-deploy to the environment until the initial code review is complete. After that point, deployments to master will follow the GitHub Pull Request workflow.

For sites not receiving manual code review, the master branch will always auto-deploy to the environment. VIP recommends always following a PR workflow to enable the VIP code analysis bot to provide automated feedback.

Automated build and deploy process

VIP’s automated build and deploy process can automatically transpile/concatenate/minify/optimize your JavaScript, CSS, and static assets (almost anything except PHP) and deploy it your site, using a Continuous Integration (CI) or Continuous Delivery (CD) service like Travis CI or CircleCI.

This means the working branch can remain clean — with only source files — and the CI/CD service can manage the build and deployment process for you.

Please note that the automated build and deploy process is not available for all clients. If in doubt, please open a ticket with the VIP team for further advice.

Further reading

Multisite on VIP Go

As well as single site WordPress installations on VIP Go, we also support multisite (also known as WordPress Networks). A WordPress multisite allows you to run multiple WordPress sites from the same WordPress installation, using the same set of user accounts. One common use case for a WordPress multisite is to support multiple languages, using the Multilingual Press plugin from Inpsyde, one of our VIP Featured Partner Agencies.

Specifics of how WordPress multisites work are available in the WordPress Codex article on WordPress Networks, but here are some key features:

  • A multisite can use any combination of domains, subdomains, and subdirectories.
  • All subsites share the same database.
  • Several tables are shared by the entire multisite:
    • wp_blogs
    • wp_blog_versions
    • wp_registration_log
    • wp_signups
    • wp_site
    • wp_sitemeta
    • wp_users
    • wp_usermeta
  • In addition, each subsite has its own set of the following tables that, after the first subsite, are prefixed by site ID (e.g. wp_ for tables for site ID 1; wp_2_ for tables for site ID 2; et al):
    • wp_commentmeta
    • wp_comments
    • wp_links
    • wp_options
    • wp_postmeta
    • wp_posts
    • wp_term_relationships
    • wp_term_taxonomy
    • wp_terms
  • While the users table is shared, users can have unique roles (or none at all) on a per-subsite basis.
  • Subsites all deploy from the same repo and the same branch.
  • Plugins and themes can be made available on a per-subsite basis.

There are many advantages to using a WordPress multisite:

  • Themes and plugins need to be updated only once for the entire network, instead of once per site.
  • Editors and administrators who have access to multiple sites can easily navigate between them.
  • Administrators can create new subsites quickly and easily.

Reasons not to use a multisite may include if you have different development teams per site who should not share access to the same repo.

If you have an existing single site and would like it converted to a multisite, please contact support.

VIP support is required to launch a subsite within a multisite. Read our Launch Day Playbook for more information on preparing for and scheduling a launch.

Should I use a subdomain or subdirectory multisite?

Formally, VIP Go supports only subdirectory multisites, but this still allows for all the scenarios you need to cover:

  • A pure subdirectory multisite, with sites addresses like and
  • A site using custom domains, with site addresses like and
  • A site using a mix of both, with site addresses like,, and

To achieve the same effect as a subdomain multisite, you could map a number of custom (sub)domains, e.g.,, etc.

We allow up to two segments in a subdirectory multisite path, so (a “one segment” path) and (a “two segment” path) are supported, but (a “three segment” path) will not work, nor will adding further segments. Configuring a WordPress multisite to allow paths with two segments requires a small amount of code, see below for more details.

Configuring a custom domain, including SSL certificate

Configuring a custom domain requires a few steps, and the site using the custom domain will not be accessible at that domain until all have been completed:

Step 1: VIP support is required to launch a subsite within a multisite. Following the guidelines in the Launch Day Playbook, please open a ticket at least 5 business days in advance to discuss your plans.

Step 2: Add the site in the multisite using a temporary path, then edit the site to change the path to / (or up to a two segment path), and to change the domain to your desired custom domain.

Step 3: If you’re using more than one domain per site, set up your vip-config.php file to handle redirecting secondary domains to the desired primary domain for each subsite. Note that for multisite, redirects between non-www domains and www variants need to be specified in vip-config.php. More on multisite domain mapping.

Step 4: From the VIP Dashboard, map the domain.

Step 5: Configure the DNS to point to your site. See the documentation on Managing Domains and DNS for more details.

Step 6: Install an SSL Certificate.  There are two options:

  • A Let’s Encrypt SSL can be activated directly from the VIP Dashboard as soon as the DNS is pointed to our infrastructure and mapped to your application (see steps 1 & 2 above).  This is the most preferable option, as all updates are automated and your team doesn’t need to worry about renewing the certificate.
  • A custom SSL certificate can be procured, please read the SSL documentation for further information.

Step 7: Following launch, we will activate the Jetpack connection and optionally, VaultPress connection for the new site.

Subdirectory multisites with two segment paths

VIP Go supports a subdirectory site with a single segment path, e.g., with no additional effort.

With a small amount of additional code, VIP Go can support two path segments, e.g. (in this configuration it will support both one and two segment paths, as well as custom domains).

To enable paths with two segments, add the following code to /vip-config/client-sunrise.php:

function my_filter_site_by_path_segments_count( $num_segments ) {
        $num_segments = 3;
        return $num_segments;
add_filter( 'site_by_path_segments_count', 'my_filter_site_by_path_segments_count', 99 );

If you do not need paths with two segments, there is no need to add the above code.

Which subsite should I launch first?

Subsite 1 is the first site in a multisite network and will be listed first in the Network Admin > Sites listing. A non-convenience URL (something other than * must have its DNS pointing to this subsite before any other subsite can launch.

This first subsite can be used for administrative purposes only: it can use a default theme, have no content, and have access restricted by Maintenance Mode. But all new subsites in a multisite network will initially exist as subdirectories of subsite 1’s domain. It can therefore be useful to have a custom domain in subsite 1 for branding purposes, such as or

Data sync considerations

Note that before performing a data sync between multisite environments, a domain mapping file must be created. Further details about data sync on VIP Go.

Plugin access

While plugins are installed via GitHub and are activated at the network level, by default, subsite administrators cannot enable or disable plugins. A network administrator can make this functionality available by checking the appropriate box at the bottom of /wp-admin/network/settings.php.

Enable administration menus: Plugins

Manually logging errors in New Relic

For debugging purposes, you may want to manually log custom errors in PHP code using the trigger_error() function, along with a minimum error level (second argument) of E_USER_WARNING. The default is E_USER_NOTICE.

However, on VIP Go, you have the ability to log custom errors in New Relic using its methods.

The function newrelic_notice_error() is available to log custom errors in New Relic. To trigger an error, you can implement something like the following:

if ( extension_loaded( 'newrelic' ) ) {
	newrelic_notice_error( 'My custom error message' );

The function documentation is available here.

Note: if there are multiple calls to newrelic_notice_error() in a single transaction, the PHP agent will retain the exception from the last call only.

Alternatively, you can use the newrelic_record_custom_event() function to keep track of data and log events without considering it to be an error.

The newrelic_record_custom_event() function documentation explains how to use that.

Tools for VIP development

VIP offers several tools on the platform to assist development and monitoring. Additionally, the VIP team monitors all sites on the platform, and will proactively notify clients about issues.

The VIP dashboard

The VIP dashboard gives clients a window into their sites hosted on VIP. Here, recent repo activity can be viewed, and database syncs can be performed from production environments to child environments. Please note that the database can only be synced from production to child environments, and not the other way around. For this reason, we’d recommend always authoring content in the production environment.


VIP CLI is the command line interface for VIP. It can be used to interact with VIP applications, query information about applications, and perform actions like syncing data from production to development environments.

Query monitor

Query Monitor (QM) is available by default on all production and development sites, and can be enabled for any role via code.

New Relic

New Relic is used to monitor the PHP (WordPress) code and browser performance of sites or applications. Access to New Relic is available at no charge for VIP clients.

Further reading

How to use PHP_CodeSniffer during VIP development

PHP_CodeSniffer (aka PHPCS) is a tool that will help you write VIP approved code by ensuring it meets VIP coding standards. Running this tool in your local development environment or code editor allows you to fix the errors as you code, helping you develop to VIP best practices, and saving time during review.

PHPCS will provide messages with more information about any errors and warnings found in the codebase scanned.

When running PHPCS, ensure that the WordPress-VIP-Go standard is used. This is the standard used by VIP in all code review, including via the code analysis bot running in GitHub repositories.

Further reading

Local development for VIP sites

VIP sites run three codebases: WordPress core (tracking the most current version), the VIP Go mu-plugins, and the codebase from your specific site repo. Because of this, a variety of WordPress local development environments can be suitably configured for VIP Go development purposes.

The local development environment can be configured to replicate a VIP environment, including cloning of the GitHub repository. Please see our documentation (linked below) for step-by-step instructions.

Further reading

Code review

VIP’s priority is to ensure that your site is there when you need it, which means we care about its performance and security. Code review is a key component of ensuring your site is secure and performance.

VIP’s code review focuses on the performance and security considerations in PHP, custom JavaScript, and SVG files. We do not review HTML, CSS, SASS, many popular third-party JavaScript libraries, or built JavaScript files.

When you open a Pull Request (PR) for your codebase in GitHub, we offer both automated scans and manual reviews to our customers.

This process is the same for both your initial codebase review, and for ongoing PR reviews.

  1. Automated scans: When you open a PR in the GitHub, your entire codebase will be automatically scanned against VIP Coding Standards by the VIP Code Analysis bot. If you have questions about how to address specific errors or warnings, you can open a Zendesk ticket with our team.
  2. Manual code review: For clients with Application Support, you may request specific developer feedback on your code (including themes and custom plugins) by adding the “[VIP] Review Request” label to your PR in master. Before adding the label, ensure that you’ve addressed as many errors and warnings from the automated scan as possible. If the changeset is larger than 1000 lines of code, it will need to be scheduled for a review. Where possible, we recommend keeping PRs small by breaking them down into atomic commits. Please allow for 10-15 business days in your project timeline to complete the first and subsequent review cycles.

We also encourage you to run the PHP_CodeSniffer tool in your local development environment or code editor, allowing you to fix errors as you code and develop to VIP best practices.

Further reading

The VIP platform

The VIP platform (also referred to in our documentation as VIP Go) has container-based infrastructure that allows clients to run core WordPress with custom themes and plugins on Automattic’s world-class hardware and network infrastructure.

On our platform, the codebase consists of core WordPress, a handful of platform-specific mu-plugins, and the client’s custom code. Media is served from the VIP Files Service, a globally distributed object store, and sites are cached on the edge with Varnish. VIP looks after hourly platform backups and 24/7 monitoring.

While your site is in development, it will use a convenience URL ending in The production environment tracks the master branch of the connected GitHub repository, which auto-deploys. VIP can also set up child environments for development purposes, which will track a specific branch in the same repo. We also encourage developing locally.

The VIP platform supports both single-site and multisite installations of WordPress.


VIP clients are offered a variety of tools:

  • Jetpack, VaultPress, and Akismet are connected by default to each VIP Go application.
  • Sites are connected to New Relic for application monitoring.
  • VIP clients can take advantage of supercharged search via Jetpack Search, powered by Elasticsearch.
  • Scanning for coding issues on each PR.

Further Reading

Accessing VIP support

Your support team is here to help, every step of the way.


VIP uses the Zendesk ticketing system for helping support clients with technical issues and launch planning.

Support tickets can be opened in one of these ways:

  • Log in to the Zendesk portal (access provided after kickoff call)
  • Submit tickets from “VIP” portal in the wp-admin of your site
  • Use the ? Support button in the lower left-hand corner of the VIP Dashboard
  • Email our support address

Tips for using Zendesk:

  • Keep each issue in its own ticket. This allows our team to effectively route your questions and can help avoid confusion where multiple issues and resolutions are being discussed in one ticket.
  • When you create a ticket, you’ll have the option of four different priority levels: low, normal, high, and urgent. Urgent tickets page the entire support team, so we appreciate that you use them sparingly for true emergencies like outages, time-sensitive security concerns, and workflow-blocking situations where the site isn’t functioning at all.
  • Access your existing tickets in the Zendesk portal.
  • Add additional stakeholders using cc field in the original email, or any subsequent responses.
  • Please follow our guidelines for opening a ticket, to help us reach a timely resolution.

The VIP Lobby

  • The VIP Lobby is the first place we share information with VIP clients from outages to event announcements.
  • To ensure you receive the latest updates, you’ll want to subscribe to new posts. When logged in, you can do this by clicking “Subscribe to Email Updates” or the “Follow” button in the bottom right-hand corner.


Follow posts from the VIP Lobby
Follow posts from the VIP Lobby


Updates about VIP service issues and maintenance are posted on @WPVIPStatus on Twitter.

Further reading

Ready to get started?

Drop us a note.

No matter where you are in the planning process, we’re happy to help, and we’re actual humans here on the other side of the form. 👋 We’re here to discuss your challenges and plans, evaluate your existing resources or a potential partner, or even make some initial recommendations. And, of course, we’re here to help any time you’re in the market for some robust WordPress awesomeness.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.