One of the challenges for Author Buzz was that we need a lot of different functions and features without polluting the plugin list with a large collection of things that blog users cannot directly access.

Our ideal solution would be to wrap all the features into one plugin. However, we also want to still be able to break them out into separate plugins if one feature was to be shared or became rather too big for where it started. With requirements like those, some advanced planning was needed.

The solution so far

Inspired by the boilerplate plugin design, we created our own framework that would allow us to create discrete modules for a single plugin.

To make that happen, we needed an object-oriented approach that would allow us to keep tot he principle of one change, one edit. That is if we change something we only need to make the one edit to do it. At no time should a change to one part of the system needed further changes in other parts of the system.

Additionally, we needed to abstract away each module so that we could activate and deactivate it as needed. Early testing was always going to be away from the live server but each feature would need some test time on live too. That means that we need to shut down a broken or poorly performing module without shutting off the other features.

To do this we have created a framework very similar to the boilerplate plugin. In fact, we started from the boilerplate as it really is some excellent code. However, that was where we left the beaten path. We combined the static class to contain three static methods active, deactivate and modules. The modules section would be the one place where we would edit to include, well, modules.

We created an abstract class which acts as a base for modules and allows us to design utility methods that all modules might need to use.

To further promote good object reuse, we also created what we called models. Like the Model View Controller approach to design, models would carry out data transport. While modules would carry out logic.

What else do we need?

Next, we took a look at Admin and front end UI. Here, we are still figuring things out. The design approach will be that UI should map back to specific modules but those UI elements should active only if the matching module is available. Thus if we shut down a module, the UI shuts down too.

As we have written a custom method is_active_module(), it should be trivial for UI to declare module dependency.

The next step is to create hooks to allow the UI to register for admin area and front end interface time.

It is working well

Early testing indicates that the modular approach works well and is reasonably efficient. It is also, I am pleased to say, a joy to work with. A little more development for UI deployment and unit testing is left to go. Soon we should be ready to roll out the framework to see how it performs in the live environment.

After that, we can fast forward the production of a number of tiny features and tweaks. We can also get to some of the more significant feature changes that we are hoping to make.

As for now, back to the grindstone for me.