July 18, 2018 marked a big day for our Weglot Translate WordPress plugin as it was the release of version 2 of our WordPress integration. We had been working for more than 2 months to completely redesign our plugin which had more than 20,000 active installations at the time. Updating a plugin can quickly become a nightmare for both the users and developers and our big version 2 release was no exception! This blog post is feedback on how we proceeded to make a smooth transition from Weglot v1 to Weglot v2 without clogging our support and frustrating our users.
Why did we need a new version?
Before explaining how we proceeded with a new version, it’s important to understand “why” we had to make a new version of Weglot. The main reasons were to improve the “adaptability” of our plugin and to reduce our technical debt.
An increasingly long and difficult support
The first version of Weglot did not contain any WordPress filters or actions: the so-called hooks. It was thus very difficult to change the default behavior of our plugin and adapt it to specific customer needs. We had to provide custom patches to our customers while taking into account the changes for our next updates. It was quite tedious and delicate. The more customers we had, the longer the technical support was. Of course, we could have simply added some filters and actions as we went along, but we were faced with other problems.
A growing technical debt
Here is the quality score of the Weglot WordPress plugin code at the time of the last update of version 1 (v1.13.1): 6.53 / 10
Generally speaking, we can’t say that it’s a terrible score but it’s clearly not great either. The mediocre score was partly due to some of the dependencies that we were using and we couldn’t do anything about it but there was still room for improvement. We didn’t want to continue on this path and end up with huge technical debt and a very slow plugin. The main problems came from the complexity of our algorithm and we realized that when we tried to set up Unit testing (automatic testing scripts of our code): It was impossible! Our objects and methods were far too large and not isolated enough. We did not comply with the SOLID principle and it had an impact on the plugin quality score. Of course, these things are invisible to our users but it has a direct impact on us in terms of maintainability and therefore also in terms of support so it’s also ultimately important for them.
Finally, we also wanted to get closer to the WordPress Coding Standards (that evaluates the writing quality of your code) and we were very far from it. So version 2 was an opportunity to comply with it.
With these improvements, the goal was to start over on a solid foundation that would allow us to be more responsive to technical support and to be able to make changes to our plugin more quickly and with greater quality. But making all these changes will not be simple.
With a great update comes great dangers
With more than 20,000 active installations of version 1 of our plugin, we had 2 possibilities:
- Solution 1: Create a new WordPress plugin
- Solution 2: Make a critical update of the current plugin
While the first solution was the simplest in terms of development, we quickly eliminated it as it would have been like starting from scratch from a Marketing and Communication point of view: 0 reviews, 0 active installations. It was too risky business-wise.
So we decided to go with solution 2: updating our current plugin. We were going to significantly change most of our plugin core code while maintaining more than 20,000 active installations.
Sounds risky? And what if we decided to also add an extra challenge on top of that? The plugin v1 required at least PHP version 5.3. We wanted to upgrade this minimum version to PHP 5.4, so we had to do some prevention to users who could no longer be able to use Weglot.
All this sounded like a recipe for disaster. We were already imagining the chaos on the release date: the customer support team running everywhere screaming, angry customers giving us 1-star reviews, servers crashing, … Of course, we didn’t want that. So, let’s take a look on how we managed to avoid all this.
How did we prepare for the update
Before releasing the big version 2 update, we decided to release a small update (version 1.13.1) whose main goal was to prepare everyone for the big release.
Version 1.13.1, our emergency exit
This little update played an important role in several situations: First, it prevented users with the old PHP 5.3 version from being able to update their Weglot plugin which was a first big risk solved. Then, it also warned all our users that version 2 was coming up and that it might cause errors (nobody is perfect!). To do this, we have set up an informational pop-up, visible in the Plugin tab of WordPress, that adapts depending on the release date of version 2 like this:
This message was displayed the day of the Version 2 release from D-day to D+15: The warning is pretty clear: This update is still in beta and we advise users to be really careful if they decide to update their Weglot app.
Then, the message changed to this from D+15 to D+30: We removed the “beta” mention but kept the backup recommendation.
Finally, the pop-up changed one last time once we knew that the new Version 2 was stable.
So … did it work?
Let’s look at the update rates of our plugin
To know if our update prevention system worked, we can first look at the update curve provided by WordPress. Unfortunately, it’s difficult to define whether this has really had a big impact. When you look at the graph, the “update peaks” are more or less the same as the following updates peaks.
But this graph can be misleading as it also includes all the quick hot fixes we made after the big Version 2 update and we can’t filter them out. We can also see that the rate of updates is spread over several days and is closer to the yellow line so it can be a sign of the impact of our pop-up system.
What about our support load?
There is another simple way to know if our system worked: the number of users contacting us on our customer support. We expected the number of support tickets to explode and we were ready to stay all night helping our users with the new update. We saw a slight increase in the number of conversations received but in the end, it was not out of the ordinary!
We saw a 19% increase in conversations during the month of the update. But this includes all technologies Weglot is also available for (Shopify, BigCommerce, …) and the natural increase in support as a result of our growth.
One of the initial goals of the update was precisely to have a more responsive support and to be able to solve more technical custom issues easily. For this, we can say that this update was a big success as we have quickly handled all the various problems caused by version 2 thanks to the improvements made to the core of the plugin.
Our new quality score
One of our goals was also to improve the code quality of our plugin and we can be pretty happy with the results: We now have a quality score of 9.99 / 10!
We can see the improvement on a daily basis when we implement new features or respond to specific technical support: it’s fast and easy! We now have almost a hundred WordPress filters and actions available and finally, we were able to set up unit tests for our plugin!
In the end, we are fully satisfied with the way we handled the release of this critical new version of Weglot: We managed to change a big part of our plugin without breaking everything and drowning our support team with hundreds of messages on release day. A successful challenge despite more than 20,000 active installations!
I hope this feedback will help you in your future update. If you have any questions, do not hesitate to contact me on Twitter.