[wp-trac] [WordPress Trac] #20977: Add Dynamic Comment Statuses

WordPress Trac noreply at wordpress.org
Wed Jun 3 06:48:46 UTC 2015


#20977: Add Dynamic Comment Statuses
--------------------------------------+------------------------------
 Reporter:  supercleanse              |       Owner:
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Comments                  |     Version:  3.4
 Severity:  normal                    |  Resolution:
 Keywords:  needs-patch dev-feedback  |     Focuses:
--------------------------------------+------------------------------

Comment (by Oxymoron):

 In response 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.

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


More information about the wp-trac mailing list