-
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
Expose Template part block variations to the Inserter #30032
Conversation
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comments are very helpful, thanks for adding them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is how the area is sourced:
gutenberg/packages/block-library/src/template-part/index.php
Lines 54 to 57 in a5395f8
$area_terms = get_the_terms( $template_part_post, 'wp_template_part_area' ); | |
if ( ! is_wp_error( $area_terms ) && false !== $area_terms ) { | |
$area = $area_terms[0]->name; | |
} |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
$default_area_values = array( | |
WP_TEMPLATE_PART_AREA_HEADER, | |
WP_TEMPLATE_PART_AREA_FOOTER, | |
WP_TEMPLATE_PART_AREA_SIDEBAR, | |
WP_TEMPLATE_PART_AREA_UNCATEGORIZED, | |
); | |
/** | |
* Filters the list of allowed template part area values. | |
* | |
* @param array $default_area_values An array of supported area values. | |
*/ | |
return apply_filters( 'default_wp_template_part_areas', $default_area_values ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is how the area is sourced:
gutenberg/packages/block-library/src/template-part/index.php
Lines 54 to 57 in a5395f8
$area_terms = get_the_terms( $template_part_post, 'wp_template_part_area' ); | |
if ( ! is_wp_error( $area_terms ) && false !== $area_terms ) { | |
$area = $area_terms[0]->name; | |
} |
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?
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. |
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. |
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 |
e49900a
to
83fce5a
Compare
It's working with the new format with the rebase :) @gziolo had made the proper transformations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, thank you!
The code looks good to me, using the block attribute only in creation as a bridge to having that term saved with the entity makes sense.
Tested as well and it works great!
Description
Related: #30020
This PR exposes the
Template part
block variation to the Inserter. In order to do that I have created anarea
block attribute in Template Part which is taken into account inisActive
function to find a matching block variation.This new attribute is removed after the actual
save
of 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
area
term allows us to save that value with the template part post type.In block variations
isActive
function first we check forarea
block attribute and if is not there it means that either we have selected the baseTemplate part
block or that it has been created so we try to find a matching block variation from the entity (post type).Testing instructions
Header
orFooter
block from any Inserter (main, slash, etc..)New template part
and observe inAdvanced settings
thearea
. Also that the proper information are shown.Choose existing
and see that thearea
inAdvanced settings
comes from the existing template part.In both cases before you click anything, you can see in the
code editor
that thearea
block attribute is set and after either action from the above, thearea
block attribute has been removed.Screenshots
Removal of the attribute
Checklist: