WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 2 months ago

#12668 reopened enhancement

Better support for custom comment types

Reported by: ptahdunbar Owned by: ptahdunbar
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Comments Keywords:
Focuses: Cc:

Description

Similar to the improved support for custom post types #9674, we really need better support for custom comment types. At the database layer, this is completely supported and is used for post type comments, trackbacks and pingbacks. The code just needs to be decoupled into standard APIs.

Specifically, we'll need APIs for registering comment types, and comment statuses so the admin interface (edit-comments.php) can support them.

I'll be working on a patch, although feel free to provide your own patches, ideas and insights :)

Change History (28)

comment:1 mikeschinkel4 years ago

  • Cc mikeschinkel@… added

Interesting idea. If comments were moved to be in the wp_posts table with post_type='comment' then a lot of functionality would come for free?

comment:2 follow-up: nacin4 years ago

Cross-referencing #10856. Should be handled together.

comment:3 unsalkorkmaz4 years ago

  • Cc unsalkorkmaz added

comment:4 johnbillion4 years ago

  • Cc johnbillion@… added

comment:5 alex-ye3 years ago

Good idea , I will try to creating my patch also ...

comment:6 bainternet3 years ago

  • Cc bainternet added

comment:7 gruvii3 years ago

  • Cc gruvii added

comment:8 follow-up: gruvii3 years ago

Would love to see comments in the wp_posts table. There are infinite possiblities especially taxonomies for the comments etc.

comment:9 in reply to: ↑ 8 nacin3 years ago

Replying to gruvii:

Would love to see comments in the wp_posts table. There are infinite possiblities especially taxonomies for the comments etc.

