What to Know When Working with WordPress VIP for the First Time

From the inception of WordPress VIP I’ve wondered what it was like to work on a VIP-hosted project. The hosting platform is notorious for being strict on code and process. On occasion, 3.7 DESIGNS would start a project that seemed like a good fit for the platform, but inevitably the projects would never get off the ground. Last year we finally landed a project that was a good fit for WordPress VIP.

Over the past four months we’ve engaged with the VIP team launching the project into a closed beta a few weeks ago. The fuzzy details of what’s required to host a VIP site are now vivid. I’ve developed better coding habits as a result. As the VIP platform continues to grow (especially with “WordPress VIP Go” rolling out–more on this later) I suspect more developers will be in my position—entering into a VIP project with a vague understanding of how things will unfold.

This post aims to detail both my experience and lessons learned while working with the VIP platform and team. I hope this will help you decide if VIP is a good fit and leaves you better prepared if it is. First, some very general background on the project.

Project Background

The primary driver to use VIP was the need for an outsourced support team. If something went wrong at midnight on Christmas we needed a team that could not only diagnose server-level issues but also jump in and fix code. Our initial plan was to use a handful of out-of-the-box solutions (i.e. existing plugins) to manage complexity and cost. Because we didn’t expect to write a lot of custom code this seemed like a natural fit with the VIP Platform considering their strict coding standards.

The most complex need was BuddyPress, which the VIP team confirmed has run on the platform previously. Additionally, we needed the ability to upload photos to BuddyPress activity, to which there are a few existing plugins. The other project requirements were seemingly small in nature like using third-party JS libraries and a custom theme.

The last important detail was timetable. This project, like many, had a quick turnaround.

Getting Started

Our client had already been in contact with a VIP account manager before we were brought onto the project. Initially the conversation was mostly structured around platform restrictions and pricing for both support and hosting. As I mentioned previously the support was a primary driver behind our need for VIP, which is an additional cost. On top of using the WordPress.com infrastructure you can pay to have access to the expert WordPress developers at VIP. You pay per support seat, which is the ability to open tickets. Project managers can view and respond to tickets, but if you want more than one developer opening tickets you pay per seat.

At this time we learned we’d be one of the initial customers on a new platform called VIP Go. VIP Go offers many of the same benefits as VIP but isn’t hosted on the same infrastructure as WordPress.com. This allows more flexibility, for example non-standard database tables are allowed if done properly, something that was a universal “no” on the standard WordPress VIP platform.

We had three or four calls confirming that everything fit the project requirements and going over the VIP development process.

The Process

In theory the VIP process is straight forward.

1. You get a VIP staging environment, Git repository, and ZenDesk account.
2. You work on your code until it’s production ready, push it to the repo, and notify VIP you’re ready for review.
3. VIP reviews every line of non-core code in the repository. We were told this process takes four to six weeks on average.
4. Any issues with the code are raised on GitHub. You push commits against them until none remain.
5. The code is pushed into your production environment.
6. You change your DNS and voilà–you’re online.

Once the site is launched you can push new code to the production environment by committing to the master branch. New commits are reviewed by the VIP team and pushed live if no issues are found. Projects like these rarely go exactly as planned, so our trip to production was not quite so clean.

What Happened

Our two biggest concerns were the code review and timeline. We were in a difficult spot. Using an existing BuddyPress theme and plugins would reduce development time; however, it was hard to say if they’d pass the review process. While the VIP documentation has plugin review and theme review checklists, neither are very long and mostly reference the WordPress Coding Standards. How strict they are on those standards was uncertain. Would they really raise an issue over whitespace usage? (i.e. here_is_my_function( $arg, $arg, $arg ) vs. here_is_my_function($arg,$arg,$arg).)

NOTE: Since publishing it’s been brought to my attention that there is more extensive documentation available, which has been added to the plugin and theme review pages.

So we first questioned “do we build from scratch or customize existing solutions?”

To Build or to Customize? That is the Question.

Initially we decided to use a premium BuddyPress theme by a reputable provider. At first glance the theme appeared close to mockups and had several enhancements we’d already planned, continuous scroll for example. This was a bad idea.

The VIP team audits every. Single. Line. Of. Code. The theme we chose had lots of code. LOTS. Want to move the sidebar to the left, right, top, or bottom? You can do it. Want to integrate with bbPress? No, actually we don’t… too bad! You can do that too. Want to change the colors from blue to orange to green? Yup, all possible.

Not only did the code bloat mean longer review times but it increased the likelihood that VIP would find issues. This led us to the next realization: in the likely event that VIP did find issues we were in a bit of a bind. We could either:

