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.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @jonnynews.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

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

Unlinked contributors: jonnynews.

Co-authored-by: coder-rancho <vyasnaman@git.wordpress.org>
Co-authored-by: spacedmonkey <spacedmonkey@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @coder-rancho! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

Thanks for contributing, @coder-rancho!

I don't think there's a need to copy the solution from #60317 for the Navigation block. Instead, we should modify the capabilities definition for this post type. See register_post_type.

P.S. The Correct folder for this enhancement would be compat/wordpress-6.9.

Thanks for the suggestion @Mamaduka. But I still think we need this implementation because get_item_permissions_check checks whether the user has update permission.

We cannot allow Editor to update wp_navigation and hence this patch is required. I can however move the implementation to compat/wordpress-6.9

I still think we need this implementation because get_item_permissions_check checks whether the user has update permission.

We should experiment and see if we can request a Navigation item in view context when a user can't edit it. Hardcoding special cases for post type in the general controller probably goes against REST API component best practices.

cc @spacedmonkey, @TimothyBJacobs

We should experiment and see if we can request a Navigation item in view context when a user can't edit it.

Setting the context as view inside block editor may cause regression issues with existing APIs. wdyt?

We'll have to re-arrange how the Navigation blocks edit component is rendered, but technically, it should be doable. That's one of the reasons I suggested combining PRs (#69806 (comment)).

If we go to the post type capabilities route, PHP changes should be minimal, so there's no reason to split PRs, and that would make it easier to test.

Alright, I'll spend some time to figure it out.

@spacedmonkey, the associated issue explains this: #60809. tl;dr; Editor needs to render, non-editable Navigation block for low-cap users, currently requests will fail and block will display "Missing navigation" message.

We'll have to re-arrange how the Navigation blocks edit component is rendered, but technically, it should be doable.

I researched about the above suggestion. Some of the important points to note:

1. We need to change three files:
   1.1. edit/index.js: This file is the entry point and render the NavigationInnerBlocks component based on conditions fetched using useNavigationMenu hook.
   1.2 use-navigation-menu.js: Define useNavigationMenu hook.
   1.3 edit/inner-blocks.js: Define NavigationInnerBlocks component.
2. At most places we're using useEntityBlockEditor to fetch list of blocks.
3. I thought, we can replace useEntityBlockEditor with getEntityRecord as follows:
   3.1 Fetch the record using getEntityRecord with { context: 'view' } argument.
   3.2 Use parse(record.content) function to get list of blocks.

My assumption was partially correct but when we set { context: 'view' }, we get the rendered content. But when we set { context: 'edit' }, we get raw content. The parse function expects the block markup (i.e. raw content).

Hence, even if we want to go this way, we have to hardcode some conditions in REST APIs.

Can we limit this to just context=view then?

@spacedmonkey, the associated issue explains this: #60809. tl;dr; Editor needs to render, non-editable Navigation block for low-cap users, currently requests will fail and block will display "Missing navigation" message.

Can we limit this to just context=view then?

@jonnynews, we need the block markup which is available only with context=edit. see this comment

@coder-rancho, let's merge/combine #69806 into this one. Otherwise, it would be hard to test these changes. The suggestion (#58301 (comment)) was valid for that case, but I don't think it applies here.

Once combined, please update the PR description accordingly 🙇

Regarding the REST API, I think we should try to introduce minimal changes only (or primarily) for the wp_navigation post type capabilities.

@Mamaduka , I've merged the branches into #69855.