For the past six weeks I have been working to retire a small library of shared plugins on the VIP Go platform. It was a slow and delicate operation that needed to be coordinated with clients and development partners. It required patience, accuracy and lots of testing.
My task was to manually open pull requests against each site and environment that we host. Any dependence on a shared plugin required moving the plugin into the local repository and adding code to ensure it was a seamless transition when deployed. Once completed for all sites, I could then retire a custom VIP plugin interface and also introduce a new API on our own website that makes updating our featured technology partner plugins a much easier task too.
The end result is a much cleaner code base for us to maintain, but more importantly it sets us down a path for a much better plugin experience for sites on VIP Go.
Let’s back up a little bit.
At the dawn of the VIP service on WordPress.com it was decided that all client themes must pass through code review. With WordPress.com being one large WordPress multi-site, the impact of a poor code from a single theme can have far reaching consequences. This led us to create a code review service and it has become one of our most distinguishing features. Code review leads to better developers and highly robust themes.
Code review also came with the requirement that all code must live in version control, making it easy to roll back to previous versions if needed. This took us in a different direction to WordPress core’s one click plugin and update features but gave us a much more predictable code base.
Code review is a slow and expensive process. Waiting for code to be reviewed is a bad experience for sites that need to be updated quickly and frequently and from our perspective we don’t want be reviewing the same plugin and code libraries over and over again. We decided the best way to fix this was to create a shared plugin collection that any site could make use of at the touch of a button. All of the plugins in the collection are guaranteed to be performant and well tested.
Whilst shared plugins sound ideal in this situation it has led to some other difficult problems. Suddenly we had many sites using the same code and it became tricky to update any of the shared plugins. One client may rely on a feature in version 1.0 whilst another is pushing for the new version, 2.0. The solution was to version each plugin, storing many different copies on our servers. Another layer of complexity was introduced.
So far we have only considered the needs of our clients and our code review team. On VIP we also have partnerships with a number of unique services. These are our featured technology partners. These partners would like to make sure our clients are using the latest plugin versions. As partners they also benefit from our code review service and we try to promote their services where possible, making it easy for new users to get started.
We have three different audiences all with different requirements when it comes to plugins on our platform. Balancing these has led us into a spiral of complexity. With the creation of VIP Go we moved all this complexity over to the new platform without much thought. This was a mistake.
By removing shared plugins from VIP Go we have simplified our product and laid a path for smarter tools and workflows going forward. Our next step is to build a plugin update bot that creates pull requests when a new plugin version is detected. Our clients can be in control of which plugin they want to use and when the updates roll out.
The most important change we have introduced with this work is a client first mentality. If we can simplify their experience whilst putting the control back in their hands then I believe we are heading in a better direction. We must continue to focus on their problems and needs over our own.
Photo by Iker Urteaga on Unsplash.
Automattic Design 