Custom Comment Types

[aaroncampbell]

It's time to take another look at Custom Comment Types. We have a nice stable example in post types, but there's a lot to do here, so we'll use this as a centralized tracking ticket for everything. As such, I'm sure the description here will be fluid for a while as we figure out how much there is to do.

Here's a rough list of things that need to be looked at and addressed:

• UI/UX - In order for custom comment types to be really useful, we need to put some serious thought into the UI/UX surrounding comments in the admin.
• The comment_type field needs to start using 'comment' instead of '' for comments. This will mean an upgrade routine as well as some back-compat work.
• We need to decide what to do about non-default comment types in various admin areas (comments table, recent comments, etc). The thing that makes most sense is for WP_Comment_Query to be adjusted to only show default comment types (comments, pingbacks, and trackbacks) by default. Additional comment types would then be handled by whatever plugin or theme adds them. Unfortunately, this is a breaking change (comment:58:ticket:12668) because right now those areas show all comment types. Maybe we can create new management areas to be able to pull these out of the default one? Lets put our heads together.
• A lot of existing functions, like comment_type(), will need to be fixed to make room for newly registered comment types and their registered strings.

Previous tickets for history:
#25674
#12668

[Funkatronic]

Would it make sense to to add comments as a sub menu to post types like taxonomies are currently?

[rachelbaker]

@aaroncampbell +1 to all the items in your rough list and suggestion to call on the prior art in post_type.

[rachelbaker]

Related #34362

[dshanske]

What are the questions about the UI/UX?

[rachelbaker]

Update: @aaroncampbell and I discussed how we can move forward with this ticket in the ​#core-comments Slack channel.

Summary:

The biggest issue with tackling this ticket remains the UI presentation.

Specifically answers to questions such as:

• Should each custom comment type get it's own section within the WordPress dashboard menu, like registering a custom post type?
• If we don't allow comment type menu sections, should all registered comment types be included in the current Comments list table? Or should there be different list tables for each custom comment type?

We are going to start with a proof of concept for an API that allows custom comment types to be registered, register_comment_type(), which borrows heavily from the prior art in register_post_type(). The proof of concept will begin as a plugin, already setup by @aaroncampbell on Github: ​https://github.com/aaroncampbell/custom-comment-types/ and the .org repo: ​https://wordpress.org/plugins/custom-comment-types/

[rachelbaker]

Punting out of 4.6.

[rachelbaker]

#34362 was marked as a duplicate.

[rachelbaker]

Related: #34110 - challenges with comment types and pagination

[dshanske]

Related: #34106 I think as part of the changes to comments necessary for custom comment types, we should implement comments having their own permalinks which will address some of the pagination issues.

[rachelbaker]

Related #38200

[dshanske]

Was thinking about this, but being as custom comment types may have custom display needs, there needs to be a way to register a callback to handle display that can still be overridden by the usual methods.

Hoping that this project gets some interest as a future focus.

[jaswrks]

Example use case for custom comment types in Gutenberg.
​https://github.com/WordPress/gutenberg/pull/4685

I took a look at the GitHub repo mentioned in the ticket description. It seems like work has stalled on custom comment types? Or has it resumed in another ticket I'm unaware of?

In the use case for annotations in Gutenberg, others following this ticket might find it helpful to read over some conclusions I came to after work on an annotation API. I posted those thoughts here: ​https://github.com/WordPress/gutenberg/pull/4685#issuecomment-362785520

If Gutenberg annotations were implemented using a register_comment_type() extensibility feature in core, one of the most important considerations in private back-end annotations would be permissions. Like custom post types, it would be awesome if custom comment types supported the full range of meta-caps and the configuration of them.

[pfefferle]

Federated protocols, like Webmentions, ActivityPub and OStatus are gaining more and more importance and there are some WordPress implementations so far. I think custom-comment-types would help handling these different protocols and their different reaction types as "likes", "reposts", ...

I am working on a some of these plugins and have to produce a lot of bloat code to work around this problem.

Is there any hope to get some attention to this feature? I would love to help!

[pfefferle]

Regarding the UI question, I would vote for: List all types in the comment section, add a column and a filter, to allow select only one comment type.

[andraganescu]