I don't see this ever happening. That said, you can already do taxonomies on comments. That it's difficult (and that you don't really know about it) is more about deficiencies in the taxonomy system rather than the comments system.

comment:10 in reply to: ↑ 2 mitchoyoshitaka3 years ago

  • Cc mitcho@… added

Replying to nacin:

Cross-referencing #10856. Should be handled together.

I don't see why these two should be handled together. #10856 involves the migration/removal of a few columns from the comments table. This bug is about API's for comment type registration and handling... the comment_type column already exists.

comment:11 jane2 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Two years without a patch, so I'm closing. Reopen if there's a patch to be reviewed.

comment:12 nacin2 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Re-closing as maybelater. If we do a comment/feedback loop in 3.5 or 3.6, this will almost certainly get hit.

comment:13 nacin2 years ago

  • Resolution set to maybelater
  • Status changed from reopened to closed

comment:14 follow-up: mordauk16 months ago

  • Cc pippin@… added

I'd love to see this discussed again. Here's an example of why I'd like to use it:

In Easy Digital Downloads, we use comments on our payments post type to track info related to individual purchases, and also for allowing store owners to leave notes about individual orders. Comments work exceptionally well for this, except they start showing up in recent comment widgets, which is not optimal, especially when notes may contain sensitive information.

I'd love to be able to register a custom comment type that would be automatically excluded from recent comment streams (since they would only pull in core comment types by default). This would give us a much more granular level of control.

comment:15 in reply to: ↑ 14 MikeSchinkel16 months ago

  • Cc mike@… added

Replying to mordauk:

I'd love to see this discussed again.

+1. I'd like to build a plugin that uses comments for Twitter status updates tied to a Twitter Account periodic post (daily, weekly, monthly) with a parent post for Twitter account.

I'd also like to build another plugin that uses comments to manage support requests for a support ticketing system.

And another plugin that uses comments for suggested improvements to pages like how php.net has comments, but with the goal of improving the page, marking the suggestion complete, and then hiding the suggestion during normal page view. My use-case is for internal use for using WordPress for creating user documentation.

comment:16 dcowgill16 months ago

  • Cc dcowgill@… added

comment:17 gvenk12 months ago

  • Cc gvenk added

comment:18 joshlevinson10 months ago

  • Cc joshlevinson added

I could see types becoming very useful. For example, along with registering a post type, I could register a comment type ( think Products with Product FAQs and Product Reviews ). Querying, submitting, and segregating these different types of comments would be easier done as a comment type IMHO.

I'm thinking about tackling this, but the repercussions of changing this extend into many areas of the admin and obviously into the core of comments itself. I am considering re-working edit-comments.php to behave similar to edit.php in that it can be used for editing custom types.

Technically, comment types are already possible (albeit in a bare-bones manner) in that if you alter a comment in the database by putting something in the comment_type field, then visit /wp-admin/edit-comments.php?comment_type=abc, the listed comments will be filtered and your single comment will be present, inheriting all the functionality of the comment list table view. This is because WP is already setup to filter the displayed comments by comment type, although only with the built-in pingback and trackback in mind.

I have been able to replicate much of the functionality of register_post_type, along with it's related functions like get_post_type_object, get_comment_types, etc.

What is hanging me up is whether or not to actually register the default comment types with the new register_comment_type functions, the same way that posts, pages, etc. are registered through register_post_type on init.

Any thoughts on this?

My gut tells me that this is the correct avenue, but I also think that doing so will require a significant re-work of how comments already work (but maybe not, that's why I'm asking). Sorry for the book, I'm just trying to lay out my thoughts on the matter.

Last edited 10 months ago by joshlevinson (previous) (diff)

comment:19 andymacb9 months ago

  • Cc am@… added

comment:20 SergeyBiryukov6 months ago

#25674 was marked as a duplicate.

comment:21 sc0ttkclark6 months ago

  • Cc lol@… added
  • Resolution maybelater deleted
  • Status changed from closed to reopened

I opened #25674 because I couldn't find this one.

We could port most of the Post Type handling internals like register_post_type > register_comment_type and get_post_type > get_comment_type which would make this implementation in core easier. We could also register the built-in types like comment/pingback etc

Then, comment_type could be implemented like post_type is in edit.php, for the comments page, and allow for the new comment types to be added into their own menus.

I love the potential of what Custom Comment Types can bring, but unfortunately not having an API to work with them can make it cumbersome to build with.

I can make a first pass at a patch on this if anyone is interested in moving this forward.

I ended up making a new GitHub repo for a functionality proposal. It's a work in progress and is open to contributors and pull requests.

http://github.com/sc0ttkclark/wp-custom-comment-types

comment:22 sbrajesh6 months ago

  • Cc brajesh@… added

comment:23 SergeyBiryukov6 months ago

  • Milestone set to Awaiting Review

comment:24 sbruner6 months ago

  • Cc sbruner@… added

comment:25 meloniq5 months ago

  • Cc meloniq@… added

comment:26 judgej3 months ago

+1

I would love to see this functionality expanded too. We already have popular plugins such as WooCommerce that use their own custom comment type ("order_notes", against the "shop_order" post type) and fill up the comments table quickly. This slows a site down substantially, as the core WP does not recognise these custom comment types as distinct from the standard comments against public posts when doing its counts of comments to be approved/latest comments etc.

I've raised it also as a question here:

http://wordpress.stackexchange.com/questions/130809/what-is-the-point-of-get-comment-count-if-you-cannot-limit-by-a-comment-type

comment:27 mordauk2 months ago

For plugins that store things like order notes, or other private data, there are three filters that have to be used if the plugin wants to:

  1. Remove the custom comment type from the general comment queries (recent comments widget for example)
  2. Remove the custom comment type from comment feeds
  3. Remove the custom comment type from comment counts

To do this, plugins have to use 3 separate filters, the last one being pretty expensive (causes a lot of slow queries on sites with a lot of comments):

<?php
/**
 * Exclude notes (comments) on edd_payment post type from showing in Recent
 * Comments widgets
 *
 * @since 1.4.1
 * @param array $clauses Comment clauses for comment query
 * @param obj $wp_comment_query WordPress Comment Query Object
 * @return array $clauses Updated comment clauses
 */
function edd_hide_payment_notes( $clauses, $wp_comment_query ) {
    global $wpdb;

        $clauses['where'] .= ' AND comment_type != "edd_payment_note"';
    return $clauses;
}
add_filter( 'comments_clauses', 'edd_hide_payment_notes', 10, 2 );


/**
 * Exclude notes (comments) on edd_payment post type from showing in comment feeds
 *
 * @since 1.5.1
 * @param array $where
 * @param obj $wp_comment_query WordPress Comment Query Object
 * @return array $where
 */
function edd_hide_payment_notes_from_feeds( $where, $wp_comment_query ) {
    global $wpdb;

        $where .= $wpdb->prepare( " AND comment_type != %s", 'edd_payment_note' );
        return $where;
}
add_filter( 'comment_feed_where', 'edd_hide_payment_notes_from_feeds', 10, 2 );


/**
 * Remove EDD Comments from the wp_count_comments function
 *
 * @access public
 * @since 1.5.2
 * @param array $stats (empty from core filter)
 * @param int $post_id Post ID
 * @return array Array of comment counts
*/
function edd_remove_payment_notes_in_comment_counts( $stats, $post_id ) {
        global $wpdb, $pagenow;

        if( 'index.php' != $pagenow ) {
                return $stats;
        }

        $post_id = (int) $post_id;

        if ( apply_filters( 'edd_count_payment_notes_in_comments', false ) )
                return $stats;

        $stats = wp_cache_get( "comments-{$post_id}", 'counts' );

        if ( false !== $stats )
                return $stats;

        $where = 'WHERE comment_type != "edd_payment_note"';

        if ( $post_id > 0 )
                $where .= $wpdb->prepare( " AND comment_post_ID = %d", $post_id );

        $count = $wpdb->get_results( "SELECT comment_approved, COUNT( * ) AS num_comments FROM {$wpdb->comments} {$where} GROUP BY comment_approved", ARRAY_A );

        $total = 0;
        $approved = array( '0' => 'moderated', '1' => 'approved', 'spam' => 'spam', 'trash' => 'trash', 'post-trashed' => 'post-trashed' );
        foreach ( (array) $count as $row ) {
                // Don't count post-trashed toward totals
                if ( 'post-trashed' != $row['comment_approved'] && 'trash' != $row['comment_approved'] )
                        $total += $row['num_comments'];
                if ( isset( $approved[$row['comment_approved']] ) )
                        $stats[$approved[$row['comment_approved']]] = $row['num_comments'];
        }

        $stats['total_comments'] = $total;
        foreach ( $approved as $key ) {
                if ( empty($stats[$key]) )
                        $stats[$key] = 0;
        }

        $stats = (object) $stats;
        wp_cache_set( "comments-{$post_id}", $stats, 'counts' );

        return $stats;
}
add_filter( 'wp_count_comments', 'edd_remove_payment_notes_in_comment_counts', 10, 2 );

These are the filters we use in Easy Digital Downloads. You may notice that in the last one we included a check that causes it to just exit early if not on index.php. We discovered that this was resulting in a lot of slow queries and so had to disable it everywhere but index.php

If we had a true way of handling custom comment types, we could avoid all of this mess.

Last edited 2 months ago by DrewAPicture (previous) (diff)

comment:28 amolv2 months ago

#27089 was marked as a duplicate.

Note: See TracTickets for help on using tickets.