-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Add the block name to the pattern content data #58715
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 Core SVNCore Committers: Use this line as a base for the props when committing in SVN:
GitHub Merge commitsIf 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. |
96e2b81
to
f29d615
Compare
Size Change: +9 B (0%) Total Size: 1.69 MB
ℹ️ View Unchanged
|
What do you think if we prepend the name to the id instead? So |
Yep, this is the reason I avoided that approach. I also never like having to split strings to retrieve data, I think the code is cleaner with it being a separate property. I don't think the extra bytes are too much of an issue, the data would still be much less than the full serialized markup of the pattern. |
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.
Let's go with this approach for this release! 👍
Yeh, I agree with this, plus we still haven't made a call on whether id will be used to track shuffling content, etc. so combining the name and id here would limit our ability to let the user set their own meaningful id as an approach to solve this. |
What?
Part of #53705.
Proposes adding the block name to the pattern content data.
Currently in
trunk
the data is just in this form:There's no way to decipher which block the
text
value might be for.This PR updates it to look like this:
Why?
As discussed in the tracking issue (#53705 (comment)), I believe this could be useful and could support features like:
Because this data is stored, I think it's better to add this new property earlier so that it's in widespread usage before the feature is launched.
How?
Add the
block.name
as a propertyTesting Instructions
Expected, you should see a content value that looks like this: