If you have been following WordPress news of late, you might be aware of the recent policy change introduced by the plugin review team last week: from now on, no frameworks will make it to the WordPress plugin repository. The already accepted and approved framework plugins shall continue to exist, but no new ones are going to find their way in there.
So, why this dislike for framework plugins? And what happens now? More importantly, is this decision justified?
Prelude
In a post titled “Please do not submit frameworks,” Mika Epstein of the plugin review team posted this:
The plugin repository is not, currently, a library or framework repository. It’s not meant like the NPM package manager, or even Composer as a way to define what a plugin ‘needs’ in the same ways for a developer to build a project. The plugin repository is, plain and simple, meant for plugins that users will find useful. Plugins that add functionality to WordPress in a directly inter-actable way.
…
At this time, we are not accepting frameworks as we don’t feel frameworks, boilerplates, and libraries are appropriate for the Plugins Directory. 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.
This is pretty self-explanatory: until a better way has been discovered, the plugin review team would prefer that frameworks and libraries should be packaged with each plugin (in such a manner that it does not conflict with other plugins or libraries). In other words, rather than telling your users “My plugin requires XYZ framework that you can get from the plugin repository”; you should bundle the XYZ framework with your plugin.
Of course, the existing ones on the repository, such as Redux Framework and Options Framework will continue to exist. This decision applies to new frameworks that might be vying for inclusion in the repo in near future.
Epstein has explained the logic behind this policy in the announcement blog post itself.
Is It Justified?
Is this policy towards frameworks really justified? Or, in other words, does it make sense to exclude frameworks from the plugin repo?
I can understand the logic behind this decision: having frameworks as plugins does account for a poor experience for the end user, among many other drawbacks.
However, that said, frameworks as plugins are definitely not bad enough to eliminate them entirely from the plugin repository. Also, while having frameworks as plugins is probably not the most sensible approach, it works well enough and is not broken enough to be fixed in such a manner.
Consider this case: as per the new guidelines, say two plugins bundle the same framework that they depend upon. Now, let’s say a user installs both plugins (let’s also assume that the two plugins are coded by two different developers, and serve two possibly unrelated functions and perform possibly unrelated tasks).
Now, everything might work well, but there’s also the chance that everything might break — what if the plugins have treated the same framework in two different manners, such that they are using it in mutually incompatible methods? Furthermore, what if the framework has a version update, and the developer of the first plugin switches to the new version, whereas the developer of the second plugin does not immediately upgrade to the newer version of that framework?
Yes, we can come up with numerous permutations and combinations wherein the website might crash if two such plugins are used. As a result, these plugins might no longer be usable in the same environment or on the same site — although they can possibly be used together if only the said framework were installed separately from the repository.
Also, it might be that I am overlooking something, or that the plugin review team is missing something here, but it is not the monopoly of *developers* to use a framework. Many users, possibly slightly higher than newbies but still not developers or advanced users, tend to use framework plugins for varied purposes. There are users who do not truly care if the said plugin that they are using is a framework, a library, or whatever else fancy term you call it — if it is updated regularly, does the job well, it is usable enough.
What Now?
The biggest and easily the most annoying issue with this change is that if you have a project that relies on a framework, you will now need to bundle that framework with your project. Works fine enough, but it deprives you of the ease and convenience of the WordPress.org plugin update system. Developers will now need to handle and manage updates of frameworks and child projects on their own; the WP.org update system and all the awesomeness that it has to offer is just not gonna work with framework-dependent stuff anymore.
Some users in the community have called this a case of selective enforcement of ideas. The REST API plugin is a framework too, but an exception has been made. However, considering the fact that I do not (unfortunately) contribute to the WordPress Core, I’ll refrain from passing any such judgment. But as someone who relies heavily on working with and tweaking WordPress for a living, as well as deploying projects built on or with WordPress, I do feel affected by this new plugin review policy and definitely not in a positive manner.
In all fairness, though, this decision has had some backing too. For example, look at the support threads of any major framework and you might find an upset user claiming that the plugin does nothing! The user probably expected the framework to work out of the box, like a true “plugin.”
However, rather than saying no to all future framework inclusions, it might have been better to consider a separate “Developer” plugin repository, or add a “Libraries” repository alongside plugins and themes — and until then, permit coders to submit frameworks to the plugin repo, although temporarily, such that those frameworks are moved to the Libraries repo as and when it is ready.
Finally, the decision to allow existing frameworks to stay in the repository is justified and sensible. However, as a side effect, it will also ensure that existing frameworks grow in stature, and newer ones struggle to compete, no matter how good they are.
What do you think of this new decision by the plugin review team? Share your views in the comments below!
4 Comments