[wp-trac] [WordPress Trac] #12668: Better support for custom comment types

WordPress Trac noreply at wordpress.org
Wed Oct 15 01:15:24 UTC 2014


#12668: Better support for custom comment types
----------------------------------------+------------------------------
 Reporter:  ptahdunbar                  |       Owner:  ptahdunbar
     Type:  enhancement                 |      Status:  reopened
 Priority:  normal                      |   Milestone:  Awaiting Review
Component:  Comments                    |     Version:
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |     Focuses:
----------------------------------------+------------------------------

Comment (by boonebgorges):

 Thanks for the clarification on scope, mordauk and dancameron. I agree
 that it's best to start with a modest scope.

 The API-level changes proposed in
 https://core.trac.wordpress.org/attachment/ticket/12668/12668
 -get_approved_comments-WP_COMMENT_QUERY.patch (plus the `esc_sql()` later)
 look reasonable at a glance to me. I'd like to see unit tests both for
 `get_approved_comments()` and for array-formatted 'type' param in
 `WP_Comment_Query`.

 Some thoughts about core and default settings. Current behavior of the
 Dashboard widget, edit-comments.php, WP_Widget_Recent_Comments is to show
 all comment types. This is, of course, the very thing we're trying to
 "fix". But there are probably many cases where the existing behavior is
 being relied upon by users and by plugins. Changing the defaults for these
 UIs so that only core comments appear has the potential to confuse. And in
 the case of edit-comments.php, it's likely that in many cases, removing
 non-core comments from this display will make it impossible for users to
 moderate/edit custom comments. Some plugins will add their own interface,
 or will filter `admin_comment_types_dropdown`, but many will not. We might
 want to consider a more conservative route of keeping the current default
 behavior, but providing more robust filters, so that plugins that add
 custom comment types can easily exclude them from these interfaces. Do
 others have thoughts about this?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/12668#comment:58>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list