There’s a newly clarified policy on Make Plugins from Mika Epstein where she says that developer frameworks are no longer going to be approved for the plugin repo. Plugins like CMB2, Advanced Custom Fields and others that may be dependencies of other plugins, and are not feature plugins of their own, would theoretically not be allowed. However, existing approvals are grandfathered in.
Mika notes it’s about users, not developers:
The issue is as follows: Having a framework as a plugin is a poor experience for the user. Not the developer. Theuser. The user understands “I have an add-on for WooCommerce, I probably need Woo.” They do not always understand “I have plugin Slider Joe. Why do I need Advanced Custom Fields?” In addition, by having a library as a plugin, the onus of version compatibility is now on the person least likely to understand it: the user.
From the context of making the plugin repo better to use for users, I completely get this. However, I am a little concerned that this removes a lot of the “free” stuff one gets form hosting a plugin on WordPress.org, especially seamless one-click updates, but also the social aspects (list of author plugins) and the discoverability component.
I’d like to see more discussion around how the repo can be beneficial for both users and developers — if the proper context for the code that is made available is provided.
This conversation was a bit frenzied today, and a great post to read from the developer-plugin developer’s point of view is the one by Justin Sternberg on CMB2 and its future.
