We’ve been telling customers to always be on the latest and greatest version of everything WordPress related. It has become the de facto answer to any bug report: “Are you running the latest version of plugin x and y?”. That’s fine, for most use cases. But what if I’m in a situation where I can’t be at the latest version? Or what if I find a bug in the latest version and have to restore to an older version?
Of course, we run our version control for websites. We can restore older versions of plugins after we find a bug. This requires us to have the premium plugin in our own version control, writing our own history. While this works fine, there are a couple really big downsides to this.
Composer makes it even more complicated
Adding Composer to the stack of tools in our projects makes this even more complicated. Composer allows us to specify what version of the dependency we want. This works fine in a perfect world, where we have access to every single version. If we find a bug in version 2.0.7, we can quickly install 2.0.6 on the site, the one we always were running and know it works fine.
The problem is, we usually do not have access to every single version of that dependency, because we don’t have access to their version control system.
Actually, to make this trick work with Composer, we need to write the plugin to our own version control. You want to add the premium plugin as a separate repository and use that as a dependency in all your projects, because it’s impossible to maintain a history of one plugin in 10 different project repositories. This also means that we have to keep that repository up to date all the time, so we collect all versions in our own version control.
Writing our own history
The core issue is that we don’t have access to the version control system of the premium plugin developers. So when they push out a new version, we have to download the file and update it in our project websites.
Now when I first thought about this, I wrote a script that does the following:
- Unzip provided zip file
- Compare the contents with the state of the version control
- Commit changes if there are any
- Read the new stable version number
- Tag the repository with that version number
This works fine in most cases and that isn’t good enough in my book. Using this script means that I’ll have to run it between every single release of the plugins, or I’m going to miss a tag and that already happened twice in the first week. This made the script a mission impossible, it just isn’t good enough.
Sidenote: I’m currently looking at setting up our own Satis instance, but let’s not go there as that will make this even more complicated. I did want to mention it as it proves some of my points again as it struggles with the same issues.
Plugin developers, you need to fix this
Things like my script, it’s only going to come close to the ideal situation. It’s up to the plugin developers to provide us with a way of downloading older versions of your plugins. Ideally, this is not just a long list of downloads, but a way that we can use (automated!) in our tools and projects directly. I’m sure you can’t just open up your version control to all your customers, but offering a repository with just commits and tags per version would be perfect.
The way people use WordPress plugins is constantly evolving. Services like WordPress Packagist prove that there is a need for different ways to get access to your plugins, other than simply downloading a zip and installing it in a single website. I hope you are going to evolve with us.