Make WordPress Core

Opened 12 years ago

Last modified 5 years ago

#20977 new enhancement

Add Dynamic Comment Statuses

Reported by: supercleanse's profile supercleanse Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.4
Component: Comments Keywords: needs-patch dev-feedback
Focuses: Cc:

Description

It would be great to add some filters/actions that would allow plugin developers to add additional statuses to comments.

Change History (9)

#2 @chriscct7
10 years ago

  • Keywords needs-patch dev-feedback added

It actually appears this could be as simple as a filter in the return of get_comment_statuses()

#3 follow-up: @Oxymoron
10 years ago

Replying to chriscct7:

It actually appears this could be as simple as a filter in the return of get_comment_statuses()

I don't think so. I began working on this but after getting into it a bit I realized this was going to be a bit larger and I think we need to discuss the best approach.

Yes, we could add a filter to that function and allow people to add custom statuses- but there are other sections of core that would need to be updated to reflect this.

From what I have found so far, in wp-admin/edit-form-comment.php the 3 different comment statuses are hardcoded with a specific class and value that is unique to them but not specified in get_comment_statuses. Here is a snippet from there:

<label class="approved"><input type="radio"<?php checked( $comment->comment_approved, '1' ); ?> name="comment_status" value="1" /><?php /* translators: comment type radio button */ _ex('Approved', 'adjective') ?></label>

Currently, get_comment_statuses() is only referenced in the class-wp-xmlrpc-server.php file. In here, it is only being used to get the slugs for the different comment statuses.

It would be nice if we could refactor how the get_comment_statuses() function formats the data, but I don't think we can due to the need for backwards compatibility. That being said, I think we could adjust that function to have a $custom_statuses variable or something that can have a differently formatted array that we could attach an add_filter() to and merge with the existing $statuses array.

Then, wherever it is referenced (e.g. edit-form-comment.php) we can update it to not only list the existing hardcoded statuses but also loop through the new custom ones we added. We will first need to identify everywhere that comment statuses are referenced throughout core, but once we do that what I outlined above should work.

Let me know any thoughts on this- I could be wrong in my suggested approach but I think it would end up being backwards compatible while also allowing custom comment statuses.

Last edited 10 years ago by Oxymoron (previous) (diff)

#4 in reply to: ↑ 3 @rachelbaker
10 years ago

Replying to Oxymoron:
All your points here are correct. I made a similar note in #30965, which wouldn't be solved by the suggested approach of allowing the result to be filtered.

I see two possible approaches:

  1. Reworking get_comment_statuses() in a backwards compatible way to be *useful* outside the XMLRPC endpoints.
  2. Create a new function that everyone else (including the WP REST API and XMLRPC API can use) and eventually deprecate get_comment_statuses

Option 1 would be the ideal, if possible.

+1 For the goal of removing the hard-coded comment statuses in favor of a single function that returns all core comment statuses (including trash) and is filterable (for the addition of custom statuses).

Last edited 10 years ago by rachelbaker (previous) (diff)

This ticket was mentioned in Slack in #core-comments by rachelbaker. View the logs.


9 years ago

#6 @boonebgorges
9 years ago

#36594 was marked as a duplicate.

#7 follow-up: @rachelbaker
9 years ago

  • Milestone changed from Awaiting Review to Future Release

We don't really have a comment_status column in the database. We *DO* have comment_approved which can have a value of: 1, 0, spam or trash (check out those amazing mixed types!).

I want to understand the different use-cases for custom comment statuses. That would make it easier to know if we should solve this by adding a filter or two OR we need to add registration functions and handle more like custom post_status.

Last edited 9 years ago by rachelbaker (previous) (diff)

#8 in reply to: ↑ 7 @mymothersdaughter
8 years ago

Replying to rachelbaker:

We don't really have a comment_status column in the database. We *DO* have comment_approved which can have a value of: 1, 0, spam or trash (check out those amazing mixed types!).

I want to understand the different use-cases for custom comment statuses. That would make it easier to know if we should solve this by adding a filter or two OR we need to add registration functions and handle more like custom post_status.

Hi Rachel, would it be possible to add a "Read" function to the comment statuses? There are plenty of times where the comment is just a message which doesn't need to be approved and placed on the blog post. I will typically respond to it but leave it marked as Unapproved because it's not spam and I don't want to delete it. But I'd like to keep it but mark it "Read" so my number of Unapproved Comments can then go back to zero. Or even a way to move a comment to Feedback.

#9 @jeremyfelt
5 years ago

  • Milestone set to Future Release

I want to understand the different use-cases for custom comment statuses.

There are plenty of times where the comment is just a message which doesn't need to be approved and placed on the blog post.

+1

I'd like to approve comments as public (default) and private. This would allow me to clear the notification bubble and reply to someone's comment by email rather than display it publicly on my site while also keeping it for me to view in that context.

It's more of a stretch, but I could also see having a "draft" status for replies.

And to stretch even more—some kind of workflow for a site that gets a bunch of comments where a first level filters them out for final editorial approval.

(Added "Future Release" back because it seems like milestone disappeared entirely.)

Note: See TracTickets for help on using tickets.