Can I tell you what’s been keeping me up at night (well, not counting last Thursday’s leftover Taco Bell)? One word: breakage.
When I adopted Seamless Donations, I also adopted an active user community. People and non-profits use the plugin every single day to help them raise money that, in turn, helps them reach out and support their causes. It’s a good thing.
To grow Seamless Donations, to add features that users have been clamoring for, and to be able to maintain it for the long haul, I’ve been updating the code so it’s much more modular and supports hooks and filters throughout the project. Don’t get me wrong: Allen, the original coder of the plugin, was a master. I’d be lucky to reach his level of coding skill. But for me to be able to maintain it, to easily be able to make small changes that don’t ripple through the entire plugin, it has to be re-architected to have an extensible-first design priority.
Already, I’m seeing some great ways to make that work for plugin users. For example, Donors, Donations, and Funds are now each custom post types, so the data stored in these post types can be used throughout the larger WordPress environment rather than remain locked inside of options records. Donations was previously a custom post type, but it didn’t integrate with, say, donors through the post type environment.
That brings me back to breakage. If you’re just using Seamless Donations 3.3.x and upgrade to 4.0, nothing should break. I’m writing data conversion routines that will migrate the old data formats to new, and it should all be good. Yeah… but…
How many of you are “just using” anything in WordPress? How many of you have gone in and tweaked the CSS of the plugin? How many of you have gone in and actually patched the core code because that was the only way you could get something to work? How many of you are counting on certain options being available and even certain functions and methods, by their original name?
In other words, if one morning you woke up and ManageWP, MainWP, YadaYadaWP, or JetPack decided to automatically update your Seamless Donation plugin to a whole new architecture, how many of you would begin by having a very bad day?
According to WordPress.org, there have been 59,442 downloads of Seamless Donations with 10,000+ active installs. There were 1,374 downloads in just the last week alone. I do not want to wake up on that same morning and have all of you annoyed at me because some auto-update service you use updated the plugin and, because the new version has different internals, broke your site.
This worries me for my own sites. I auto-update my plugins to make sure they get security updates, and I’ve had sites break because the plugins changed behaviors.
Can you now see what keeps me awake at night? The potential for 60,000 pissed-off nonprofit Web site operators all yelling at me at once. Ouch. Not gonna let that happen. Gonna be smart, instead.
So let’s talk roadmap
I have carved out big chunks of time on my schedule (it’s actually in my calendar) to work on Seamless Donations. I’m hoping to have version 4.0 done by the end of June (or earlier). Of course, that might change if the day job makes unexpected demands, but that’s why I’ve actually pre-allocated my time. That way, I’m not just doing this when I get a few minutes here and there. I’ve made appointments for a lot of coding time each week.
As I’ve discussed earlier, 4.0 will have the new extensible architecture and use some frameworks that will allow for future growth.
But I’ve been really worried about the breakage issue. I’ve been agonizing over whether to auto-update the data to the new format (so those getting plugins updated automatically don’t stall) or do some other approach. I’ve decided on another approach.
One little detail I didn’t tell you previously is that I’ve been building the new admin functions of Seamless Donations as a separate menu tree from the original. That way, I can quickly go back to the original and compare notes, to make sure I’m getting all the settings and options moved over. In other words, there’s a Seamless Donations admin menu and a Seamless 4.0 admin menu and they’re both live. It works very well.
Getting back to that big upgrade morning, though, here’s my plan: I’m going to keep the old pre-4.0 infrastructure for Seamless Donations in the code and make that the default stuff that runs. That way, if you’re relying on all of Allen’s code and you have a working site, nothing should break the morning of the upgrade.
There will be a nag bar plastered on the top of the screen (like the Sandbox testing bar) that lets you know you can migrate to the new version. The new version will also be installed as part of the plugin distribution, but won’t be turned on (via careful use of options and if/thens) until you decide to go into the admin panel and specifically and consciously click the “upgrade to new version” button.
At that point, the data will convert, the old menu will drop away, the new Seamless 4.0 admin menu (and all the slick new interface goodies) will come online, the custom post types for Funds, Donors, and Donations will be live, and you’ll be working from that point forward in the 4.0 world. Slick, eh?
You won’t be able to go back, but assuming you’ve used some best practices, that shouldn’t be a problem.
Best practices upgrade migration
For example, you can (read: damn-well-better) backup your site, make a copy on a staging site, update the Seamless Donations plugin to 4.0, and then click “upgrade to new version.” You can then see what changes and problems might manifest while on the staging site, make any changes you need for your live site, and then, once you have everything ready, “upgrade to new version” on your live site.
That way, you can have your code and eat it, too.
The old code won’t really add too much overhead (although I’ll have to be careful if I want to change functions in the original code — I’ll probably clone them and rename them so they don’t conflict in the namespace).
The one area of big risk is if the old code runs into a security issue. It’s been running for years now on so many of your sites, that I’m less than concerned. And, like I said, Allen (the original developer who now works at WordPress’s Automattic) is a heck of a programmer. He has been very careful in coding the plugin for security best-practices. So that code should last for a while without needing too much work.
My guess is that after a year or so of 4.0 (and above) in active use, I’ll jettison the old 3.x code so that it’s not out there in the wild.
So, there you go. A safe, smooth, shouldn’t-break-everything-one-terrible-morning upgrade path that will get you new plugin hotness while at the same time making sure your sites stay running without any unpleasant surprises.
Yeah, it makes me feel all warm and fuzzy, too.
–David
