-
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
Quick Edit: add Template field #66591
Conversation
…Press/gutenberg into add/template-form
Size Change: +1.07 kB (+0.06%) Total Size: 1.83 MB
ℹ️ View Unchanged
|
…Press/gutenberg into add/template-form
@louwie17, @youknowriad, @oandregal, I'm adding you as reviewers to gather some initial feedback on this PR. Currently, there are two things to mention:
|
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 tested well and changes look good from my end, I just left one minor suggestion.
__experimentalBlockPatternsList usage
I agree that this is fine given the template field also lives within the wordpress/fields
package.
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. |
Thanks for the review! |
[ postId, postType ] | ||
); | ||
|
||
const { availableTemplates, templates } = useSelect( |
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.
Why not merge both useSelect calls?
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.
Fixed with f891475
return { | ||
...field, | ||
Edit: ( data ) => ( | ||
<ExperimentalBlockEditorProvider settings={ settings }> |
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.
Why is this here and not directly in the template field edit?
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.
Not asking to change it, just curious why
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 need to pass settings
to this provider and usePatternSettings
depends on the edit site store:
gutenberg/packages/edit-site/src/components/page-patterns/use-pattern-settings.js
Lines 15 to 20 in f891475
export default function usePatternSettings() { | |
const storedSettings = useSelect( ( select ) => { | |
const { getSettings } = unlock( select( editSiteStore ) ); | |
return getSettings(); | |
}, [] ); | |
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.
Ok, here are my thoughts on this. Not necessarily something to be done here though
We need to check what settings exactly are needed for these previews. It seems mostly about the list of available patterns (maybe there's other stuff but I'm not sure). IMO, these could be provided directly from core-data
package selectors... without the "settings" object. This is a cleanup that needs to be done at some point. I mention some of this here https://make.wordpress.org/core/2024/09/12/gutenberg-development-practices-and-common-pitfalls/ (It's also kind of a similar change to what we did for defaultTemplates and template parts)
I'm ok shipping this as is now but I feel like if someone uses the "template" field, it should just work without any hidden requirement.
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.
Thanks! I agree with you! I'm happy to:
- open an issue.
- add the issue link on this comment.
- dedicate some time in the upcoming weeks to fix this.
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.
Awesome ❤️
What?
This PR is based on top of #66531
This PR is part of #64519.
Why?
This PR adds the
Template
field.Testing Instructions
Use default template
.Testing Instructions for Keyboard
Screenshots or screencast
Screen.Capture.on.2024-10-30.at.20-10-04.mp4
Drawbacks
@wordpress/block-editor
dependencyTo implement the modal previewing all the templates is necessary use the
__experimentalBlockPatternsList
from the@wordpress/block-editor
package. I think that it is acceptable.Uncaught TypeError: Cannot destructure property 'avatarURL' of '(0 , _wordpress_data__WEBPACK_IMPORTED_MODULE_3__.useSelect)(...)' as it is undefined
errorIn some cases, the templates in the modal aren't rendered correctly due to this JavaScript error:
Screen.Capture.on.2024-10-30.at.20-15-04.mov
gutenberg/packages/block-library/src/avatar/hooks.js
Lines 19 to 26 in 61f9655
This happens when the setting object isn't initialized. To fix this issue, I pushed 5a623fb. Still, I'm not sure that this is the best solution 🤔.
It is a similar issue that I tried to tackle with #66459.
cc @oandregal @youknowriad and @louwie17