The process of refactoring Seriously Simple Podcasting

Last updated on July 15th, 2019

Seriously Simple Podcasting has been available as a WordPress plugin for almost 7 years. The initial release was published on 13 December 2012 by Hugh Lashbrooke.

Since Castos acquired the plugin in late 2016, we’ve pushed out 33 updates in the past two years. We’ve worked hard to fix bugs and add new features, the most recent addition being the ability to import podcast episodes from other third party platforms.

With a plugin that has been around for so long, there is going to be a level of technical debt involved in the code base. There has been 7 years worth of development on the plugin, but with more of a focus on fixing bugs and adding features. This means that as the functionality of the plugin has grown, so has dependency on a plugin structure that is suddenly no longer as maintainable as it was before.

The release of version 1.20.0 of Seriously Simple Podcasting includes the start of the process of refactoring the plugin in order to combat this problem. Seven years worth of development is not something you change overnight, but we’re hoping that the changes we implement now will pave the way towards a more solid code base in the near future.

PHP version requirement change

With the recent updates to WordPress’ minimum PHP version requirement to 5.6, Seriously Simple Podcasting has also been updated to the same requirement. We bumped the minimum requirement up to 5.3 back in 2017, so this was the next logical step.

Composer based Autoloading

Composer is a package manager for PHP applications, and has become the standard in managing third party packages. While we do not use any non WordPress based packages in the plugin, Composer also allows us to implement composer based autoloading. In keeping the plugin 100% compliant with WordPress coding standards we’ve opted (for now) to use classmap autoloading instead of a PSR standard.

Namespacing

Namespacing is a way of encapsulating the different pieces of your PHP project. Combined with autoloading, it allows us to remove all the ‘require’ statements in the plugin, as well as add a better structure to our classes and help prevent plugin conflicts.

WordPress Coding Standards

As mentioned earlier, and because the plugin is listed in the WordPress plugin repository, we’re slowly formatting all the code to meet the WordPress Coding Standards.

SOLID(ish) principles

SOLID is a design pattern aimed at making code more maintainable and flexible. While the plugin is not yet, and probably won’t for a while be, completely SOLID, we’ve starting a general move towards a better separation of concerns, so that working on individual pieces of the plugin is easier.

Unit Testing

We’re nowhere near 100% unit test coverage, quite the opposite in fact, but we’ve started by adding a phpunit config to the plugin. Going forward, any new features will be required to have unit tests. As we refactor the plugin further, and make the code more testable, we’ll add unit tests to those features already in place.

There’s still a lot to do, and as we add new features it allows time to refactor older parts of the code. We’re confidant that these changes will lay a solid foundation for smoother development and testing of new features as the plugin matures.

Share with a friend!

  • Category: