Based on new developments, we should use TGMPA to bring in CMB2

[jtsternberg]

Based on developments here and here, I think we should avoid using composer or directly including CMB2 bundled into the plugin and instead depend on TGM Plugin Activation.

The TLDR of the links above:

• New frameworks are no longer allowed in the repo. CMB2 will be allowed to stay however.
• since CMB2 will be staying in the repo, other plugins cannot bundle it within their own plugins (to be accepted to the WP plugin repo), because plugins are not (any longer) allowed to bundle other plugins that exist in the repo.
• As such, the recommended practice is to require the plugin via TGMPA.

I didn't create a PR yet because I want to make sure we're all on the same page, and hear any feedback.

[jazzsequence]

Justin --

We discussed on the dev call today building a project boilerplate for mu-plugins like what we used to have when wd_s was a boilerplate for entire projects instead of just a theme boilerplate.

Is TGMPA something that should be included in this? Can we talk about this next week on the dev call maybe?

[blobaugh]

Yes! TGMPA all the things!

@jazzsequence it should definitely be in the boilerplate

[modemlooper]

A lot of devs like including it, you are going to get backlash. Plus now they will have to include TGMPA instead

[blobaugh]

@modemlooper could you be more specific? TGMPA is becoming a good standard. What backlash are you expecting?

[jtsternberg]

@modemlooper not really concerned about backlash at this point. Devs can still include it if they're building anything commercial or not hosted on wp.org, but if it's going on wp.org, they can't do it anyway, and their backlash should be directed elsewhere. If a dev wants to use this generator AND bundle CMB2, I don't think that's a blocker.. we all know how to unzip a file and include init.php.

[JayWood]

If, and only if we're going to add plugins to repos, then I'd say TGMPA - or our own method if need be, otherwise, if it's purely commercial and won't be in a .org repo, include it.

Short of it, one less thing to worry about activating/deactivating, besides, most projects we keep CMB2 in mu-plugins anyhow.

[modemlooper]

I agree with TGMPA, just noting that if you were bundling before and now you have to switch it will cause a few people to be upset.

[jtsternberg]

Like @JayWood said, we keep CMB2 in mu-plugins or use our required plugins plugin to make sure the CMB2 plugin is included, so this change will keep us from adding one more (fairly large) piece of cruft from our generated plugins.

[JayWood]

Honestly don't know how I feel about it being in the plugin generator though, not all plugins we write require CMB2, maybe do it as a sub-generator if possible where it will auto-download CMB2 to the plugins directory or something and put in the necessary hooks?

[jazzsequence]

If we're using TGMPA for things, that's a great argument for maybe doing something with it in the plugin generator. Agree that we don't always need CMB2 in all generated plugins, even those that use it (because of required plugins plugin or it's in mu-plugins or whatever).

On the other hand, there are times when we do need CMB2 bundled in the plugin -- e.g. when we're prepping a plugin for release. So, easy solution for that is to not bundle things like cpt-core, taxonomy-core, CMB2 in the generated plugin by default but if the new release function is initiated, and we're using something that might need any of those packages, they get pulled in at that point when the release is created (e.g. if we used the generator to create a cpt, taxonomy or options page).

In that case, I'm not sure we need TGMPA support built into the generator but I'd be interested in seeing what that looks like, it's been a while since I looked at that library.

[CamdenSegal]

We have had a plugin published to the WordPress plugin repo with CMB2 included using the generator's method. I think switching the generator to TGMPA is not necessary. CMB2 is the only library included by the plugin which is in the .org grey zone of being a code library and also a plugin.

While the generator is used frequently internally, where we could easily use TGMPA or just have all the libraries installed by default, I do not want to make a change that would significantly reduce the ease of use outside of WebDev.

TGMPA is a neat system for handling plugin dependencies, but also I think problematic for plugins intended for the .org plugin repo.

I'm definitely up for continued discussion, but I think the current system is still the ideal solution.