-
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
Patterns: Avoid mapping template parts objects to patterns #62927
Patterns: Avoid mapping template parts objects to patterns #62927
Conversation
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Size Change: -14.6 kB (-0.83%) Total Size: 1.75 MB
ℹ️ View Unchanged
|
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'm not sure what to test specifically. Do we have e2e test coverage for template parts/patterns?
I did get a warning react-jsx-runtime.development.js:87 Warning: Each child in a list should have a unique "key" prop.
when loading the "all template parts" page.
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 LGTM and seems to work well! The test failures seem related though..
canvas: 'edit', | ||
} ); | ||
const title = decodeEntities( defaultGetTitle( item ) ); |
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.
Nice catch 👍
Before:
Gravacao.do.ecra.2024-06-28.as.13.34.54.mov
After:
Gravacao.do.ecra.2024-06-28.as.13.32.12.mov
categoryId, | ||
search | ||
); | ||
return selectTemplateParts( select, categoryId, search ); |
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've only found two uses of the usePatterns
hook:
- One is in the page-patterns screen, also adapted in this PR.
- The other is in the sidebar, that doesn't need any adaption as it's only used to retrieve data from patterns but not from template parts post types (what is being modified in this PR).
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 presume that, back in the days, the usePatterns
hook was created as a way to avoid if conditions in the page (rules of hooks) and also to provide a stable structure to consumers (sidebar, page) independently from where the data came from. It seems to me the consumers still do a lot of data wrangling depending on the type, so not sure how effective this has been for the second goal.
It'd be good to rename it to usePatternsOrParts
of something similar for clarity at some point: not a requirement for this PR.
theme && slug ? theme + '//' + slug : null; | ||
|
||
const templatePartToPattern = ( templatePart ) => ( { | ||
blocks: parse( templatePart.content.raw, { |
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.
Reviewed how this (or whether) is being used in the consumer code that uses parts (page-patterns). Everything has been migrated:
- blocks: adapted consumer code
- categories: unused
- description: no need to do anything
- isCustom: unused
- keywords: unused
- id: parts already have an id
- name: removed & adapted the consumer code
- title: removed & adapted the consumer code
- type: as it is
_links
: as it is
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 see actions were also a consumer of this (through dataviews's item). I've only found one case that requires updating (title
is not using decodedEntities
https://github.com/WordPress/gutenberg/pull/62927/files#r1658485082 ) but the rest were already ported (isCustom
, etc.).
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.
Code-wise, this is a good move. The usePatterns
hook and the idea of providing a stable structure for the page-patterns across patterns & parts wasn't working: it leaked to actions & the page-patterns still had to do a lot of data wrangling depending on the post type.
I've done some testing: both the Patterns dataviews page & actions within the editor.
Issues:
- Parts: duplicate action doesn't work properly (it works in
trunk
).- in dataviews: shows weird title (object, not the title string)
- in editor: it triggers an error (probably related)
- User patterns: the title for the duplicate action needs passing through
decodeEntities
(creating a pattern whose name isandré
should help testing this: compare duplicate action vs rename action to see the difference)
Duplicate (dataviews):
Duplicate (editor):
Thanks for the thorough testing @oandregal, we definitely need more e2e test. Probably one per action. I'm going to try to add some as I refactor and type the actions. |
We should also look at removing |
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.
Thank you!
Part of #55083
Related #59659
Unblocks #62913
What?
When working on a the dataviews extensibility actions. I noticed that some of the post type actions receive objects that are not actual post types, they are temporary objects that were created for the purpose of rendering template parts in the patterns page. We were mapping template parts to weird objects that resemble patterns.
For me this is not something we should be doing because:
How?
This PR just removes that mapping and tries to update all the places where that mapping was necessary. The code is a bit hard to follow, so there's a chance that I missed some places. Some help testing everything is needed.
Unrelated: I was not able to test the template parts actions menu in the editor because I was not able to open template parts in the editor (I'll investigate this separately)
Note I noticed that there's also mapping happening between registered patterns (theme patterns) and saved patterns (user patterns). I think for these as well, we should be removing the mapping.
Testing Instructions
1- Use the different filters, fields and actions in the template parts dataviews.