It's a common practice to use the post_parent property in the WP_Post class to create 1-to-n relationships between different custom post types.

In an plugin I'm developing, I added a SelectControl to the PluginDocumentSettingPanel to be able to set the id of a related custom post type in another custom post type. According to the docs, I should use getEditedPostAttribute to retrieve the current "parent" (the id of the related custom post type) of the custom post type being edited:

select( 'core/editor' ).getEditedPostAttribute( 'parent' )

But, for some reason, I'm getting an undefined value even though the post_parent property is set. A custom meta box in the classic editor shows it correctly.

If I set the hierarchical property in the custom post type to true, the selector works and I get the correct value. Is this by design? Or are we forced to use a custom meta field to store this data, now?

It's a common practice to use the post_parent property in the WP_Post class to create 1-to-n relationships between different custom post types.

In an plugin I'm developing, I added a SelectControl to the PluginDocumentSettingPanel to be able to set the id of a related custom post type in another custom post type. According to the docs, I should use getEditedPostAttribute to retrieve the current "parent" (the id of the related custom post type) of the custom post type being edited:

select( 'core/editor' ).getEditedPostAttribute( 'parent' )

But, for some reason, I'm getting an undefined value even though the post_parent property is set. A custom meta box in the classic editor shows it correctly.

If I set the hierarchical property in the custom post type to true, the selector works and I get the correct value. Is this by design? Or are we forced to use a custom meta field to store this data, now?

• custom-post-types
• javascript
• block-editor
• hierarchical

Share Improve this question asked Jul 3, 2020 at 8:57 leemonleemon 2,03244 gold badges2525 silver badges5151 bronze badges

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 1

You are already using the correct Gutenberg/JS code, but it's a limitation in the REST API which exposes the parent field only for hierarchical post types like page. But you can force the field to appear in the REST API responses via register_rest_field() — example for a my_cpt post type:

register_rest_field( 'my_cpt', 'parent', array(
    'schema' => array(
        'description' => __( 'The ID for the parent of the post.' ),
        'type'        => 'integer',
        'context'     => array( 'view', 'edit' ),
    ),
) );

Alternatively, you can use the rest_prepare_<post type> hook to just add the parent in the response:

add_filter( 'rest_prepare_my_cpt', function ( $response, $post ) {
    $data = $response->get_data();
    $data['parent'] = $post->post_parent;
    $response->set_data( $data );

    return $response;
}, 10, 2 );

But if you want to allow editing the parent via the REST API, then the first option is preferred.