Cmb2: Gutenberg integration?

Created on 22 Dec 2017  ·  21Comments  ·  Source: CMB2/CMB2

Any ideas for or plans as to what CMB2 integration with Gutenberg might look like?

I'm currently researching for https://github.com/WordPress/gutenberg/issues/4151 and would love to tap into any existing discussion that's been had. I see https://github.com/CMB2/CMB2/issues/1030 but it doesn't look like that made it past the initial posting.

Most helpful comment

I've been thinking about this a bit as Gutenberg starts entering its final stages.

One of the things that you may want to do is create a separate, modular (most likely an NPM module) JS library that replicates all of the CMB2 field types as very, very customizable Gutenberg blocks. Basic blocks like a single text one, a color picker, etc.

Then, you can use the current CMB2 registrations to create a big JS object (Or a an even better abstracted data structure as suggested here: https://github.com/CMB2/CMB2/issues/1030) that automatically gets converted into meta blocks, using that separate NPM library to create all the blocks. The bonus is that library could also be used by standalone by other developers to import those customizable blocks and use them elsewhere on their projects.

I know the Gutenberg team is still figuring out a few things, like nested blocks and advanced block templates, so it may be possible to actually use default core blocks for some of the CMB2 field types. In my head, this gathers a lot of inspiration from https://github.com/youknowriad/gcf and would work in a similar way except blocks would be registered automatically.

I do have a few concerns though.

  • Should registered CMB2 blocks automatically be converted to Gutenberg blocks? Or should it be opt-in
  • How can we make sure that meta Gutenberg blocks _always_ render in the editor on existing content (Block templates only work for new posts)
  • Really not sure how to handle groups
  • Basically every current hook and callback would be rendered useless since it will all move to JS
  • There are a lot of custom field types that we would not be able to register properly.

I'm sure there's more. Ultimately, I'm not exactly sure how to do this and maintain backwards compatibility fully. But I figured I could at least kick off a discussion.

All 21 comments

I do have some ideas, mostly around keeping the CMB2 registration API, but updating the render API to be JS-based. My hunch is we may want to fork for this, rather than maintain the back-compatibility. Unfortunately my time has been quite limited lately, so I have not been able to put as much time/thought into it as I'd like.

As far as hooking into Gutenberg, my thoughts are to make the field API very flexible to be able to be used for custom blocks, or for the extra meta drawers.

Would the goal be to take fields registered via the field API and dynamically generate JS for registerBlockType, sort of like what's done with the customizer?

Would the goal be to take fields registered via the field API and dynamically generate JS for registerBlockType

As it makes sense to, I think. Some fields could remain in meta boxes, while others would make sense to move to blocks.

I've been thinking about this a bit as Gutenberg starts entering its final stages.

One of the things that you may want to do is create a separate, modular (most likely an NPM module) JS library that replicates all of the CMB2 field types as very, very customizable Gutenberg blocks. Basic blocks like a single text one, a color picker, etc.

Then, you can use the current CMB2 registrations to create a big JS object (Or a an even better abstracted data structure as suggested here: https://github.com/CMB2/CMB2/issues/1030) that automatically gets converted into meta blocks, using that separate NPM library to create all the blocks. The bonus is that library could also be used by standalone by other developers to import those customizable blocks and use them elsewhere on their projects.

I know the Gutenberg team is still figuring out a few things, like nested blocks and advanced block templates, so it may be possible to actually use default core blocks for some of the CMB2 field types. In my head, this gathers a lot of inspiration from https://github.com/youknowriad/gcf and would work in a similar way except blocks would be registered automatically.

I do have a few concerns though.

  • Should registered CMB2 blocks automatically be converted to Gutenberg blocks? Or should it be opt-in
  • How can we make sure that meta Gutenberg blocks _always_ render in the editor on existing content (Block templates only work for new posts)
  • Really not sure how to handle groups
  • Basically every current hook and callback would be rendered useless since it will all move to JS
  • There are a lot of custom field types that we would not be able to register properly.

I'm sure there's more. Ultimately, I'm not exactly sure how to do this and maintain backwards compatibility fully. But I figured I could at least kick off a discussion.

keeping backward compatibility is a bad idea, just fork it and rename CMB3 for Gutenberg release.

Well we need a little bit of backward compatibility or it will be an another framework.
Maybe add a parameter like gutenberg on true that enable it on the gutenberg editor can be a workaround and for the old document how to update them to support the gutenberg by field type.

Just a ping to see if someone worked on something.
Maybe we can ask to the community to add the support and do promotion?

@jtsternberg have you been looking into this at all?

I have not had the opportunity to start work on this, and would love some community contribution. I really like the path ACF has taken with configurable blocks, and would love to do that with CMB2, using the existing box/field registration API.

Using the same approach as ACF did is a great idea, I want to be part of this

I haven't had time in the last several months to really start throwing something together. If anyone is interested, getting a proof-of-concept PR together would be a huge first step.

@jtsternberg The meta box API isn’t being deprecated but there’s also no clear path forward for how Gutenberg will support “legacy” PHP meta boxes.

we need to use blocks api https://wordpress.org/gutenberg/handbook/block-api/

I tested CMB with Gutenberg on my plugins and seems that everything is working but I didn't tested all the fields.
As plugin developer for me and I guess for many others is important to know if this project support the new UI with the default fields at 100%.
There is someone that can confirm that?
Because I think that if we have a gutenberg supported this ticket can be closed.

Has there been any progress on this anywhere?

Not really that I've seen @noplanman but there also hasn't appeared to be any need either. At least not on a compatibility front.

CMB2 works out of the box with Gutenberg as a way to manage post meta/custom fields. A more integrated solution (like incorporating CMB2 fields within Gutenberg blocks) is a much larger task and I don't believe that's on the roadmap at the moment (unless someone wants to take ownership of that undertaking).

What I have is a situation where I use CMB2 to create templates for content, which can then be applied to the post content via metabox buttons.

With TinyMCE / WYSIWYG editor this works perfectly, as it simply replaces the content.

Using Gutenberg however, it isn't the same, as the HTML block type just doesn't play nicely.

It would be perfect it there were a CMB2 field type which was a Gutenberg editor and then saves the actual block content, which could then simply be replaced in the post.

Does anybody have an idea how best to solve this?
Is there maybe an easy way to automatically convert HTML into blocks?

Of course it would really be great if the saved template would be inserted verbatim into the content box.

I am curious if the classic editor block would work for you, if anything it'd get TinyMCE back again. Otherwise, this type of usage sounds like a lot of customization that's just happening to use CMB2 for some of it.

We would need to add block building capability to the library just to get block integration in general, but then we'd need to find a way to tie that in with whatever integration from CMB2 fields as well. I'm doubtful we want to try and go down that hole in the core plugin, but perhaps it could be done as an extension/addon.

Is there maybe an easy way to automatically convert HTML into blocks?

No, there's not an easy way, in Gutenberg every element is a block and your custom element must be a custom block as well, you can try to convert your HTML into block but it is not assured you have a good result, maybe some block will break, you can follow the handbock on how to transform html into block https://developer.wordpress.org/block-editor/developers/block-api/block-transforms/

Here there is an interesting uses case in transforming an older content into block https://css-tricks.com/wordpress-block-transforms/

Thanks for the input, I'll see what I come up with and how much will actually be necessary in the end.
Other option is to just define the limitations and stick to them :wink:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

noquierouser picture noquierouser  ·  8Comments

abuyoyo picture abuyoyo  ·  7Comments

apokyro picture apokyro  ·  5Comments

DevinWalker picture DevinWalker  ·  4Comments

stabilimenta picture stabilimenta  ·  8Comments