Update the Site Title block to use block bindings #67260
Conversation
talldan
added
[Type] Enhancement
talldan
requested review from
gziolo,
artemiomorales,
SantosGuillamot and
cbravobernal
talldan
requested review from
spacedmonkey,
tellthemachines,
ajitbohra,
juanmaguitar,
fabiankaegy and
ndiego
as code owners
|
Size Change: +267 B (+0.01%) Total Size: 1.82 MB
ℹ️ View Unchanged
|
|
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. |
talldan
added
Needs PHP backport
talldan
force-pushed
the
update/site-title-to-use-block-bindings
branch
from
a33fede to
136c0d2
Compare
… block using block supports
talldan
force-pushed
the
update/site-title-to-use-block-bindings
branch
from
3a5a968 to
b60d3a7
Compare
There was a problem hiding this comment.
Thanks for opening this 🙂 As you shared, I think this opens the conversation about how to handle core blocks that could be bindings: site title, post title, post excerpt... Personally, I would like to explore the possibility of reusing the heading and the paragraph block and creating sources for these use cases. It would potentially trigger conversations about improving block variations or the attribute locking.
However, if we decide to keep using a site title block, I am not sure if we should use bindings. The point of bindings is to be able to reuse the same block with different dynamic data. But if the dynamic data is always the same (in this case site title), why don't we just add that logic directly in the edit and the render? If it hits any limitation with contentOnly, maybe there is an API missing there? Or do we expect block developers to also use bindings for this use case?
If we explore using bindings for this kind of core blocks, each use case might be different. For example, what are the differences between a site title block and a heading/paragraph connected to the site title?
Imagine we implement something like the following:
- A variation of the heading and paragraph connected to site title through bindings.
- Users can change from paragraph to headings using controls.
- If the variation is active, hide the panel to change bindings (or not, whatever is decided).
What would be missing?
If we're creating variations for heading and paragraph, is that then there's potentially two Site Title blocks showing up in the inserter. I suppose one of the variations could be set to It's annoying I only just thought of that, I can try it. 😄 |
| } | ||
|
|
||
| export default { | ||
| name: 'core/site', |
There was a problem hiding this comment.
Can we make this a generic "entity edit" binding where the connection would provide a "kind, name, property/key"?
There was a problem hiding this comment.
I think we'll need a matching server implementation. I guess REST API resources map fairly close to entities, but I'm wondering if there will be edge cases and whether there might need to be a translation layer.
I'll put it on the TODO list. 😄
There was a problem hiding this comment.
Generic entity edit sounds great on the client as a source for Block Bindings. Great idea. 👏
The specific details would need to be explored like validation whether all of them fit into the model, does the current user has permission to view or edit them. It wasn’t simple for Post Meta alone.
The server part for source registration might be a fun challenge, too. However there is so much potential 😀
|
If we could migrate blocks (site title, post title, etc..) in a good way, I can see the value in this approach. If on the other hand we're trying to use another mechanism (bindings) just in order to have a |
One of the goals of block bindings was to be able implement a whole range of blocks like Site title, Post title using it (though ideally using an existing block like the Heading block), so I don't see it as using another mechanism, but instead part of migrating these blocks to have the correct implementation. I'm also trying the hard option before taking the easy one. It might be too soon to try this. 😄
I discovered a fairly big thing that would be missing if the heading block were used—themes are currently targeting blocks like 'core/post-title' and 'core/site-title' block in the theme.json, giving them some special styling: This would need a migration if a variation were used, though I also don't know whether themes can target block variations in a theme.json, I imagine not. |
I am not sure I fully understand this, but I have one question related: I can see the benefit of using existing blocks (like paragraphs, headings...) with bindings instead of having multiple blocks. However, what is the benefit of migrating those blocks (Site Title, Post Title...) to use bindings? The main goal of block bindings is to be able to use the same block to show dynamic data from different places. However, if the dynamic data is always the same (Site Title, Post Title...), what is the point of moving them to block bindings? I feel I'm missing something here.
We have discussed this in the past. I believe it is not possible right now but with the introduction of block bindings supporting block variations in |
To be clear, I'm not saying switch these blocks to use bindings and stop there, but it seems unfeasible to migrate to heading without solving several other issues first (which can be documented). There can be some advantages to solving this as a stepping stone:
|
|
@talldan just as an FYI, the hardcoded list you mention actually gets run through a filter so it is possible to modify that list even today for this exact reason.We build lots of really custom header elements that save complex post meta stuff. And we do it via this filter today. |
|
What I'm concerned about is promoting this use of block bindings when the dynamic data is always the same. I don't think block bindings make sense in that case. It makes me think that it might cover an underlying issue with
"content": {
"type": "rich-text",
"source": "rich-text",
"selector": "p,h1,h2,h3,h4,h5,h6",
"role": "content"
}Shouldn't this solve the original issue of editing when the template is locked?
|
Could you elaborate on what you mean by it being always the same? Do you mean the value being unchanged, or always being bound to the same field?
It'd be an unused attribute and perhaps a bit misleading to anyone interested in how the block works. What's supposed to happen if it's programmatically set to something?
Anyway, I think I can get away with what Nik suggested for now, and I think it's too soon to progress with this work. It was fun to explore it and start some of these conversations. I do think this will need to be revisited. I can spot some current or upcoming issues:
|
I mean always being bound to the same field. Block bindings purpose is to be able to reuse the same block but connect it to different data (Site Title, Post Title, Post Excerpt...) that can be chosen by the user. In this case, it is always connected to "Site Title", so I don't see the value bindings are adding. That made me wonder how dynamic blocks can easily opt-in for
Interesting conversations going on and a few follow-ups from this 🙂 |
To me, this is more of a power user feature, and there would be a facade that hides the complexity (e.g. a block variation of heading) for blocks like site title / post title. That's the ideal implementation. Lots of problems to solve though before that. I'll write up an issue documenting the hurdles. |
What?
Fixes part of #65778
Updates the Site Title block to use block bindings. This allows for a
contentattribute to be declared, and the block can be edited incontentOnlymode. If this approach works, it can also be used for other blocks (Site tagline, Post Title, Post Featured Image etc.).Why?
This provides some advantages:
contentattribute, and can be edited incontentOnlymode.editfunction is simplified quite a bit.How?
core/sitebinding source.metadata.bindingsattribute value describing the bindings. The most feasible option seemed to be using a default block variation of the site title that declares the attribute value. The problem with allowing the binding to be declared as an attribute value is that it can be removed by the user, leaving the block in a confusing state. I instead opted to add abindingsproperty for the attribute in the block.json that the block bindings API reads. The advantage of this is that it's innate to the block, it can't be removed without modifying the block type definition. It's a technical decision that need some discussion.Still to solve
Block/attribute support for bindings is currently hard-coded. I've updated the support in JS. The PHP support is declared in WordPress core code. It's easy enough to solve, but two things will be needed to properly support the binding on the frontend:
lib/compatfolder for Gutenberg that adds support for this to the last to WP versions.Testing Instructions
trunk(apart from the front-end)contentOnlytemplate locked group using the code editor:trunkyou can't.