@pfefferle I am also highly interested in this but at the moment know very little about all the indie web protocols that could make custom comment types useful. I will do more research but if you have a clear path or vision it would help to spell it out here so I could use it as pointers for my path forward.

Collaborative editing in Gutenberg could also benefit from having custom comment types as a way to store notes in the editor, like the work above on the annotations api concluded.

Let's all keep this alive :)

[pfefferle]

@andraganescu The IndieWeb defines different reactions (​https://indieweb.org/reactions) like classic replies, re-posts, RSVPs, likes and more.

I would love to see the possibility to group these reactions and to define different templates, like for example facepiles.

Here is an example of my hacks ;) ​https://notiz.blog/2019/11/06/hier-und-jetzt-open-web-4/#comments

[imath]

Hi !

Thanks a lot for everyone's work on this ticket so far. I've been looking deeply into it lately and started organizing a patch (from a local branch). I understood reading the description of this ticket and some comments, there are some huge challenges to accomplish and the road might be long (that's probably the reason a plugin has been considered and inited).

Here are my first suggestions about a possible road.

1) First I though about the semantics and came to the conclusion "Comments" should probably not be the name of the Admin Menu and step by step I feel we should think of a name that means "All possible informations/interactions in return of a post". I'm not english so I might have made a wrong choice, but I chose "Feedbacks". I believe this word allows types like :

• comments (text feedbacks),
• pings (automatic link notification feedbacks)
• trackbacks (manual link notification feedbacks)
• reactions (emoji like feedbacks)
• annotations (Gutenberg's project post content collaboration feedbacks),
• likes, reviews etc...

2) Then I thought about the Admin UI. I believe moving it into submenus of post types is not a good idea as existing feedbacks (comments, pings, trackbacks) can possibly relate to any post types. So it could add a lot of sub menus and we'd need to possibly overheat the feedback/comment queries to filter according to the post type. So I think a possible way of keeping it simple is to use an horizontal navigation. I took some inspirations from the Site Health Administration screen and here's how it could look like :

As you can see, I think in this case it's important to detail the comments count (or the feedbacks count) according to the type within this horizontal navigation.

3) I've started building some register_feedback_type(), create_initial_feedback_types(), get_feedback_type_object(), get_feedback_type_labels() etc.. functions and a WP_Feedback_Type class borrows heavily from the Post Types API.

There's still a lot of work to do before I can share a patch on this ticket. I thought before carrying on working on it, it would be wiser to have your opinions about these suggestions. So thanks in advance for your feedbacks 😉

[andraganescu]

I really like this Feedback menu proposal, both as interaction and as a way to sum up all the different kinds of "comment types". It seems to me easier to conceptualize feedback (singular is enough as it means all the feedback) as including comments, pings, mentions etc., rather than trying to understand what "comment types" may mean.

I like the idea of Feedback also because "post" is more abstract than "comment", and, hence, post types makes sense, while "comment types" doesn't, a comment being a far more concrete thing than a post.

One suggestion I have is that we keep the same menu pattern like the other items in the sidebar use: all the kinds of feedback should be a submenu item under Feedback, I don't see any need for that tabbed navigation in @imath 's mockup above.

@imath could this be a feature plugin at first (WordPress Feedback plugin, that implements all the registration and management for feedback types / kinds) and possibly involve more folks on GitHub?

[imath]

Thanks a lot for your feedback @andraganescu I forgot to explain why I chose the horizontal navigation :)

If the Feedback menu had submenus for Comments, Pings, Trackbacks (etc), I had no idea what to display for the Feedback Administration screen. I'm fine with using regular submenus, but then I'm very interested about content ideas for the Main menu's displayed page.

could this be a feature plugin at first

Sure!

[Funkatronic]

And also, any feedback types connected to specific post types should show up either as a submenu for that CPT or as a meta box in CPT pages themselves, or whatever the Gutenberg equivalent is

[paaljoachim]

I really like the horizontal navigation. As it keeps "Feedback" in one screen. Having the most used first and then the user can easily switch over to the other Feedback types. I also believe that the "Notification" area could be included in the horizontal navigation.

It would be very helpful and very much clean up the left sidebar if WordPress in general goes over to using horizontal navigation instead of submenus. This is though a larger part of a new UI/UX design in WordPress.

