3

I'm developing a system where a post can have multiple replies/feedbacks. As of now I's storing each of the comments as a serialized postmeta. But just today I figured out that I can use the existing comments table for the same purpose, and where there is a commentmeta table I can store additional data there too.

So I came up using the wp_insert_comment(), and I hope more robust one is wp_new_comment(), where I introduced with the comment_type parameter. I found that it stores:

  • null for default comment type 'comments',
  • pingback for 'pingbacks', and
  • trackbacks for 'trackbacks'

As it seems similar to wp_posts' post_type column, but is that actually is like that? Is it safe storing my custom comment_type there to keep trace of certain types of comments/feedbacks?

5

Comment type is similar to post type, because it allow to query only a specific type of comments, just like post type allow to query one or more post types.

And just like core post types (page, post) there are core comment type as well: 'comment', 'pingback', 'trackback'.

A difference between the two is that, by default, WP_Query do not fetch post types that are not explicilty required, but only the 'post' post type.

On the countrary, WP_Comment_Query, by default, fecth all comment types.

A lot of themes use wp_list_comments() to show comments.

That function has a 'type' argument that allow to set the comment type to show.

If you look at, for example, default themes, that function is used without the type argument. It means that, even if you use a custom comment type, that special comments will be shown among "regular" comments by most of the themes.

To overcome this issue you can use the 'pre_get_comments' hook to prevent your custom comment types to be fetched along "standard" comment types:

/* Assuming 'my_custom_comment_type' is the name of custom comment type */

add_action( 'pre_get_comments', function(\WP_Comment_Query $query) {
   /* only allow 'my_custom_comment_type' when is required explicitly */
   if ( $query->query_vars['type'] !== 'my_custom_comment_type' ) {
      $query->query_vars['type__not_in'] = array_merge(
          (array) $query->query_vars['type__not_in'],
          array('my_custom_comment_type')
      );
   }
});

Using code above, you can safely use 'my_custom_comment_type' to store comments that will be not mixed up with standard comments.

After that, when you need to fetch your custom comments, you need to explicitly pass the comment type slug, and everything should work fine.

However, note that functions normally used to retrieve comments, like wp_list_comments() or get_comments() automatically exclude comments that are not approved (or spam).

In fact, depending on your settings, if you use wp_new_comment() to store your custom comments, it is possible that they are stored as not approved and you will not able to fecth those comments even if explicitly using proper 'type' argument.

To avoid this, there are 3 possibilities:

  • always use the 'status' argument of WP_Comment_Query (or get_comments()) set to "all" when fetching custom comments type: this way all comments will be fecthed no matter if approved or not
  • use the more low-level wp_insert_comment() to save the comment, and set 'approved' argument to 1
  • use the filter 'pre_comment_approved' to always store as approved comments having your custom comment type:

    add_filter( 'pre_comment_approved', function( $approved, $data ) {
        return isset($data['comment_type']) && $data['comment_type'] === 'my_custom_comment_type'
           ? 1
           : $approved;
    }, 20, 2);
    
  • Thanks a lot. Another more in-depth answer from you - thanks a lot. [1] Anyway, I found 'comment_approved' parameter is working for wp_new_comment() too - so currently with your suggestion, I can insert new comment successfully. [2] I'm not actually concerned about the pre_get_comments action hooking, because If my custom comment has comment_post_ID 111 it won't show up at the post 112 - isn't that? Though a fail safe is always better. I'm now stuck with another issue, probably I'll ask another. – Mayeenul Islam May 6 '15 at 5:28
  • I updated the Codex page with the tested example. Please have a look if I'm right, or not. :) – Mayeenul Islam May 6 '15 at 5:42
  • @MayeenulIslam the line you linked proof that 1. wp_new_comment() ovverride 'comment_approved' field with the result of wp_allow_comment(), no matter what you passed. 2. If you insert the comment for a post it will be visible on that post, but if that post has other kind of comments they will be mixed. Moreover, things like widgets that show last comments may show your comment. 3. Your Codex example is wrong because of #1,: you can pass `'comment_approved' argument, but it will be just overridded. – gmazzap May 6 '15 at 8:06
  • do I revert the Codex edit? – Mayeenul Islam May 6 '15 at 8:10
  • Don't have time to see how it was before, if you just added 'comment_approved' than yes, I think is better to revert, otherwise just delete that line @MayeenulIslam – gmazzap May 6 '15 at 8:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.