This has been a long journey considering we only changed a single digit going from 1.7.20 to 1.7.30, but internally, Statcomm has changed so much, that we considered to explain a little what it is all about.
Before introducing our current development path, we want to thank you. Your feedback proved to be invaluable to make this plugin evolve. We want to simplify the communication between all of us, so we expect to give you some news in the short time. Stay tuned.
So, let’s get into the concept, should we?
After careful listening to the users, we decided to make a changing move to support current requirements in a more manageable way. Many requests required just a plugin fine tuning, but others were definitely more challenging and very promising for current and future users. At same time, we would like to make a robust plugin core while we develop new features.
So, we started thinking a way to answer a higher level question(s) regarding what the user needs.
And the question(s) was/were: how to include additional functionality without cluttering the plugin? How can we make a better plugin to fulfill simultaneous requirements, even conflicting ones? Is that even possible?
Answering questions: back to the basics
We currently dug in alternative ideas and solutions to answer it. Our obvious first question was: If someone surely did the same thing, how did they solve it? We found a few other solutions implemented , but they fell short to our way of doing things.
One approach we saw was basically an ‘on-off’ functionality, like wired switches inside the code. You could turn some functionality on and off, but in the end you couldn’t expand it. The ‘switch’ philosophy leads to rigid code and you can’t easily add newer functionality without some tradeoffs and getting hands dirty ( aka custom programming).
Other solutions bypassed the problem. You have a plugin, so if you want to expand it, just make another plugin to complement the first one. Currently, that is the accepted workaround. We found some drawbacks about it:
- We would need to activate many plugins to accomplish additional tasks. What if we want to make a very simple solution with a couple of lines. Should we make a plugin just for that? This solution fragment a problem that maybe it shouldn’t be fragmented in the first place.
- Moreover, we could end up creating many plugins that few people would actually use, since the plugin functionality is depending on other plugin and it won’t work with anything else. Good for our ego (because we would be the creator of many plugins :), but bad for the final user.
- Avoiding clutter the plugin in exchange of cluttering WordPress Repository with rather limited plugins is like delegating a problem to another entity. Something is stinking in this way of solving things.
But what if we use a simple way of activating and deactivating code in a way a user easily manage it to match their needs? Ok, ok, that’s sounds pretty much like the normal WordPress plugin. In fact, the solution we finally came up is nothing new but a tweak.
The subplugin way
Our current solution tries to reuse as much WP core functions as possible. We failed to do so.
Don’t get us wrong. Some parts of WP were never thought to be used in the way we did, so we re-write it to be a little more flexible (maybe we should add some suggestions to the WP core , but that’s is another story).
Back to the idea, a Statcomm subplugin is a stripped-down version of WP plugin concept. That was easier to say than done. It took a major rework, but it has no additional mysteries to the final user. It is a familiar concept that everyone will be comfortable with.
Subplugin: what is and what is not
A subplugin is similar to a plugin because:
- It uses the same plugin header format to be identified.
- Can be activated/deactivated in similar fashion as a plugin.
- It works almost exactly like an usual plugin.
- If you know how to make a plugin, make a subplugin is just plain straightforward.
- We’ll make a bunch of them in the incoming versions to fill many gaps, mainly user requests.
But also, a subplugin is different a plugin because:
- A subplugin resides in the [statcomm folder]/subplugin folder. After that it is detected and it works in similar fashion as a plugin.
- It uses a separated menu (subplugin menu) in Options.
- Is initialized right after Statcomm plugin initialization.
- A subplugin cannot be edited or deleted, only activated/deactivated.
- If a subplugin is deleted manually, automatically is deactivated (it could happen in a Statcomm plugin update) as plugin works.
- Subplugin can’t be searched or filtered(at least this functionality is discarded in first versions)
- Subplugin list is not paginated (idem)
- There is not a recent list of activated/deactivated subplugins.
- There is not automatically updates and no updates at all, only when Statcomm plugin updates.
- There is not actions/filters usually found in the WP core unless strictly necessary(at least in the initial version)
- Subplugins were made to fulfill the users requests and kept the Statcomm core as clean as possible, keeping non-core feature in its own containers.
- We encourage users to hack these subplugins , test it, modified it and improve it. We are always open to your feedback, suggestions and criticism.
There is clear distinction when deciding between plugin and subplugins. We are working toward make a robust Statcomm plugin core and a also a layer to handle the many user requirements. These add-ons will move with the plugin and they should be very easy to configure. That would be specially useful when we release Statcomm 1.8.x version, where the graphic engine will be switchable. But that’s is way ahead in our schedule.
When it would be available?
We are testing the new implementation. The 1.7.30 version will be ready before July 15th.
Thank you everyone and enjoy the day. Don’t forget to read second part!