Expose Template part block variations to the Inserter #30032
Conversation
ntsekouras
added
[Feature] Full Site Editing
[Block] Template Part
ntsekouras
requested review from
mtias,
gziolo,
Copons,
david-szabo97 and
Addison-Stavlo
|
Size Change: +27 B (0%) Total Size: 1.41 MB
ℹ️ View Unchanged
|
| */ | ||
| variations.forEach( ( variation ) => { | ||
| if ( variation.isActive ) return; | ||
| variation.isActive = ( blockAttributes, variationAttributes ) => { |
There was a problem hiding this comment.
I know this predates the PR, but the isActive nomenclature is quite confusing to me. What does it represent?
There was a problem hiding this comment.
From the docs:
A function that accepts a block’s attributes and the variation’s attributes and determines if a variation is active. This function doesn’t try to find a match dynamically based on all block’s attributes, as in many cases some attributes are irrelevant. An example would be for embed block where we only care about providerNameSlug attribute’s value.
This is useful for cases you want to use information from the block variation, after a block’s creation. In this case though we have a combination with information from variation and entity attributes (before and after creation).
| const { area, theme, slug } = blockAttributes; | ||
| // We first check the `area` block attribute which is set during insertion. | ||
| // This property is removed on the creation of a template part. | ||
| if ( area ) return area === variationAttributes.area; |
There was a problem hiding this comment.
I like this flow, it should make a lot of things more flexible for full template patterns
| slug: 'template-part', | ||
| content: serialize( innerBlocks ), | ||
| }; | ||
| // If we have `area` set from block attributes, means an exposed |
There was a problem hiding this comment.
The comments are very helpful, thanks for adding them
There was a problem hiding this comment.
This is how the area is sourced:
gutenberg/packages/block-library/src/template-part/index.php
Lines 54 to 57 in a5395f8
It feels like we should make it work similar to the meta in the post content that is stored in attributes and magically saved together with the block to the right place. @mcsf, what do you think?
|
This is looking good to me |
| // block variation was inserted. So add this prop to the template | ||
| // part entity on creation. Afterwards remove `area` value from | ||
| // block attributes. | ||
| if ( [ 'header', 'footer' ].includes( area ) ) record.area = area; |
There was a problem hiding this comment.
There are more values available and they are filterable on the server:
gutenberg/lib/full-site-editing/template-parts.php
Lines 171 to 183 in a5395f8
There was a problem hiding this comment.
Yeah, but we are exposing only the above two in the Inserter (header, footer). When we decide to add the Sidebar we will include this as well. Regarding the uncategorized, is the default if not provided so we don't need anything explicit provided there for the base Template part block.
There was a problem hiding this comment.
Yeah, but we are exposing only the above two in the Inserter (header, footer). When we decide to add the
Sidebarwe will include this as well.
How do you plan to ensure it happens when someone changes the list of block variations? I don't think those two should know of each other. You also need to keep in mind that block variations can be filtered.
There was a problem hiding this comment.
I got what you mean now, thanks for explaining. I removed the check since it is handled on the server and it defaults to uncategorized if the provided value is not allowed.
| slug: 'template-part', | ||
| content: serialize( innerBlocks ), | ||
| }; | ||
| // If we have `area` set from block attributes, means an exposed |
There was a problem hiding this comment.
This is how the area is sourced:
gutenberg/packages/block-library/src/template-part/index.php
Lines 54 to 57 in a5395f8
It feels like we should make it work similar to the meta in the post content that is stored in attributes and magically saved together with the block to the right place. @mcsf, what do you think?
ntsekouras
force-pushed
the
try/expose-template-part-variations
branch
from
0d6d2f4 to
168fd03
Compare
|
Nice work. I think it's the way to go with the current setup of the Template Part block and how the block variations work.
I think this is the part that is a bit confusing because the same information can be sourced from two places depending on the flow. It raises the question of whether we could treat block related entities similar to how blocks can work with a post's meta: It might be impossible in practice to abstract it, but I'm curious what people think. /cc @mcsf, @youknowriad and @ellatrix. |
ntsekouras
force-pushed
the
try/expose-template-part-variations
branch
from
fb15117 to
07fcc58
Compare
|
I followed the testing instructions above and the PR worked well for me with TT1 Blocks. |
|
If I type /footer and then select an existing header template part (listed in templateParts in theme.json), |
|
Thanks for testing Carolina :)
Yes. If we end up wanting to use an existing Template part it should use its own attributes/props. So in your case I guess the
|
They are defined. My test themes templateParts are updated to match this PR: While TT1 Blocks (where, according to above video, it works) uses the old format Could that be it? |
It might be related, @ntsekouras would know better. I opened PR to updated the format in the TT1 Blocks theme last week: WordPress/theme-experiments#232. |
Good catch 👍 It seems so, yes :) - I'll change how this is handled with the new format. |
ntsekouras
requested review from
oandregal,
spacedmonkey and
TimothyBJacobs
as code owners
|
edit: No need to test yet, as a PR was merged 4 hours ago that changed the implementation for getting the template parts, so my code won't work well :). I have to rebase and reimplement |
ntsekouras
force-pushed
the
try/expose-template-part-variations
branch
from
e49900a to
83fce5a
Compare
|
It's working with the new format with the rebase :) @gziolo had made the proper transformations. |
Description
Related: #30020
This PR exposes the
Template partblock variation to the Inserter. In order to do that I have created anareablock attribute in Template Part which is taken into account inisActivefunction to find a matching block variation.This new attribute is removed after the actual
saveof the Template part and is only used for the Placeholder/insertion part for various reasons like passing this value to the Template part entity, proper display information in BlockCard etc...It is removed because the Template part block renders its own entity internally. Any attributes on the outer block itself are just block attributes, and thus saved as part of the post it is a child of (template, page, etc). The
areaterm allows us to save that value with the template part post type.In block variations
isActivefunction first we check forareablock attribute and if is not there it means that either we have selected the baseTemplate partblock or that it has been created so we try to find a matching block variation from the entity (post type).Testing instructions
HeaderorFooterblock from any Inserter (main, slash, etc..)New template partand observe inAdvanced settingsthearea. Also that the proper information are shown.Choose existingand see that theareainAdvanced settingscomes from the existing template part.In both cases before you click anything, you can see in the
code editorthat theareablock attribute is set and after either action from the above, theareablock attribute has been removed.Screenshots
Removal of the attribute
Checklist: