-
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
useEntityBlockEditor: Update 'content' type check #59058
useEntityBlockEditor: Update 'content' type check #59058
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. |
Size Change: -3 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
Flaky tests detected in 703000b. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7912504980
|
I'd like to understand in which case the content is an object and why? |
Let's say REST API omits I discovered while debugging regression for navigation callback REST API. Besides, we only want to parse the content if it's a string, so I think this check makes more sense. More details can be found here - #58987 (comment). The code in question: gutenberg/packages/core-data/src/selectors.ts Lines 458 to 463 in 2d7a1de
|
Why would the REST API omit content.raw from the response? Regardless, I think That doesn't mean we shouldn't check the "string" but for me fixing the former is actually more important. |
I agree, but how can we guarantee server responses from the client? REST API responses/schema is filterable. All we can do is safeguard and validate. P.S. I'm open to suggestions :) |
I'm trying to understand which endpoint is causing the issue and why. I followed the proposed instructions and I don't see any error on trunk personally. Is there something else at play. What does the endpoint return for you? |
The current issue is with an embedded record for the To avoid extra network requests, the As for why, it's a regression for this particular case - https://core.trac.wordpress.org/ticket/43439#comment:17. Screenshot |
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.
Can we avoid using embed for now. It feels like it has at least a couple bugs as linked on that ticket?
Btw, I'm ok with this PR too but having a wrong endpoint return an incomplete response is also a bug.
Having getEditedEntityRecord
returning "content" as an object is also a bug IMO that should be solved, even if it doesn't manifest in the editor today, it may manifest in some plugin for instance.
Here's the PR #59076. I'll merge this PR; it's just hardening the content existence/type checks. |
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org> Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
I just cherry-picked this PR to the cherry-pick-beta-2 branch to get it included in the next release: b348e5c |
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org> Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
What?
Part of #58987.
PR updates the
content
type check foruseEntityBlockEditor
and makes it more strict.Why?
In rare cases, entity content returned by
getEditedEntityRecord
can be an object. Passing an object or function into theparse
method will throw an error.Details - #58987 (comment).
Testing Instructions
ref
attribute -<!-- wp:navigation /-->
.ref
attribute is set.Plus, CI checks should be green.
Testing Instructions for Keyboard
Same.
Screenshots or screencast