[PoC] Patterns: try partial syncing of inner blocks #56348
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
glendaviesnz
added
[Type] Enhancement
glendaviesnz
requested review from
spacedmonkey,
ellatrix and
ajitbohra
as code owners
|
This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress. If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged. If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack. Thank you! ❤️ View changed files❔ lib/experimental/blocks.php |
|
Size Change: +93 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
glendaviesnz
commented
Nov 21, 2023
| @@ -153,6 +154,12 @@ function gutenberg_render_block_connections( $block_content, $block, $block_inst | |||
| $attribute_value['value'] | |||
| ); | |||
|
|
|||
There was a problem hiding this comment.
The following will need some work. Currently, there is no common attribute that identifies what the outer wrapper tag is across blocks using innerBlocks. This currently just gets the first tag in the content, which works for lists, but may not for other blocks, so we may need to add an additional attribute to the blocks to clearly identify the innerBlocks wrapper.
|
The key things that would need to be worked through with this approach:
|
This was referenced Nov 21, 2023
|
@gziolo, @SantosGuillamot just an FYI - although the initial release of partial syncing may not included innerBlocks we wanted to check that there were at least some ways forward to allow for this. While this PR may not end up as part of the final solution, it does seem to indicate that it will be possible to scale the connections approach to allow for innerBlocks. |
|
It looks promising. Probably need to think about how the data is serialized, as it seems as the moment the block markup is stored? I think that's something that would have to change, as otherwise there's a mix of data types being pushed into dynamic data (json style data for normal blocks, and serialized html for inner blocks). If it were just an array of block types and the subset of attributes that seems pretty close, and that approach might also work for other block binding types like custom fields. The other part to think about is how the user might configure this, especially as patterns and custom fields will have different UIs for declaring bindings. |
|
Also worth noting some other constraints with this approach:
|
The problem with innerBlocks is that the block type and attributes are enough on the editor end, but not enough in order to get the html block content on the server for static blocks as we don't have access to the save function. The only way I could see for this to work on the server end was to save the markup - but I agree it would be nice if there was another way! |
Yes, this needs a bit of thought about how the locking mechanisms might need to be extended to allow more fine-grained control about what can and can't be edited with container blocks. |
I would imagine using the same mechanisms that block bindings do use—saving the markup and using the HTML API to rewrite parts. You end up with the same complications we have for block bindings generally—what happens when blocks are rearranged around and might mismatch the content data, but this is a problem already being solved. You could start thinking about the problem as though there are possibly two different ways for inner blocks to work in a partially synced pattern:
|
That is essentially what is being done on the frontend, the block markup is parsed to straight html and inserted in the content using the HMTL API. The complication with innerblocks is we need to be able to regenerate potentially complex block structures for the editor context, which would be a bit of a mission if all we have is the html markup. One alternative would be a json structure that has the block attributes for the editor context and an Having either the block markup, or block attributes saved for innerblocks rather than just the markup also partly gets around some of the issues with block changes as migrations/deprecations will run I think when the blocks are reparsed in the editor. Once we get some more of the simple connections work done and circle back to this it should be reasonably easy to experiment with a few different approaches to storing the innerBlocks changes. When we get to that point then looking at it from the two angles you mention will be useful I think. |
kevin940726
force-pushed
the
try/partial-sync-no-monkey-patching
branch
from
6befb37
to
dc91763
Compare
|
How could be the same case implemented if we were to introduce a new Repeater block that would have to be used inside Block Patterns whenever we want to allow multiple instances of the same block? Examples in pseudocode: <List>
<Repeater min="2" max="5">
<ListItem />
</Repeater>
</List><Gallery>
<Repeater min="4">
<Image />
</Repeater>
</Gallery>What other use case would you like to cover? |
Interesting idea, will circle back and take a look at that once we have the simple content cases implemented. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
This is an exploration to see if it will be possible to partially sync a block that has innerBlocks as part of the work around #53705.
Why?
The initial work around partial syncing is focusing on simple block content like a paragraph's content attribute or an image's src. but we need to make sure that the APIs being used to this will scale to allowing blocks with innerBlocks content to also be partially synced.
How?
Uses the handling of the patterns innerBlocks implemented in #56235 to detect changes to a patterns inner blocks and save the serialized changes into the patterns attributes
Testing Instructions
Pattern attributesThis is a very rough prototype, and will most likely have bugs 😄
Screenshots or screencast
partial-inner.mp4