The above design is something for design folks to look closer at.
@karmatosed @joen @michaelarestad

[karmatosed]

Whilst I appreciate this exploration I think it's important to take a review of the current situation, projects being worked on and then look at the design.

There are a few places things like commenting is being worked on, the biggest of these is the new notifications project. That noted, it should therefore be a consideration before moving into anything like this.

From a design view, I think we need to consider more the work going on within the block editor and reflect patterns there over add new ones into wp-admin that maybe are a little out of step of that. Whilst I understand looking to site health, that is a project that isn't as current as the new work going into the editor, so we should take from there for patterns as a starting point.

Grouping everything into 'feedbacks' on surface might seem a great idea but really for users this could be confusing. What evidence is there this term is useful for others, outside of opinions? Perhaps we can consider other terminology but I think this needs to be worked out and designed from a need. What is the baseline need here? Then let's ask how we can bring in newer UI to meet that need.

Menu design and any IA change like this needs to be considered with regards to them bringing throughout, over just applying to one area. Let's do that as we take a step back.

It would also be great to see the design-feedback keyword used on tickets like this, it's important to get design feedback. Thanks @paaljoachim for looping me in.

[desrosj]

I am personally a -1 for "Feedback".

My brain draws a parallel to custom post types here, registering a new comment type creates a new menu. But, I could also see the custom types showing in the current comments area by default.

[knutsp]

Public comment types could be integrated in current Comments screen.
Private types could optionally cause a new menu and a simple editor, like post types, or handled by custom code.

Keep the simple set of supported features, best suited for external or front end user generated content, some very simple adding/editing for admin users. We have custom post types.

[imath]

Thanks a lot for your feedbacks.

I realize I may have diverged from the primary goals of the ticket 😬. What's expected is to leave existing types unchanged and do some adjustments for non default types

Maybe we can create new management areas to be able to pull these out of the default one

So I understand @desrosj & @knutsp opinions. I also understand @karmatosed concerns about the word "Feedback" that could possibly be confusing + UI changes are sensitive.

I'm going to follow this direction. Thanks again 👍

[dshanske]

I think, as someone who has struggled to add custom comment types, we need below the hood before we get to changing the admin.

Proposing in stage one we introduce a comment registration function based on the register post type and taxonomy functions, and all that entails. Then register the built-in types using that system. The built-in types will be part of comment query by default, with a filter to change the default list to something else, or back to everything. This will require modifying functions with hard-coded information to use the registered settings we decide on.

That is enough work to start before we contemplate changing how the admin screen is laid out.

[jeremyfelt]

Replying to dshanske:

I think, as someone who has struggled to add custom comment types, we need below the hood before we get to changing the admin.

Agreed. I think there are some general structural pieces that can be updated to make it nicer for custom comment types to exist without requiring big adjustments to UI/UX.

I like @dshanske's list of priorities, though I might even start with one of @aaroncampbell's original points on this ticket:

The comment_type field needs to start using 'comment' instead of for comments. This will mean an upgrade routine as well as some back-compat work.

This alone prevents the clean storage and detection of comment types, whether or not the admin should display them.

Maybe this ticket should be broken into other tickets that are more focused and used as a way to track overall progress?

[imath]

Hi @dshanske & @jeremyfelt

Thanks a lot for your feedbacks. I also agree to progress with smaller steps. Here's the step about using comment instead of '' for the wp_comments.comment_type field: #49236

[dshanske]

Now that #49236 is in 5.5, what's next?

[imath]

Hi @dshanske

I've been working on a plugin about "next", so I was thinking about sharing about it and try to progress from there organizing regular meetings ​on Slack's #core-comments channel.

Do you have other/better ideas?

[dshanske]

We haven't had regular comments meetings in ages. I am happy to attend and discuss(other obligations permitting, of course). And I've been thinking about this problem for a long time, and want to help move it forward.

[Ov3rfly]

The comment_type field needs to start using 'comment' instead of '' for comments. This will mean an upgrade routine as well as some back-compat work.

The current approach does/will lead to unexpected results, wrote more about this here https://core.trac.wordpress.org/ticket/49236#comment:36 in addition to #51082

[dshanske]

Okay, it has been a few years....we have comment as the comment type in Core. Is it time to move to the ability to register custom comment types in the backend next?