Include the comment type when showing the comment table list in wp-admin

[josephscott]

For Javascript that would like to enhance the comment table list in wp-admin ( wp-admin/edit-comments.php ) it would be really handy to have the comment type included in the HTML. This would allow Javascript to apply the changes to specific comment types easily.

I'm including a patch that does this by adding an attribute to the TR : data-commenttype. TR entries would look like:

<tr id='comment-191' class='unapproved' data-commenttype='pingback'>
<tr id='comment-190' class='approved' data-commenttype='comment'>

and so on.

I choose data-commenttype as the name to avoid the confusing rewrite situation that happens with data-* attributes. The other style that would have been safe would be data-comment_type, but I think that would be even more confusing.

[westi]

Why not just add this information as css classes so that is can also easily be used for custom styling of the rows etc?

We should probably just be using comment_class() here.

[josephscott]

I'm not a huge fan of overloading CSS class names, but that is something that could be done. I've uploaded a diff with that ( comment-table.2.diff ) using comment_class() and you end up with TRs that look like:

<tr id='comment-191' class='pingback even thread-even depth-1 unapproved'>
<tr id='comment-190' class='comment byuser comment-author-admin bypostauthor odd alt thread-odd thread-alt depth-1 approved'>

[josephscott]

Nacin asked about a version using just comment_class(), something I'd done originally when working on the second version of the patch. You can see it here - ​http://pastebin.com/LGes0Siq - I ended up going with get_comment_class() because it felt like a cleaner change.

[nacin]

comment-table.2.diff​ looks good, but what are the chances of those classes conflicting with core or plugin admin CSS?

[josephscott]

Replying to nacin:

comment-table.2.diff​ looks good, but what are the chances of those classes conflicting with core or plugin admin CSS?

I'm not sure, another reason why I went with the data-* attribute, it avoids styling collisions.

That said, so far I haven't seen any issues for core. Plugins would be the great unknown (as usual).

[westi]

Replying to nacin:

comment-table.2.diff​ looks good, but what are the chances of those classes conflicting with core or plugin admin CSS?

I think it is better practise to re-use the same classes as we make available on the front end.

We should probably do this in other places where we have a object_class function available too.

[westi]

In [18594]:

Include all comment css classes when outputing the rows in the Comments admin page to allow for easy customisation by plugins. Fixes #18447 props josephscott.

[westi]

In my "minor" change to joseph's patch I broke the comment action links because they rely on the status global :(

[westi]

In [18599]:

Fix the action links broken by [18594]. Fixes #18447.