So recently the WordPress plugin review team, and the WordPress meta team (the team responsible for maintaining wordpress.org and tangential properties like the plugin repo) have been talking about and making some pretty big changes, and it looks like some of those changes are starting to take effect.
Earlier, I tweeted a bit:
So this is that blog post.
First, I want to get a few things straight.
- The WordPress plugin review, and the WordPress meta teams are both awesome. The plugin review team wades through thousands of plugin submissions a year and I don’t know how they keep up with it all. They deserve all the respect in the world for doing what they do and making our WordPress world a better one.
- Despite the fact that this post is about CMB2, these opinions are my own, and do not necessarily reflect those of my employer, WebDevStudios.
Now for the pain points.
1) In this comment thread on the make blog, you can see that CMB2, and other framework plugins are no longer (and, I guess, never were) allowed in the repository. I would be totally ok with that decision… if that was the decision that was given when the plugin was submitted. But since, through some inconsistency in the system or communications, CMB2 was approved, we’re now in a place of derision. If this, in fact, their final decision and goal for the plugin repo (which would be a bummer), we would definitely rather hear from them directly that they don’t want CMB2 (or any framework) in the repo and that we should look into other methods of distribution.
2) In this response in that thread, the suggestion is instead,
Frameworks and libraries should be packaged with each plugin (hopefully in a way that doesn’t conflict with other plugins using the framework or libraries). At least until core supports plugin dependencies.
— Hey that’s awesome! CMB2 is actually built to handle conflicts naturally and ONLY load the most recent version it finds. It also maintains backwards-compatibility for this reason. If this is the worst-case scenario, it’s not all that bad.
3) BUT WAIT, based on this plugin submission rejection, it appears that the plugin review team (of which, Mika of the previous quotation, is a prominent member) does NOT allow CMB2 to be bundled as a framework either. Is removing CMB2 from the plugin repo the solution here? Would that satisfy the seemingly arbitrary guidelines?
4) Based on another’s comments on his plugin submission rejection, the plugin review team also seems to be eschewing any kind of developer-only plugins.
So, as my tweets suggest, I’m a bit bummed about this new(?) direction as it will significantly impact the momentum this plugin has gained.CMB2’s intention was never to “cheat” the system (WordPress or plugin repo), but to instead work within its constraints.
Also, this idea of spurning developer tools and frameworks leaves a bad taste in my mouth. When I think about Powers That Be eschewing developers, I think of Twitter and their charades. I am not saying that’s where we are, but it feels a bit like we’re heading that way.
I care about this for a lot of reasons, but this blog post could become a manifesto, so I’m just going to throw out some points, without trying to make any clear implications/correlations. (read: just trying to get this post out)
- I care about CMB2 and its users. It’s kindof my baby. (From what I read on the internet, you’re not supposed to have feelings about open source software. I’m a rebel that way. :P)
- CMB2 honors WordPress in its spirit — “Democratizes” field/form creation, and lowers the barrier to entry for fledgling plugin developers.
- Sets smart, secure defaults.
- “Just works.” – it’s built to work in nearly any environment and with nearly any data source.
- Backwards compatibility.
- Built to be easy, but more importantly, was built to work ™the right way. For instance, developers can let CMB2 deal with sanitization/escaping.
- CMB2 is built in a way that it manages conflicts automatically. Only one copy of CMB2 is loaded on any given server, and CMB2 handles loading the newest version for you. So you can bundle it and not worry about it becoming ‘stale’.
- Impending CMB2 REST API – adds conceptual WordPress meta API functionality. Could provide valuable precedent and active user base for WordPress core API team to leverage.
- CMB2 is an awesome prototyping tool for all these reasons. With CMB2, get your MVP out the door ASAP (ok enough acronyms).
So what are the next steps? I’m not sure. Would love to get some feedback. I think we have a few options:
- Leave things as-is, and see where it takes us.
- Remove CMB2 from plugin repo. This makes me sad, and it will be a bummer losing the support forum (which, transparently, was definitely one of the reasons we submitted to the repo in the first place). Also losing all those 5-star ratings Michael Beckwith has worked so hard to earn.
- Add a minimal UI to the plugin version of CMB2 to make it more than a ‘framework’. (um, probably no thank you)
- Require developers to use TGM Plugin Activation (also in a state of flux) to require the CMB2 plugin.
- Talk with the plugin review and/or meta teams to see what they would like to see from us.
- Etc?
Again, I’m open to feedback and suggestions. Let me know what you think.
Update: Mika has added a good post to the make/plugins blog which helps clarify the expectations and guidelines. She also added clarification in the comments, so be sure to scroll down and read those.