Custom post types with a custom REST controller class are not editable

[greatislander]

Issue Overview

Custom post types registered with a custom REST Controller class are not editable in Gutenberg.

Steps to Reproduce

1. Register a custom post type with a custom REST Controller class.
2. Try to edit a post of this type.

Expected Behavior

Gutenberg loads the post for editing.

Current Behavior

Gutenberg fails to load the post.

Possible Solution

• Proposed solutions exist in Custom post types without show_in_rest cannot load editor #3066, but this is a different bug so I thought it would be worth documenting separately.
• gutenberg_get_post_to_edit() assumes that all posts will be in the wp/v2 namespace. Changing this to accommodate namespacing would resolve this issue.

  gutenberg/lib/client-assets.php

  Line 513 in 6eec188

  sprintf( '/wp/v2/%s/%d', ! empty( $post_type_object->rest_base ) ? $post_type_object->rest_base : $post_type_object->name, $post->ID )

Screenshots / Video

Related Issues and/or PRs

#3066

Todos

• Tests
• Documentation

[greatislander]

Note, as per my Slack post, also affects taxonomies registered in their own namespace in the REST API.

[danielbachhuber]

@greatislander To take this conversation forward a bit, how would you expect this to work?

To provide a little bit of background...

It's a reasonable assumption that any routes in the wp/v2 namespace can work with Gutenberg because they're defined by core APIs. For instance, because the wp/v2/types/post endpoint exposes supports=[title], Gutenberg knows it can display the title field. Gutenberg can also assume that a title is a "title", and so on.

However, once we enter the world of arbitrarily defined endpoints (e.g. pressbooks/v2 and otherwise), Gutenberg has much less information to go by. For instance, you could've named your "title" field headline, but there's no way for Gutenberg to know they should be treated the same. At a higher-level, the challenge is that you (the developer) can shape your data however you'd like — and Gutenberg has no idea how to correlate fields to API data.

If you'd like your custom post type to work with Gutenberg, I'd suggest enabling show_in_rest=>true, exposing the post type in the wp/v2 namespace using the standard controller, and then make any modifications to the controller behavior using the explicit APIs (e.g. register_rest_field()). At this point, I'm not sure whether this is a solvable problem.

[greatislander]

Hi @danielbachhuber, thanks for the detailed response.

We used the pressbooks/v2 namespace mainly because of this part of the REST API documentation:

[Namespaces] should be used as a vendor/package prefix to prevent clashes between custom routes…

Failing to [use a unique namespace] is analogous to a failure to use a vendor function prefix, class prefix and/ or class namespace in a theme or plugin, which is very very bad.

We proceeded to build major core functionality (for communication between Pressbooks networks) on top of our namespaced custom post type endpoints based on the understanding that this was the preferred way for third-party extensions to work with the REST API. Changing these to wp/v2 at this point would be very disruptive (note: we use 'show_in_rest' => true, and specify our custom controller class using the rest_controller_class argument).

To your specific point, I understand that the use of wp/v2 makes it easy for Gutenberg to assume the presence of certain features. However, isn't it also the case that a custom post type within that namespace could not support the title field? Gutenberg handles this, and I believe there are other optional features of post types in the core wp/v2 namespace that are handled in various ways.

Perhaps an approach to this would be giving plugins a way to tell Gutenberg that their namespaced custom post types and taxonomies support whatever core post type and taxonomy REST API features Gutenberg requires (or support a particular subset of these features). Does this sound like it might be feasible? I noticed that this open PR which removes the gutenberg_get_post_to_edit() function I referenced earlier. I haven't looked at it in detail to see if any of the changes within might impact this issue.

Again, thanks for engaging with this issue. I will look into it more this week and see what's changed and if I can think of any more specific approaches.

[dac514]

If you'd like your custom post type to work with Gutenberg, I'd suggest enabling show_in_rest=>true, exposing the post type in the wp/v2 namespace using the standard controller, and then make any modifications to the controller behavior using the explicit APIs (e.g. register_rest_field()). At this point, I'm not sure whether this is a solvable problem.

Hi @danielbachhuber

Are you aware of this issue? https://core.trac.wordpress.org/ticket/38323

register_meta() currently works globally across all post types, but it does not support registering meta for individual post types.

The short version, we tried to do what you proposed but ran into problems. If my custom post type is named 'chapter' and I were to do register_meta( 'chapter', ... ) CRUD breaks. There were several other issues.

When we worked on our API our priority wasn't Gutenberg compatibility. It was to have a decent API.

Mostly, our post types work fine in the existing editor and i'm not sure what you are proposing will even work?

[danielbachhuber]

Hey folks,

@pento and I chatted yesterday (after I posted my original comment), and I think #2457 (comment) is the direction we're heading. Essentially, we're introducing block-editor as a post_type_supports(). If you register a custom controller for your post type, but include block-editor, then Gutenberg will assume you've done what you need to for compatibility

Are you aware of this issue? https://core.trac.wordpress.org/ticket/38323

Yes, although it seems to be a (related but) different topic than this issue.

[kadamwhite]

@connerbw Commenting for posterity: As of WP 4.9.8, register_meta supports an object_subtype argument which can be used to limit meta registration to a single post type's endpoint. register_post_meta( 'cpt_name', ... ) has also been introduced as a (recommended) shortcut for registering post meta for a specific CPT.