Add edit template part menu button #34679
Conversation
| const templatePart = templateParts.find( | ||
| ( part ) => | ||
| part.theme === block.attributes.theme && | ||
| part.slug === block.attributes.slug | ||
| ); |
There was a problem hiding this comment.
It feels a little bit weird to have to do this to find the id of the template part. Maybe we should make this a selector? Or is there other API for this?
There was a problem hiding this comment.
It looks like template part CPTs have a fixed "$theme//$slug" ID structure so this should do the trick:
const templatePart = select( coreStore ).getEntityRecord(
'postType',
'wp_template_part',
`${ block.attributes.theme }//${ block.attributes.slug }`
);There was a problem hiding this comment.
That feels like an internal implementation though which I'd like to avoid relying on. Unless it's being documented somewhere 🤔 ?
There was a problem hiding this comment.
There's already precedent for doing this in the codebase (e.g. TemplatePartEdit) and turns out there's actually a documented helper we can use.
There was a problem hiding this comment.
The helper is not exposed though. Could it be easier if we just expose the templatePartId in block's attributes? So that we can just compare by ids rather than have to compose them first.
There was a problem hiding this comment.
But it's redundant to have both id and part+slug attributes in the Template Part block, though, no? They will contain the exact same data.
I think it's okay to rely on the ID being in this format. It's not an implementation detail as it's exposed in the public REST API. There's precedent already because TemplatePartEdit does exactly what we're doing here: it builds an ID from part and slug and passes it to getEntityRecord.
By using getEntityRecord instead of getEntityRecords we're not unnecessarily fetching all template parts from the REST API.
Arguably createTemplatePartId could live in @wordpress/core-data.
There was a problem hiding this comment.
Oh right, we can use getEntityRecord directly! I'm not sure where to put that createTemplatePartId though, it seems less "data"-ly to be put in core-data. I just inlined it here and added a comment.
|
Size Change: +14.7 kB (+1%) Total Size: 1.06 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
It works 🥳 Couple of minor things:
Since "template part" is a technical (and potentially confusing) term, we can probably go ahead and use the template part name in the menu label. IE "Edit Header" instead of "Edit Template Part".
I would also suggest placing the "Edit" menu item before the "Detach blocks from template part" menu item as I suspect editing will be a more common action.
Makes sense to me! Although the term already exists in the sidebar menu though. Are we planning to change that in the future too? |
I believe there is still quite a bit of design work to be done around navigating the site editing flows, so I would imagine it is possible. For example I have seen some explorations that just display the taxonomies (headers, footers, sidebars, etc). Thanks for the update, I noticed that we're using inconsistent text case when displaying template part names, but we can address that separately. I'm not sure we need the quotation marks. One final question – I'm only seeing this menu in the Site Editing context, should it be in the template editor too, or will that come later? |
| const templatePart = templateParts.find( | ||
| ( part ) => | ||
| part.theme === block.attributes.theme && | ||
| part.slug === block.attributes.slug | ||
| ); |
There was a problem hiding this comment.
It looks like template part CPTs have a fixed "$theme//$slug" ID structure so this should do the trick:
const templatePart = select( coreStore ).getEntityRecord(
'postType',
'wp_template_part',
`${ block.attributes.theme }//${ block.attributes.slug }`
);
packages/edit-site/src/components/edit-template-part-menu-button/index.js
Outdated
Show resolved
Hide resolved
I'm just copying it the design of the back button 😅, but I agree it feels a little weird as it's not clear what the quotation is for. I'll remove it for now.
What do you mean by the template editor? Do you mean the one in edit-post? |
Yeah that's the one. I'm able to view and interact with template parts there, so I should probably be able to focus (isolate) them too. |
Cool, I think that was brought up in #29148 (comment). It's still not clear how it should work in practice though, I'd say let's add this first in the side editor and iterate? |
|
As discussed in #34732 it would be interesting to try a slightly different design pattern in this context which enables us to circumvent the awkward "<- Back" button for navigating between template <> template part, and hopefully add some clarity to the overall template editing experience. Here's a video: editing.a.template.part.mp4Figma prototype here. Notes:
In the future we can apply this pattern to entities inside template parts (like the navigation example in the prototype). But that's something we can explore in more detail later. |
|
@jameskoster let's leave that for the flow of editing templates in general, we still need all the pieces for the "isolated mode" in place to handle direct links to edit header, navigation, footer, etc. Variations on "spotlight" we can break them up separately. The fading out has proven tricky on anything that had a different background than white, for example. |
Description
Related to #33926. Addresses the following.
Design is in #29148 (comment) 's video.
How has this been tested?
Screenshots
Kapture.2021-09-09.at.14.25.10.mp4
Types of changes
New feature
Checklist:
*.native.jsfiles for terms that need renaming or removal).