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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>

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

_{compressed-size-action}

Flaky tests detected in 703000b.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7912504980
📝 Reported issues:

• [Flaky Test] can remove menu items #58985 in /test/e2e/specs/editor/blocks/navigation-list-view.spec.js

I'd like to understand in which case the content is an object and why?

Let's say REST API omits content.raw from the response, then getEditedEntityRecord (due to handling in getRawEntityRecord) will return content as an object.

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:

Let's say REST API omits content.raw from the response, then getEditedEntityRecord (due to handling in getRawEntityRecord) will return content as an object.

Why would the REST API omit content.raw from the response? Regardless, I think getEditedEntityRecord should always return "content" as either a string (regardless of what the REST API gives) or a function (if edit as function).

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 navigation-fallback. Here's a response for WP 6.5-bet1 and Gutenberg trunk.

To avoid extra network requests, the getNavigationFallbackId resolver will try to populate the entity record from the embedded response.

As for why, it's a regression for this particular case - https://core.trac.wordpress.org/ticket/43439#comment:17.

Screenshot

Can we avoid using embed for now. It feels like it has at least a couple bugs as linked on that ticket?

Here's the PR #59076.

I'll merge this PR; it's just hardening the content existence/type checks.

I just cherry-picked this PR to the cherry-pick-beta-2 branch to get it included in the next release: b348e5c