Recently WordPress plugin review team write a reminder post “Please do not submit frameworks” (Ipstenu/Mika Epstein).
And the reason is:
We require that plugins be useful in and of themselves (even if only being a portal to an external service). And while there are many benefits to frameworks and libraries, without plugin dependency support in core or the directory, it becomes another level of hassle for users.
In a comment, Darrin, who had a framework plugin (Advanced Term Fields) submitted and approved last month asked:
Are you saying the best way to handle this scenario is to include the parent framework in each child plugin, as opposed to alerting the user that “This plugin requires XXX plugin in order to function properly”?
And Mika answered:
Currently, yes. That would have been the best way.
I don’t really agree with this.
I think it should go to the opposite direction. And this is why.
Dependency Hell
One problem in Dependency Hell:
Two plugin, let’s just say “Plugin A” and “Plugin B” using the same framework and they add this framework by including it in the plugin as WordPress plugin review team suggested.
That means, the system (website) will have 2 instance of this “framework”. Of course both will use checking mechanism (maybe using function_exists() ) to load it, and the result is the framework will only loaded once.
But the question is which one?
Several scenarios:
1) There’s an update for the framework (maybe to solve bug/security stuff). And “Plugin A” update the framework. But “Plugin B” don’t update the framework.
If the framework in “Plugin A” is the one loaded, then all is good. But what if the framework loaded is the one from “Plugin B” ?
2) The framework introduce new feature. “Plugin A” update the framework and use this new feature, “Plugin B” don’t update.
What if the framework in “Plugin B” is the one loaded? “Plugin A” will be broken.
…etc
So,
Rather than including a framework in each plugin/theme I think it’s better to just add the framework as separate plugin. And let that be a new norm.
It’s better for the user. So they will get latest and most secure version of the library. It could be a bit confusing, but it’s the best for the user.
If a plugin did not work because they do not update it/make compatible with latest framework plugin, then it’s the plugin fault. Not the user, not the framework developer. And user will ditch them eventually.
Maybe Proof
One for the original author of CMB (Custom Meta Boxes) Library is Bill Erickson. The latest CMB version is 1.2.0.
His plugin using CMB:
- Image Override (v.1.2) still use CMB v.0.9.3
100+ active install - Old Post Notification (v.1.1) still use CMB v.0.9
50+ active install - Ketchup Coupons (v.0.1) use latest CMB v.1.2.0
400+ active install - Interstrategy Business Listings (v.1.1) use CMB v.0.6
10+ active install - Interstrategy Events Manager (v.1.0) use CMB v.0.6
less than 10 active install. - Event Manager Theme Functionality (v.0.9.1) use CMB v.0.8
500+ active install
So, if I install and activate just 1 plugin, it might work. But what if I install and activate all 6 plugins. Which CMB version will load in my site? Will everything work? Is my site secure?
That just an example. I believe there probably dozens of plugins in the repo uses CMB library.
To Bill Erickson. If you are reading this, I’m sorry I use your plugins as example. I’m a fan 🙂
I am thinking what we need is instead for WP to recognize “Libraries” and treat them different from plugins.
I think that’s a great idea. Maybe not too separated, because there’s “gray area” where plugin is a framework but have feature can be use by regular joe.
And maybe a dedicated “tag” could be use. plus add notice in the plugin page. Something like “This is a library (…be quiet)”