BROADCASTS.com

b'Welcome to Episode 14 of the WordPress business podcast Mastermind.fm! Today Jean and James will be discussing total plugin rewrites. It\\u2019s 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\\u2019s a quick teaser of what they dig into on the topic. Tune in for more!
\\nTotal Plugin Rewrites!
\\nJean 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.
\\n
\\nThe first thing to ask yourself before you begin: When should a rewrite be undertaken? Some things to consider:
\\n
\\n \\t* Can you still iterate on your current architecture?
\\n \\t* Is there new technology or new developments coming in that changes the landscape of your market?
\\n \\t* Recurring user problems
\\n \\t* Want to open the plugin to 3rd party developers (if not initially built to be extensible)
\\n
\\nDriving forces behind rewriting Ninja Forms:
\\n
\\n \\t* Mechanism by which we built the plugin simply didn\\u2019t allow for any other way of doing things. It was inflexible and the UI was starting to get cluttered.
\\n \\t* We wanted a new UI and new functionalities for our customers and users.
\\n
\\nNinja 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\\u2019t able to roll forward before they\\u2019re ready. There are also multiple channels for user testing and reporting without actually having dedicated beta testers.
\\nReflections on the Ninja Forms Three process:
\\n
\\n \\t* Work as much behind the scenes as you can until you are ready to market
\\n \\t* Don\\u2019t put out timelines
\\n \\t* Don\\u2019t make promises too early
\\n \\t* Plan your marketing early but don\\u2019t start too early
\\n
\\nParticular challenges in the process
\\n
\\n \\t* Settings name changes and changing how they\\u2019re stored
\\n \\t* Addons need the same changes that core does, multiplying the work and adding challenges to upgrade routines used in core
\\n \\t* Handling customization in functions.php without breaking post-upgrade
\\n \\t* Handling user analytics in the transition from old to new
\\n
\\nParting thoughts from James: Think about your user base, think about your code base, think about your team. What\\u2019s best for everyone involved? Consider all the different pieces, all the moving parts, everything involved. Don\\u2019t come to the decision lightly. Ultimately, do what is best for your users.
\\n
\\nThere\\u2019s 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!'