![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#47866 closed defect (bug) (fixed)
Document that register_meta's show_in_rest for Custom Post Types requires custom-fields support
| Reported by: | kadamwhite | Owned by: | kadamwhite |
|---|---|---|---|
| Priority: | normal | Milestone: | 5.3 |
| Component: | REST API | Version: | 4.9.8 |
| Severity: | normal | Keywords: | commit |
| Cc: | Focuses: | docs |
Description
As noted previously in #40408 and captured in a REST API handbook ticket, a custom post type must include custom-fields in its supports array or the meta key will not appear in REST API responses even if that meta is properly registered using register_meta.
This is true for both register_meta and the derivative register_post_meta method, as in the below rough example:
<?php register_post_type( 'book', array( 'public' => true, 'show_in_rest' => true, 'supports' => array( 'title', 'editor' ), ) ); register_post_meta( 'book', 'awards', array( 'show_in_rest' => true, 'single' => true, 'type' => 'integer', ) );
The meta key will be missing from the REST API responses for the book post type in this example because custom-fields is not included in the supports array.
As meta over REST becomes more important to the block editor and complex plugins, I propose we expand the documentation of the show_in_rest argument for register_meta to highlight this caveat.
Attachments (1)
Change History (5)
This ticket was mentioned in Slack in #docs by kadamwhite. View the logs.
7 years ago
#4
@
7 years ago
Great, I had to find out it myself couple of days ago and it wasn't straight forward.
As a suggestion, maybe it could indicate more directly what needs to be present. Something like: "... declare support to custom post types by having 'custom-fields' in its 'supports' array. (@see register_post_type)"
Proposed documentation adjustment for show_in_rest field