I have a custom post type, call it topic. It is from BBPress, but this isn't a BBPress question.

I also have a post type lessontopic.

I added a meta box to BBPress so that I can choose an associated Lesson Topic for the Forum Topic when I am in the BBPress Topic backend editor, and that save that as post meta data.

Here is what I did:

add_action( 'add_meta_boxes', 'ld_bbpress_display_ldtopic_selector');

function ld_bbpress_display_ldtopic_selector() {
    add_meta_box( 'ld_bbpress_ldtopic_selector', __( 'LearnDash bbPress Settings', 'learndash-bbpress' ), 'ld_bbpress_display_topic_selector_callback', 'topic', 'advanced', 'high' );
}

function ld_bbpress_display_topic_selector_callback() {
   My call back stuff
}

add_action( 'save_post_topic', 'ld_save_associated_ldtopic',10,1);
function ld_save_associated_ldtopic($topic_id){
    if ( ! wp_verify_nonce( $_POST['ld_bbpress_nonce_ldtopic'], 'ld_bbpress_meta_box_ldtopic' ) ) {
        return;
    }
    my save stuff
}

Now everything looks ok in backend. But if I choose a lesson topic from my meta dropdown, and hit update, and step through in my debugger, I see that the update is performed in

wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php

This has to do with the fact that for a custom block I made that enables me to select forum topics, I had to enable BBPress topics to be seen in restAPI, and that mysteriously causes backend editor to hit the restAPI endpoint for updates. I did that restAPI enabling via

add_filter( 'bbp_register_topic_post_type', 'enable_restAPI_bbpress_topics', 10,1);
function enable_restAPI_bbpress_topics ($args) {
    $args['show_in_rest'] = true;
    $args['supports'] = array( 'title', 'editor', 'author', 'thumbnail', 'excerpt' );
    return $args;
}

But I don't understand: why does the mere act of checking off that a post type is visible to restAPI cause wordpress's backend editor to go into a completely different mode of operation? I mean, we are talking about backend. If I enable restAPI, I can see how that should facilitate headless CMS, etc, but why on earth does it so radically alter how Wordpress deals with backend post editing?

Somehow, this is resulting in my save hook ld_save_associated_ldtopic not seeing the $_POST array and therefore not seeing nonce data.

Really quite peculiar. I feel like I am breaking some rule and it is biting me, but not sure what I need to do to get my meta box to work in this fashion.

Ideas?

thanks, Brian

I have a custom post type, call it topic. It is from BBPress, but this isn't a BBPress question.

I also have a post type lessontopic.

I added a meta box to BBPress so that I can choose an associated Lesson Topic for the Forum Topic when I am in the BBPress Topic backend editor, and that save that as post meta data.

Here is what I did:

add_action( 'add_meta_boxes', 'ld_bbpress_display_ldtopic_selector');

function ld_bbpress_display_ldtopic_selector() {
    add_meta_box( 'ld_bbpress_ldtopic_selector', __( 'LearnDash bbPress Settings', 'learndash-bbpress' ), 'ld_bbpress_display_topic_selector_callback', 'topic', 'advanced', 'high' );
}

function ld_bbpress_display_topic_selector_callback() {
   My call back stuff
}

add_action( 'save_post_topic', 'ld_save_associated_ldtopic',10,1);
function ld_save_associated_ldtopic($topic_id){
    if ( ! wp_verify_nonce( $_POST['ld_bbpress_nonce_ldtopic'], 'ld_bbpress_meta_box_ldtopic' ) ) {
        return;
    }
    my save stuff
}

Now everything looks ok in backend. But if I choose a lesson topic from my meta dropdown, and hit update, and step through in my debugger, I see that the update is performed in

wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php

This has to do with the fact that for a custom block I made that enables me to select forum topics, I had to enable BBPress topics to be seen in restAPI, and that mysteriously causes backend editor to hit the restAPI endpoint for updates. I did that restAPI enabling via

add_filter( 'bbp_register_topic_post_type', 'enable_restAPI_bbpress_topics', 10,1);
function enable_restAPI_bbpress_topics ($args) {
    $args['show_in_rest'] = true;
    $args['supports'] = array( 'title', 'editor', 'author', 'thumbnail', 'excerpt' );
    return $args;
}

But I don't understand: why does the mere act of checking off that a post type is visible to restAPI cause wordpress's backend editor to go into a completely different mode of operation? I mean, we are talking about backend. If I enable restAPI, I can see how that should facilitate headless CMS, etc, but why on earth does it so radically alter how Wordpress deals with backend post editing?

Somehow, this is resulting in my save hook ld_save_associated_ldtopic not seeing the $_POST array and therefore not seeing nonce data.

Really quite peculiar. I feel like I am breaking some rule and it is biting me, but not sure what I need to do to get my meta box to work in this fashion.

Ideas?

thanks, Brian

• custom-post-types
• posts
• custom-field
• metabox

Share Improve this question asked Dec 4, 2019 at 12:17 BrianBrian 33722 silver badges1111 bronze badges 3

• with the new editor gutenberg, saving a post is done with the REST API. but it always a POST request then you should read data chosen by the user on the action save_post_topic. look what append with the Network Monitor of your browser. If you use Firefox, you can show it with Ctrl + Shift + E developer.mozilla/en-US/docs/Tools/Network_Monitor – Kaperto Commented Dec 4, 2019 at 12:36
• The thing is, when I compare updates in different post types, class-wp-rest-posts-controller.php update_post is not always called. In my case it is being called, and something about that is making it such that $_POST is not even set when program flow gets to my save hook. I think the show_in_rest parameter adds extra constraints and I need to somehow allow my meta box save hook to receive a $_POST variable. Somewhere along the way the rest controller is unsetting $_POST... – Brian Commented Dec 4, 2019 at 12:47
• oh, I just seen on my tests that there is 2 request when saving. first : POST to REST API with the only content ($_POST is empty here). and the second : POST to post.php, there $_POST contains boxes values. – Kaperto Commented Dec 4, 2019 at 12:55

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 1

But I don't understand: why does the mere act of checking off that a post type is visible to restAPI cause wordpress's backend editor to go into a completely different mode of operation?

WordPress 5.0 introduced the Block Editor. This is an entirely new post editing screen and method of editing posts. It works by using the REST API. So if you have a post type that is not available in the REST API, it will fall back to the old "Classic" editor, and continue to function as it used to.

If the post type is enabled in the REST API, then unless otherwise specified (such as by using the use_block_editor_for_post_type filter), the Block Editor will be used instead.

Custom meta boxes created using add_meta_box should continue to work in the block editor, but they have to be handled differently for compatibility with the Block Editor. How this works is documented here.

But there should be no issue with $_POST being seen inside the save_post or save_post_topic hook. If you're attempting to debug, it's likely that you're looking at the wrong request. Most changes in the editor will be sent to the REST API endpoint, and handled by that, but meta boxes will be posted as a separate request to /wp-admin/post.php, where the normal actions will fire. The only difference being that this now happens in the background.