We just launched a portfolio plugin for WordPress at the beginning of September. Every project has its gotcha moment right at the end when you think you're done and an undiscovered assumption rears its ugly head. The plugin, Pizzazz Portfolio, was no different. The business model for Pizzazz is freemium where a free version is available to everyone and a commercial version with more features is available to those who want more beef. Our stumbling block was when we realized that we couldn't perform a direct upgrade from free to premium using WordPress. We've built several WordPress plugins, however the portfolio plugin is the first time we've released a plugin into the WordPress plugin directory for mass distribution. I asked some peers of mine how they handled these types of upgrades and they told me that they typically wrote custom updater classes. We could have done this, but there was just one problem: like any good developer, I'm lazy. I don't want to write custom updater classes if I don't have to. I won't explain here why it is good for developers (and benefits their clients) to be lazy, but I will blow your hair back by explaining how we used Joomla to upgrade WordPress.
The main problem was that WordPress isn't designed to allow installing a premium version over a free version. So I did some research and found a custom updater class built for WordPress that allows a developer to specify a different update source then the WordPress plugin repository. Using the class, we could trick WordPress to treat an upgrade as an update and pull in files from a remote server which WordPress would treat the same as its own repository's updates. For the application, this isn't installing a plugin over the top of another plugin, but rather a simple version update.
We built Pizzazz's sales site on Joomla because I prefer Joomla for sites that need application specific behavior beyond content creation. Additionally, I knew that if we needed to develop anything custom, we would have a more powerful development environment in Joomla.
As it turned out, we did want that development environment (*pat on the back past self.*) Once I realized we needed a server to deliver upgrade files to all the WordPress sites that would be running Pizzazz, we set about building a simple API on the sales site. We're using RS Membership to manage subscriptions and we built a custom component to receive the WordPress sites' plugin update requests. It uses an email address to check the status of a subscription and deliver upgrades and updates if that user's account is active. It took us about one third of the time it would have taken to build a custom updater class and none of the time dealing with the associated QA process and debugging of such a class.
The end result was that once someone purchased a subscription for the premium version, all they had to do was enter their email into the free version of the plugin and update it using WordPress's normal update process. It was super easy for the end user and very quick. It also violated the WordPress plugin directories guidelines and got the plugin promptly de-listed. I know what you're thinking: so much for being lazy. Yes, I didn't see that coming, and it was a bit of a bummer after all our work at being lazy, but it turned into just a minor headache and not a full blown migraine and we were able to continue to use our API to serve updates to active subscribers (which we needed anyways.)
This type of project is actually pretty common for us. We typically are working between and building solutions where none exist: between applications, between websites and services, between extensions and plugins, and between ideas and execution. Six years ago when I came up with the name for Blue Bridge what I perceived as the primary role of developers was building solutions between where people are and where they need to be— bridges. It's sorta fun when we have the occasion to build one for ourselves.