Updating failed message when a wp_insert_post function is hooked to save_post ho

I’m surprised this works with classic editor. When you call wp_insert_post() from a “save_post” action, it triggers another “save_post” action, which calls wp_insert_post() again, which triggers another “save_post” action, which calls…

You get the idea — an infinite loop. The 500 error is a little different, I’m unsure of the precise cause, but I think it’s related to the server already being busy saving the initial post data when you hit it again to save the altered title. Either that or you’ve encountered a race condition where the submitted data isn’t valid yet because the initial save has not been completed yet.

In any case, there’s a better way to save altered post data. Alter the post data before the post is updated through the ‘wp_insert_post_data’ filter.

I’m not using the wp_insert_post here to alter the data of the post I am saving. As an example, when publishing the post A, I retrieve the some of its data, e.g. name of its related taxonomies. I am using the name of these taxonomies as the title and content to create post B. So when save_post action on post A is applied, post B is created through wp_insert_post, but wp_insert_post has nothing to do with updating post A.

So I am using it to a create a totally different post of a different custom post type and I am just taking some data from the post I am saving, so it shouldn’t bring an infinite loop as I am talking about two different posts not the same post.

This worked well in the classic editor, however it didn’t work with the block editor. I even tried to use the remove_action then re-add add_action recommendation mentioned in the documentation for wp_update_post but still it gave the same error.

Understood, different posts, but it’s still the same action hook which fires for any post insertion. Is your callback checking the passed post data to ensure it does not try to add another new post due to insertion of its initial new post? So that the post B insertion will not cause a post C to be inserted? In effect removing your action callback should have the same result, but removing an action is blind to context, checking post data is context specific.

How do you add the action back again afterwards? I’m thinking there could be a race condition where it’s added back before WP gets a chance to finish inserting a post, so it gets called again anyway. A difference of a few microseconds, but it’s possible in a multi-threaded environment. And block editor saves take much longer than classic editor by going through the API. Checking data might be a better approach, the problem being how does you callback know when it is called due to post B insertion and not post A?

Or are you sure you need to add your callback back in? It’s no longer needed after the first time through, right? It’ll be in place for the next save request even if it is removed and not added back for the current save request.

Thanks @bcworkz for your support. Actually the hook doesn’t fire again as I have a condition to check if a new term is added to the post A so I add its data to post B. Post B will never have a new taxonomy term so the hook will not fire when adding post B. This is my function. I should have added it in the beginning but I thought that talking as a concept would have been enough. I am sorry for that.

Regarding removing the action and re-add it. This was just a kind of troubleshooting but I removed it afterwards as I found it won’t help.

function add_new_term_from_post($post_id) {
      $settings_options = get_option('settings_options');
      if($settings_options['redirect-directly'] === "1") {

        $post_taxonomies = get_post_taxonomies($post_id);
        wp_defer_term_counting(true);

        foreach ($post_taxonomies as $post_taxonomy) {
          if (in_array($post_taxonomy, $settings_options['show_taxonomies'])) {
          $post_taxonomy_terms = wp_get_post_terms($post_id, $post_taxonomy);

          foreach ($post_taxonomy_terms as $post_taxonomy_term) {

            if($post_taxonomy_term->count === 1 ) {
          if($post_taxonomy_term->name !== NULL && $post_taxonomy_term->name !== NULL && $post_taxonomy_term->name !== NULL) {

    $term_post = array(
      'post_title'    => $post_taxonomy_term->name,
      'post_content'  => $post_taxonomy_term->name,
      'post_excerpt'  => $post_taxonomy_term->name,
      'post_status'   => 'publish',
      'post_type'     => 'whatever'
    );
    if(post_exists($post_taxonomy_term->name, "", "", "whatever") === 0) {
      wp_insert_post($term_post);
        }
      }

              }
            }
          }
        }
        wp_defer_term_counting(false);
      }
    }
    add_action('save_post', 'add_new_term_from_post');

• This reply was modified 5 years, 7 months ago by bebro.
• This reply was modified 5 years, 7 months ago by bcworkz. Reason: code fixed

OK, I see. That explains why it worked in classic editor. I think it fails with the block editor due to a race condition. As I mentioned, API saves take much longer, especially if you want to get newly added taxonomy terms. Putting in a delay to wait for the API to finish would be a terrible bodge. Perhaps try getting any taxonomy terms out of the $_POST data instead of the DB?

Despite breaking the possible infinite loop by checking for assigned terms, it still might be a good idea to remove your callback from the action before inserting the “whatever” post. Or better yet, if the initial post with taxonomy terms is a different post type than “whatever” type, use the type specific hook "save_post_{$post->post_type}". So if the post with terms is a regular post post type, hook “save_post_post”.