Today the WordPress plugin review team issued a reminder for what they said is a long-standing, unwritten rule: frameworks are not allowed in the official directory. In a post tiled “Please do not submit frameworks,” Mika Epstein outlined the reason behind the rule:

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.

Until WordPress core adopts a way to support plugin dependencies, the plugin review team recommends that frameworks and libraries be packaged with each plugin in a way that doesn’t conflict with other plugins/frameworks/libraries.

The issue was most recently addressed with the CMB2 plugin, which Epstein said was mistakenly approved months ago. CMB2 is essentially a library that makes it easy for developers to build metaboxes, custom fields, and forms. It is exactly the kind of plugin that the previously unwritten rule is meant to block from being available in the official directory. Epstein further clarified the reasons why:

The issue is as follows: Having a framework as a plugin is a poor experience for the user. Not the developer. The user. 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.

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.

The confusion lies in the fact that this particular rule has been applied inconsistently for years and has many notable exceptions, including Redux Framework, CMB2, and arguably plugins like Piklist, Titan Framework, Kirki, Options Framework, and many more. These are the types of plugins that don’t really do anything out of the box but are meant for developers to use for building things.

According to Epstein, a few of these plugins have been “grandfathered in” due to oversights in the plugin review process, but the rule stands for new submissions.

“CMB2 and Redux Framework are grandfathered in,” she said. “We don’t let any more in, since a lot of plugins include them inside AS plugins. It’s a mess. Also CMB2 shouldn’t have been approved, which is a different mess altogether. Frameworks are not supposed to be in the repo at this time. Period.”

Another commenter on the most recent post, who recently had his Advanced Term Fields plugin approved, 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?’”

Epstein confirmed that this is in fact what the team is suggesting:

Currently, yes. That would have been the best way. Since your plugin is approved, though, it’s unfair of us to yank the rug out from under you. While you don’t have a great many users, we recognize when the gaff is us.

The plugin review team has a difficult job and is working with limited volunteer resources. However, the inconsistent application of unwritten rules has led to what appears to be an arbitrary set of guidelines. One thing that would make life easier for both reviewers and plugin developers is if WordPress core adopted a way to manage inter-plugin dependencies. The TGM Plugin Activation team is working on a proposal for a feature plugin, which we’ll examine in depth in an upcoming post.

Source: WP Tavern