New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gutenberg integration? #1079

Open
danielbachhuber opened this Issue Dec 22, 2017 · 14 comments

Comments

Projects
None yet
7 participants
@danielbachhuber
Copy link
Contributor

danielbachhuber commented Dec 22, 2017

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

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

@jtsternberg

This comment has been minimized.

Copy link
Member

jtsternberg commented Dec 27, 2017

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.

@jtsternberg

This comment has been minimized.

Copy link
Member

jtsternberg commented Dec 27, 2017

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.

@JasonHoffmann

This comment has been minimized.

Copy link

JasonHoffmann commented Jan 5, 2018

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?

@danielbachhuber

This comment has been minimized.

Copy link
Contributor

danielbachhuber commented Jan 6, 2018

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.

@JasonHoffmann

This comment has been minimized.

Copy link

JasonHoffmann commented Feb 7, 2018

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: #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.

@broros

This comment has been minimized.

Copy link

broros commented Jul 13, 2018

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

@Mte90

This comment has been minimized.

Copy link

Mte90 commented Jul 13, 2018

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.

@Mte90

This comment has been minimized.

Copy link

Mte90 commented Aug 13, 2018

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

@tw2113

This comment has been minimized.

Copy link
Contributor

tw2113 commented Aug 13, 2018

@jtsternberg have you been looking into this at all?

@jtsternberg

This comment has been minimized.

Copy link
Member

jtsternberg commented Aug 13, 2018

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.

@juanpablogdl

This comment has been minimized.

Copy link

juanpablogdl commented Oct 10, 2018

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

@jtsternberg

This comment has been minimized.

Copy link
Member

jtsternberg commented Oct 11, 2018

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.

@broros

This comment has been minimized.

Copy link

broros commented Nov 19, 2018

@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/

@Mte90

This comment has been minimized.

Copy link

Mte90 commented Dec 19, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment