Update the Site Title block to use block bindings #67260
+198
−43
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.