1. Fix the issues ourselves and maintain a forked version of a plugin / theme.
2. Beg the author to fix the issues.
3. Fix the issues and beg the author to adopt the fixes.

After about four weeks into the project and some careful warnings from the VIP team I decided to rebuild the theme from scratch. I spent a weekend doing so using a vanilla install of underscores. Luckily I put most of the custom functionality in a custom plugin and our design was relatively simple. Ultimately this was for the better as we ended up with a lighter, easier-to-manage and use-case specific theme.

The plugins we vetted as best we could, crossed our fingers, and pushed for review.

The Code Review

Everything had issues, including the code output by underscores! The plugins were the worst offenders. The most common problems were related to:

1. Validating, sanitizing and escaping
2. Limitless queries (i.e. ‘posts_per_page’ => -1 )
3. Including unminified versions of JS

Validating, sanitizing, and escaping problems were most prevalent. Most plugin authors use _e() for localization, VIP expects esc_html_e(). Most plugin authors assume that data entered by a site admin is safe, VIP begs to differ (and rightly so). Several plugins failed to validate data as integers, colors, etc…

The custom theme I built was completely lacking in escaping and I did a whole bunch of silly things in my custom plugin like not using nonces. My issues were easily solved, but we had several other plugins that needed fixes as well.

We reached out to the plugin authors and asked if they would roll our fixes into core to which most agreed. We only had to replace one plugin completely due to an unresponsive author and lots (30+?) issues raised.

The whole process took approximately six weeks. When the last issues were closed we updated our DNS and the site was live.

Good Surprises

As predicted there were a few surprises along the way. The first was an issue with avatar uploading and cropping through BuddyPress. Despite VIP’s assurance that BuddyPress had run in a WordPress VIP environment before, the way the filesystem is setup prevented the upload of profile photos.

To solve the problem, WordPress VIP actually paid one of their trusted partners to fix the issue and commit it to the BuddyPress core. Pretty amazing service.

Other Challenges

I always have trouble giving up control, which as of right now you give up on VIP. Shortly after launch we randomly noticed our coming soon page was the White Screen of Death. In trying to solve the issue we identified a few problems:

1. We didn’t know when our last commit was actually deployed, so someone else brought the issue to our attention.
2. We didn’t have access to any of the tools necessary to diagnose the error, like error logs.
3. Even if we did identify the problem we still had to wait for the VIP code review to push the fix.

After talking with our account manager about the issues it sounded like they were all solvable. There was a hook we could use to get notification of deploys. They’re currently working on giving clients access to error logs and the database, and if the site were launched publicly the VIP team would get notifications and would jump on the issue immediately.

The issue of control came up a second time trying to diagnose why registration e-mails were not being delivered. Without access to the delivery logs you didn’t know if the e-mails were delivered or failing to send.

Needless to say I prefer the option of control with the safety of having other peoples eyes on it if I’m unavailable to fix something directly.

Throughout the process I often had trouble figuring out the preferred workflow. It took a handful of times to understand when we were supposed to open a ticket to do something and when we were suppose to do things ourselves. Now I know that during the code review new code was to be submitted as a separate branch with commit messages referencing the issues. After the code review this changed. We pushed code directly into the master branch which was then put into the review queue. If we were pushing a lot of code we would open a ticket warning VIP of the “impending doom.”

Key Lessons Learned

Having gone through the process I have a much better understanding of the platform, what to expect, and when it’s a good fit. Here are my key take aways:

Great for custom. Hard for assembled

If you’re planning on having significant custom functionality and don’t plan on building it all in house I’d look for another platform. In fact, I’d count on 80% of third party plugins getting issues raised.

Document, document, document…

I can’t help but feel like some of the debugging issues we ran into were caused because we only had knowledge of the code and VIP only had knowledge of the platform. On the next VIP project I plan on spending more time writing general notes about the application architecture to better inform the support team when issues arise.

Make sure it’s the right fit

The impression I get My initial impression was that VIP is a great fit for stable, relatively unchanged code bases that have trouble scaling under traffic. Our plan all along was to do quick sprints, pushing out new functionality every other week. This iterative approach seemed a bit at odds with the VIP process which feels slower and more methodical. Pushing changes quickly means less time for QA and greater chance for bugs. A simple bug patch needing to go through a code review queue is less than ideal for a more iterative nature. That said, according to the VIP team their average turnaround from push, to review and deploy is about an hour. A quicker turnaround deploy can also be accommodated by opening an “urgent” support ticket. While not instant like an ungated deploy, it does make quick iterative changes more feasible.

Hopefully this is enough insight to help inform your working with VIP. I’d love to hear other experiences or if you feel my conclusions differ from yours.