Podcast: Play in new window | Download | Embed
Welcome to Episode 14 of the WordPress business podcast Mastermind.fm! Today Jean and James will be discussing total plugin rewrites. It’s an area they both have a degree of experience in, as both are either involved in or researching this strategy for their own plugins. Here’s a quick teaser of what they dig into on the topic. Tune in for more!
Total Plugin Rewrites!
Jean is currently discussing with his team whether they will be rewriting their plugin, WP RSS Aggregator. James and his team have been in the process of a complete rewrite of their plugin, Ninja Forms, for around a year now.
The first thing to ask yourself before you begin: When should a rewrite be undertaken? Some things to consider:
- Can you still iterate on your current architecture?
- Is there new technology or new developments coming in that changes the landscape of your market?
- Recurring user problems
- Want to open the plugin to 3rd party developers (if not initially built to be extensible)
Driving forces behind rewriting Ninja Forms:
- Mechanism by which we built the plugin simply didn’t allow for any other way of doing things. It was inflexible and the UI was starting to get cluttered.
- We wanted a new UI and new functionalities for our customers and users.
Ninja Forms has handled the transition from the old plugin (2.9.x) to the new plugin (3.0) using a slow transition phase-in to select groups of users. The most current version of the 2.9.x has the new 3.0 code base, but it only unlocks under certain conditions. Certain checks are in place to make sure that a user with non-compatible extensions isn’t able to roll forward before they’re ready. There are also multiple channels for user testing and reporting without actually having dedicated beta testers.
Reflections on the Ninja Forms Three process:
- Work as much behind the scenes as you can until you are ready to market
- Don’t put out timelines
- Don’t make promises too early
- Plan your marketing early but don’t start too early
Particular challenges in the process
- Settings name changes and changing how they’re stored
- Addons need the same changes that core does, multiplying the work and adding challenges to upgrade routines used in core
- Handling customization in functions.php without breaking post-upgrade
- Handling user analytics in the transition from old to new
Parting thoughts from James: Think about your user base, think about your code base, think about your team. What’s best for everyone involved? Consider all the different pieces, all the moving parts, everything involved. Don’t come to the decision lightly. Ultimately, do what is best for your users.
There’s much more in the audio from marketing to support, so sit back, grab your favorite frosty beverage, and lend us an ear! After you’re finished, check out the latest post on Pippin Williamson’s blog. He discusses monsters and databases: The monster that is a poor database schema. It’s very much related and we bet you’ll love it!
