[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