-
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
Block Bindings: Prioritize existing placeholder over bindingsPlaceholder #65220
Block Bindings: Prioritize existing placeholder over bindingsPlaceholder #65220
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. |
b4401a7
to
a346646
Compare
Size Change: +1.01 kB (+0.06%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
At first glance, I would try to avoid adding a new prop to the rich text component. I still have to take a deeper look at the code, but maybe we can read the |
It's an already existing prop 😅
We'll need to extract the default somewhere else, but even then, the default varies by element type. It's a bit tricky, I've thought about that for a few minutes. |
Sorry, I didn't realize that. Anyway, it doesn't feel intuitive to me, but I'd love to know other opinions.
I was thinking about changing this conditional to something like this: bindingsPlaceholder:
adjustedValue?.length > 0 || attributes?.placeholder
? undefined
: _bindingsPlaceholder, I am not sure if the block attributes are already available in the rich text component, but we have the I quickly tested and it seems to work, although it would need a double-check. By the way, I believe we should combine the |
Would that work, considering the placeholder attribute is always set? That's why the |
If I am not mistaken, the |
Maybe the logic could be moved here, but I believe this order still applies: Placeholder attribute -> Bindings placeholder -> Placeholder prop. |
In the latest two commits, I've pushed a different alternative to solve the issue. Basically, it checks the Additionally, I slightly modified the logic for Let me know what you think 🙂 |
Looks great to me @SantosGuillamot 🚀 |
…modifying the placeholder prop
// Don't modify placeholders if value is not empty. | ||
if ( adjustedValue.length > 0 ) { | ||
return { | ||
disableBoundBlock: _disableBoundBlock, |
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.
Interesting, should it explicitly return null
for bindingsPlaceholder
and bindingsLabel
with some more detailed explanation?
Alternatively, would the following work and made it easier to follow:
disableBoundBlock: _disableBoundBlock, | |
disableBoundBlock: _disableBoundBlock, | |
bindingsLabel: props[ 'aria-label' ] || placeholder, |
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.
A similar trick might also work for bindingsPlaceholder
.
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 explicitly return null
as suggested. I kind of like having the conditionals outside of the bindings logic. It makes it clear when the placeholder
and the aria-label
are defined:
placeholder: bindingsPlaceholder || placeholder, gutenberg/packages/block-editor/src/components/rich-text/index.js
Lines 442 to 444 in 0027219
aria-label={ bindingsLabel || props[ 'aria-label' ] || placeholder }
Having said that, I don't have a strong opinion so I'm happy to change that.
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 left only feedback related to code readability. This fix is looking great. I think we should include in the plugin release and backport also to WP 6.7 release.
…der (#65220) * Pass data-custom-placeholder prop to all RichText instances that are modifying the placeholder prop * Use placeholder if data-custom-placeholder is true * Add test * Only use placeholder if aria-label is not defined * Prioritize custom placeholder in aria-label * Fix Cover block test * Revert aria-label changes * Try: Read block attribute in bindings placeholder * Revert changes to placeholder prop * Fix after rebase * Explicitly return `null` for empty values --------- Co-authored-by: zaguiini <zaguiini@git.wordpress.org> Co-authored-by: SantosGuillamot <santosguillamot@git.wordpress.org> Co-authored-by: gziolo <gziolo@git.wordpress.org>
I just cherry-picked this PR to the wp/6.7 branch to get it included in the next release: 0080898 |
…der (#65220) * Pass data-custom-placeholder prop to all RichText instances that are modifying the placeholder prop * Use placeholder if data-custom-placeholder is true * Add test * Only use placeholder if aria-label is not defined * Prioritize custom placeholder in aria-label * Fix Cover block test * Revert aria-label changes * Try: Read block attribute in bindings placeholder * Revert changes to placeholder prop * Fix after rebase * Explicitly return `null` for empty values --------- Co-authored-by: zaguiini <zaguiini@git.wordpress.org> Co-authored-by: SantosGuillamot <santosguillamot@git.wordpress.org> Co-authored-by: gziolo <gziolo@git.wordpress.org>
I just cherry-picked this PR to the release/19.3 branch to get it included in the next release: 3640694 |
Supersedes #65154.
What?
Respect existing
placeholder
attribute when it exists over the one provided by the Block Bindings API.Why?
We're setting a more helpful placeholder if the block has bindings. While that's awesome and works as intended most of the time, if the block already has an existing placeholder, that value is lost, but it should've been prioritized.
How?
Prioritize
placeholder
in the applicable places (placeholder
andaria-label
.) We're using an existing prop calleddata-custom-placeholder
to understand if the placeholder has been customized.Testing Instructions
Register a new post meta field on the server:
In Gutenberg...
The result should match the screenshot below.
Side note: The 2nd paragraph is empty because the value returned from the server is an empty string. I'm not sure that's intended, but that's what we have right now in
trunk
. 🤔 I'm also unable to edit the value, which is weird considering recently we've fixed a similar bug.Screenshots or screencast