Open talldan opened 5 months ago
@youknowriad Not sure if you recall, but we discussed this issue in the past (though I can't remember which PR we discussed it on now).
I've put together a PR that renames the button block attributes to see exactly what it would entail - https://github.com/WordPress/gutenberg/pull/62612.
It ends up being quite a big change. 😬
I'm not sure if there's anything else we can do to mitigate the issue before 6.6..
An alternative could be to prevent users from using the same name for button and image blocks. I can look into that. What do you think?
I've put together a PR that renames the button block attributes to see exactly what it would entail - https://github.com/WordPress/gutenberg/pull/62612.
I'm not entirely sure we should be doing this (renaming the attribute) as the issue can come up with any block types really. And for these particular case, both of these are urls but it's not entirely clear why they should share the same name.
An alternative could be to prevent users from using the same name for button and image blocks. I can look into that. What do you think?
Maybe if it's not that complex but it could also be considered a bug to be solved later. I think ultimately we could offer a way to "map" to specific attributes in the actual binding configuration. Something like "bindingName": "href"
. (A way to rename the attribute at the binding level). We may want to offer this possibility later at the code level for third-parties/advanced use-cases but UI wise, it's not clear we should be doing anything.
I think it's fine to not address this right now. We could render a warning in list view or somewhere else if we detect two different block types with the same name. Maybe on save flow as well.
For more complex setups I think we can make it possible, but not super explicit (bound per attribute at the code level but not UI, as @youknowriad mentions).
This is a good example of the "Simple things should be easy and intuitive, and complex things possible."
The scenario described here is a complex one, we should find ways to make it possible, but the straightforward cases should be super easy, which is where the name as key comes into play — it's less concepts, more straightforward.
Thanks for the comments - that adds some confidence that it's ok to bump this to 6.7/later and think about more general solutions 👍
Description
When pattern overrides are enabled for a block, the block name becomes the key that attribute data is stored under in instances of the pattern block. For example, a button block called "CTA" would store it's
url
attribute value in a pattern block's content like so:Another feature of pattern overrides is that two blocks can share the same name, so two paragraphs, or a paragraph and a heading can have their text content synced, with the data being stored in the same object.
A problem occurs when a user gives a button block and an image block the same name. The image block has the following attributes:
url
- used for the<img>
tag'ssrc
attributehref
- used for the optional<a>
tag'shref
attributeWhile the button block has:
url
- used for the optional<a>
tag'shref
attributeFor image and button
url
means two different things. If an image and a button share the same override name, it can result in a broken image src when the user sets the button block's link. It's unfortunate that the button block's attribute isn't calledhref
.Another factor is that the image block's
href
isn't currently a supported attribute for pattern overrides / block bindings.Step-by-step reproduction instructions
https://wordpress.org
)Expected: The link for the image is set to the same thing given the two blocks are named the same Actual: The image block has a broken image
Screenshots, screen recording, code snippet
Environment info
No response
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Yes