Posted on March 1, 2016
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.
I wish you’d just dropped plugins a line. We would have been happy to explain. You were approved by accident. We have not been allowing new frameworks or libraries in for about 3 years now. That’s our fault. You did nothing wrong.
1. LIBRARIES, which is actually what cmb2 is, are problematic as stand alone plugins. We have always felt that they should be included in the plugin itself. Just like jquery css, just like the aws-sdk.
2. Plugins are supposed to be functional. That is they do a thing. Cmb2 is not. It is something upon which you build a thing.
3. We allow developer plugins. See ‘Query Monitor.’ That’s dev only :) We don’t allow plugins that require people to edit code, or are solely there to be dependencies.
4. When you have required plugins, end users have often gotten confused about why this other plugin that they don’t use has to be installed and active, delete it, and break sites.
It’s really just that.
Thank you for responding Mika, and apologies for not dropping the plugins team a line. Honestly, I wasn’t sure who, how, or where this should be approached.
Any time anyone has a question, you can email us 24/7 at plugins@wordpress.org :) We even put the email in the header on make.wordpress.org/plugins
Plugins are for users. Not developers. That’s the crux of our stance. As a user, I shouldn’t have to care if the dependent plugin is installed at all. And from that end, a plugin that is only a platform on which a theme or plugin is built, shouldn’t be in the repo.
Yet.
One day? God, I hope we can sort out a WordPress ‘library’ repository. A standard place for plugins to pull in requirements like jquery css and aws and a million other libraries. Wouldn’t that rock? But we aren’t there yet.
Honestly, the thing I love about Cmb2 is that you made a perfect library that, in the non-composer world of development, made it nigh impossible for users to screw up dependencies. What I hate is seeing someone use cmb2 when their own plugin is ten lines. But that’s them not understanding libraries and weight.
If you want people to require your plugin as a dependency, leave it where it is. If you want them to include it as a library, it shouldn’t be in the repo. Right now, we can’t do both.
Thanks again Mika, your response is a perfect one, and I appreciate you taking the time out of your busy morning to check in and help clarify some things. Your feedback will definitely help us as we determine what the next steps are.
I only have one final (and maybe redundant?) question. If we leave CMB2 in the repo as it is now, can it remain their forever? Will it have immunity? :)
I ask because, again, I just want to find the best way forward. If leaving it in the repo is only a temporary solution, then it’s probably best we bite the bullet and figure out the new path.
You’re in and it’s not your fault we goofed and approved it. So you can stay in if you want, of course.
If it had been a couple weeks before we noticed, it would have been different. It’s MONTHS. That’s totally, 100%, our screw up. It can stay.
Ok, thanks again!
Mika, could you expand on this? Why do you hate seeing that? My assumption is that without CMB2, their plugin would of course be many more lines… so what’s wrong with using a library to enable something like a 10-line plugin that does something useful?
I think the general idea is that it’s overkill to include a big library to add a single metabox and field (or something like that), which I agree with. That definitely gets into the much bigger conversation about the merits of frameworks, which is probably outside the scope of this discussion.
Pretty much that. But that’s my personal opinion. I won’t punt your plugin if thats what you want to do. I just ‘tsk’ and shake my head.
I would argue that if a framework enables me to write a plugin in 10 lines that utilises a framework so efficiently that my plugin actually passes the .org plugin guidelines, this can mean two things. Either the plugin guidelines (there is a rule that defines the minimum functionality, if I recall correctly) are terrible, which they are not, or the framework code is very well structured and easy to use.
The problem here is not the bundling of libraries. This is actually a really good thing. Code that I’m bundling, is not my responsibility. I have less code to maintain, assuming the library itself is well maintained and tested. This is also a group effort really, as all developers who implement the framework can contribute back to it. Any fixes, improvements or new features will benefit all the plugins that implement the framework.
This is not overhead. This is what dependencies are designed to do. I write PHP apps of just a handful of controllers and models, based on the Laravel framework. Laravel itself pulls in a ton of Symfony components and so on. All this enables me to quickly write web apps that do what I want them to do and I get to use all this awesome code that is already available. My web apps are sometimes maybe 1000 lines, while all the bundled components are much – MUCH – more code.
The biggest problem (at least in my opinion) with the WordPress ecosystem is the whole dependencies thing. Something like CMB2 would be a perfect dependency for a lot of plugins. Making it a dependency that is easy to bundle, easy to maintain and update, is a pain in WordPress right now. The focus on ‘always run the latest and greatest version’ and ‘never make it impossible for users to update’ is great and all, but we can’t continue to do this without solving the dependencies problem.
Effectively rolling out updates of dependencies and resolving conflicts is the hard part of this puzzle. That’s what we need to solve in our own WordPress-y way.
Composer has solved this problem for the PHP ecosystem in general. I’d like to see ways that we can use Composer in our ecosystem as well. If that’s impossible, we should look at how Composer solves the problems it solves and mimic that in our own way for just the WordPress ecosystem. This will greatly benefit the end users as well, we just need to figure out a way to make this as user friendly as possible.
I put this same comment in a little more detail on my own blog: http://coenjacobs.me/2016/03/02/bundling-libraries-is-not-overhead-its-a-best-practice/ This topic deserves far more attention than it is currently getting.
I would like to question 2 points.
1. Who says plugins are for users and not for developers?
First of all developers are users.
And of course not all users are equal nor should they be.
Plugins have varying degrees of technical skill requirements and that’s a good thing.
2. If you don’t like a plugin that uses 10 lines of code and includes CMB2 then reject it not CMB2. How many of these plugins actually exist?
I would tend to agree with your first point, but on your 2nd point, Mika has already said they won’t be rejecting CMB2 at this point.
You’re conflating what I (as a human) dislike, and what I (as a repo moderator) permit.
1. The plugin teams say plugins in the WordPress Repository are for users. At the risk of sounding like a parent, the answer is ‘because that’s what we decided.’ Plugins in the repo should be for end-users. And some are more technically complex than others, but all are ‘functional’ on their own.
2. Justin was correct when he said my issue with the 10-line plugin using CMB2 is overkill. I feel it’s poor design. But that’s not a reason to reject the plugin if the 10 lines do exactly what they say they do, and do it safely and sanely.
Even if CMB2 is pulled from the repo (by yourself), I still believe it to be one of the most solid metabox frameworks out there and have evangelized CMB2 wherever and whenever I can. It still has legs to run on, even if outside of the repo.
With that being said, i find it to be more of a developers tool, and plugins in the repo tend to fall under end user tools. One potential soltuion could be similar to how custom post type ui is handled, where the version in the repo is packaged with some sort of user interface (gui), while the standalone framework on github would remain how it currently sits.
Obviously this has its drawbacks as you’d now be forced to maintain two entities instead of the one, but you wouldn’t end up losing out on your reviews, the support forum and the SEO the repo brings. You could potentially onboard some new users with an interface, as well.
Just a thought, but I’m watching this closely to see how things play out. Good luck, Justin – and thanks for all your work on CMB!
Thank you for the feedback Evan!
Can CMB2 be in Core at some point? Or is there better field API coming already.
There IS a Fields API coming to core, hopefully soon, so that is awesome. But, I don’t believe it will be able to replace CMB2 completely.
That’s correct, Fields API can’t really replace CMB2 and a few of those other solutions out there that offer a broad range of functionality for many use-cases. Core is really only interested in the main use-cases and most needed. That’s fine for me, I would love to cover more ground but I won’t get greedy :)
Excited to see what we can do with CMB2 powered by Fields API in the future, but that’s definitely a year or more away since CMB2 would at some point have to require a minimum WP version that includes Fields API in core.
You mentioned TGMPA, and we’re one step further on and one step further away.
We’re not yet a plugin, but if we were, we’d have to become a featured plugin to be allowed into the WP repo. That in itself requires a big shift (and a known rewrite).
Saying that, the WP theme repo, Theme Forest and Code Canyon all list TGMPA as a solution for a theme or plugin requiring other plugins.
At the end of the day, while it’s not a great situation, the Plugins team is at least being consistent between TGMPA and CMB2 :-)
Gary, would you recommend CMB2 add-on plugins use TGMPA to require CMB2? I know it’s undergoing some changes, which is why I ask.
TGMPA fully supports plugin B saying that plugin A is a requirement to have installed and active, so yes, they could to that.
I’ve used CMB2 for quite a while. I’ve bundled it with a repo plugin (before CMB2 was in the repo) and with a client plugin. Once CMB2 was in the repository, I rejoiced and unbundled it. Since then, I’ve just made it a requirement for my plugins (thank you, TGMPA).
Having CMB2 in the repository means that I can let y’all do your work and keep making it awesome, and I don’t have to worry about making sure my copy of it is up to date, which is pretty much impossible when clients are former clients. It also makes my plugin much leaner (possibly deceptively, but still).
If a user mistakenly removes CMB2, they’ll lose the metaboxes in the admin, but since all of the fields are retrieved on the front end using core functions, the site won’t break. This is, for me, a key difference between CMB2 and ACF (I know I can pull those fields using core functions, too, but the documentation doesn’t push you that way).
Even though it may have been a mistake to include CMB2 in the repository, I (for one) am very thankful it’s in there, and I appreciate that the plugins team will leave it be.
Justin (& co), I appreciate your hard work on CMB2, and how helpful it’s been to me; it’s made a lot of the client work I do so much easier.
Robin, that is so awesome to hear, and I/we really appreciate your feedback!
OMG such a great point about ACF and other plugins that require you use their functions, very good point! I think you did it the right way :)
I think we should stop spoon feeding users. If a user is using WordPress as an administrator then they must be at least slightly technically-minded.
Henry,
This argument was lost years ago. As long as WordPress’ core goal is to democratize publishing, the users will always be first.
What I’d really love to see is better developer tools– like dependency support in core. But it seems like most things getting added core have to pass the “does it benefit the user and/or wordpress.com” litmus test. I don’t see a roadmap for dependency support anytime soon.
Ryan,
I get that authors and editors might not be interested in the technical side of publishing but in this case we’re talking about administrators, the people who look after the system. This type of user _should_ be more technologically-minded although I do realise this might not always be the case.
Pingback: Bundling libraries is not overhead, it’s a best practice – Coen Jacobs
I think there’s another ideological point to consider here.
CMB2, and similar tools, build on top of native WP functionality. The fact these tools exists, and in use by so many, suggests that maybe that native functionality isn’t sufficient in its current form. I know the Fields API is looking into part of this, but being able to just have my plugin return an array to WP core with values for what metaboxes there are, what fields they should contains, and where those boxes should appear, would go a long way to sorting this particular dependency issue out.
That’s right Gary, Fields API is exactly what solves the root issue, which should cover many use-cases. However libraries like CMB2 can extend it and make it do even more, which would still be useful for many plugin devs and theme devs to make use of depending on what they’re doing. So this particular dependency issue for CMB2 will remain for a period of time until people begin adopting Fields API (once in core), but it’s certainly not the only case of such a need in plugins — but I would definitely bet it’s the biggest case.
Needing a custom meta box / custom field API to work with to abstract all the weird things you have to do on your own in WP right now is so very common, in fact people roll their own before they realize they could use a library instead. Fields API aims to solve a big segment of these folks needs’, but dependencies won’t go away, I can’t tell you the countless plugins built that require Pods on various client sites all over, all they can do is check if Pods is activated and if not then throw an error message in the admin and just not load / function.
Dependencies are real :/
Pingback: CMB2 & the WP REST API | briancoords.com
Pingback: Carbon Fields distribution woes – Carbon Fields
Huge fan of CMB2 here. I hope that the future is bright for CMB2 and the community that has grown around it.
I’ve always viewed CMB2 as more of a library than a plugin (especially because of the loading mechanism it uses), but thought it was cool that it was in the .org repo because it seemed to expose the project to a broader audience.
If keeping the plugin in the .org repo precludes it from being allowed to be integrated within plugins or themes, that would be a deal breaker for me. Keeping it on github would be just fine in that case. Still a bummer of a policy though.