-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Using InnerBlocks with post meta storage #10745
Comments
Does #6751 (comment) help you? Or is it different because it's a save function and not an onChange? |
Hey @designsimply, unfortunately that doesn't help, at least as best I can tell. |
Okay! Sorry it didn't. We'll want to wait for input from someone who's a bit more knowledgeable than I am on the subject. 😊 |
I think you should be using the block editor module directly to perform this (build an editor inside an editor). We have some documentation here. https://wordpress.org/gutenberg/handbook/designers-developers/developers/packages/packages-block-editor/ With this package you pass a list of blocks as an array and retrieve and array. You can decide to serialize/parse the blocks using (this package will only be available in WordPress 5.2). |
The block editor module looks very interesting, and I look forward to getting my feet wet with it! I see a lot of potential. And while I agree that it provides a roundabout solution to this problem, I don't agree that it resolves this issue. From a developer's experience perspective, that seems like a fairly complicated abstraction. To summarize why that is,
However, if I want to merge (1) and (2) and have a custom block that provides a block editing environment saving to post meta, now I have to write a significant amount of code and jump through some fairly complex hoops (especially as it pertains to no registered block types, from the sounds of it). As a developer trying to build complex interfaces in Gutenberg, this is a relatively common scenario for me, and I would expect it to be roughly no additional work. |
Sorry for the late response. The Block editor already provides a high number of APIs, and adding APIs is not always a good solution because of the fact that for each added API, we need to maintain it forever, so adding APIs is a very deliberate decision. You can also take a look at the reusable block's implementation https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/block/edit.js#L134-L143 which does exactly what I proposed above. I don't think it's too much code, or complex code to be honest and I don't feel like it's a very common scenario for all block editor users. |
@youknowriad I personally don't feel like that is an additional API. InnerBlocks are a core concept as well as the meta source. Hence, in my opinion, these two should work together. I've also just encountered this problem myself. |
@youknowriad This is something I just encountered as well. While it's not impossible to utilize the extra implementation as you said, I'm questioning the logic of just not including this in core. You said yourself it's not much or complex code; that negates the point that this would be a fully-fledged API that is difficult to maintain. |
Can we re-open this issue? I completely disagree @youknowriad that " [It's not] a very common scenario for all block editor users." Being able to add content before and after the main content area (like what the native Title block does in the editor) is super important for making the gutenberg experience well rounded. There are so many applications to this that I can think of, that are currently bottlenecks in transitioning to Gutenberg. |
@mboynes Seeing as you were asking this around 3 years ago, I am curious if you arrived at any solutions for this? Thank you! |
Is your feature request related to a problem? Please describe.
I attempted to build a custom block which uses the
InnerBlocks
component and which stores its content to post meta. I could not find a straightforward way to do this; it appears thatInnerBlocks
will always save to post content.Describe the solution you'd like
From my perspective, one high-level approach would be that the
InnerBlocks
component would allow for anonChange
prop, or similar, which would allow a custom block to easily callsetAttributes()
to storeInnerBlocks.Content
. There would also need to be a way to passInnerBlocks
the contents/value from attributes.The text was updated successfully, but these errors were encountered: