We just released the 3.0 version of our suite of events calendar plugins. It feels great to ship code, especially when you’ve been working on it for so long, but we’re also well aware that release is really just the midway point of the product cycle. Bug reports have started to trickle in. Thus far, nothing too major has been reported which is a great feeling. We’re knocking stuff out quickly, and things should quiet down shortly.
One issue that we are getting is from users who have customized their views. Often these are web builders just like us who are using Event Cal Pro to build solutions for their own clients. They’re going to have some work to do to make those customizations work with 3.0. I want to speak to why that is, and why we ultimately decided to go this route. I know when I update plugins, and my customizations break – I get annoyed. Really annoyed. Knowing that – why move forward this way? The problem starts with technical debt.
Events Life Cycle
Our product gone through three substantial iterations. The initial build was done for our clients. We needed an event solution, and at the time there wasn’t much out there. So we built it. To their spec. Then we built it again, and again, and eventually abstracting it to something that we could use with little friction on any project. That codebase was our first offering to the community.
Custom Post What?
While people were enjoying our 1.0 release, WordPress kept cranking out versions. Enter custom post types. This brings us to the 2.x cycle. We undertook a significant rewrite of the code to move events to custom post types. Not everyone loved it. In fact lots of folks particularly didn’t love it. Events that used to flow into their main blog loop, and their featured sliders and such no longer worked. At the time, we struggled with the decision. In hindsight, it was clearly the right course of action. Imagine releasing a product today that created content like events and used the default post type – you wouldn’t make it very far.
Why 3.0?
So what’s the deal with 3.0? There haven’t been any major structural changes to WordPress on par with the introduction of custom post types. The 2.0.11 release is solid. Like any piece of software, I’m sure there are remaining bugs, but overall it’s been pretty well worked over by 400,000 site owners. It’s selling well. Why on earth would we spend nearly a year, and an exhorbitant amount of our financial reserves to rebuild it? Technical debt.
We’re builders. We love making stuff. Working with things like Easy Digital Downloads, and Advanced Custom Fields are delightful because they’re built with builders in mind. When we began the 2.x cycle, we weren’t building for builders. The views lacked hooks and filters. The class names were inconsistent and confusing. The file structure was arbitrary. When we went to extend our own plugin, we faced hurdles. We continue to use our Events Calendar codebase on our client projects. Some of those projects include massive builds with millions of page views a month. Though the 2.0.11 codebase is solid, there are queries that are less efficient. To address them, meant rewriting the core queries that power the plugin. That’s technical debt.
Paying our debts
We could have continued to kick that debt down the road. If our goal was to milk this sucker for cash until it slowly atrophied, we would have skipped this update. It would have been cheaper. It would have been much easier. Instead, we made a commitment to sticking around. We wanted our product to be a tool that our peers can extend, build on, and accomplish amazing things. This meant tearing the bandaid off. The end result is a plugin that is ready for what’s next. It’s ready to be scaled, it’s ready to be extended. Future versions of the plugin will roll out gracefully (I’ll be writing about our release cycle plans shortly).
To the bulk of our users who simply plug-n-play, they’ll notice new features but little of what’s under the hood. They may find a bug, or need a tweak here and there, but ultimately the transistion should be pretty smooth. They won’t know about the technical debt that we’re currently paying off.
Our users who have customized their views are going to have some work to do to update them. That sucks. We know how frustrating it is to hit update and see things break. We are working on more documentation to help the process. Please hit the support forums and let us help you. We rebuilt 3.0 with all your future projects in mind.