Reading terms from a public REST endpoint is forbidden in the editor unless you can edit them

[TJNowell]

If you try to use const terms = select( 'core' ).getEntityRecords( 'taxonomy', 'my_taxonomy' ) as a user that does not have the ability to edit terms in that taxonomy, the REST API will reject the request with a 403 if the context is edit, even if that endpoint is publicly queryable.

This is due to code in the term controllers get_items_permissions_check at:

​https://github.com/WordPress/wordpress-develop/blame/d8712695cbafb597ce53020fe786ff5ad06bbecb/src/wp-includes/rest-api/endpoints/class-wp-rest-terms-controller.php#L191-L197

The needed information is available if context=edit is manually removed from the API URL.

This check should be removed, it does not make sense that public information is unavailable in the edit context. It should instead reject editing when editing, not when reading.

I've found this issue while testing an update to WP 5.9.

As a use case, we use this information on a project to display data to authors, but they cannot change or edit it, it's purely text.

[TJNowell]

Noting that I can add context: 'view' to the 3rd parameter of getEntityRecords but this workaround should be unnecessary for public endpoints

[TimothyBlynJacobs]

The default context is view. The Block Editor made the architectrual decision to set the default context to queries to use edit.

The edit context allows exposing fields that are not public, even if the resource is public. For instance, the raw post content is exposed when requesting a resource with an edit context.

There are a number of fields in the taxonomy endpoint that are not exposed publicly. If you don't need those more privileged fields, then you can query the resource using the view context.