[wp-trac] [WordPress Trac] #19623: Use Comment API in comments_template, rather than hardcoded SQL

[WordPress Trac]

#19623: Use Comment API in comments_template, rather than hardcoded SQL
-------------------------------------------------+-------------------------
 Reporter:  simonwheatley                        |       Owner:
     Type:  enhancement                          |  boonebgorges
 Priority:  normal                               |      Status:  accepted
Component:  Comments                             |   Milestone:  4.1
 Severity:  major                                |     Version:  3.3
 Keywords:  has-patch needs-testing 2nd-opinion  |  Resolution:
                                                 |     Focuses:
-------------------------------------------------+-------------------------
Changes (by boonebgorges):

 * keywords:  has-patch needs-testing 4.1-early => has-patch needs-testing
     2nd-opinion
 * owner:   => boonebgorges
 * status:  new => accepted
 * milestone:  Future Release => 4.1


Comment:

 Circling back around to this, because I'd like to get another opinion or
 two before moving forward with the fix suggested in
 [attachment:19623.03.patch]. IMHO, the params 'unapproved_user_id',
 'unapproved_author', and 'unapproved_author_email' are very clunky. Their
 semantics overlap with each other and with 'status' in awkward ways, and
 it will be very important to document how they override other params (so
 that, eg, passing 'unapproved_author' with 'status=approve' means that not
 all the returned comments will actually be approved).

 A much more elegant - but more complicated - solution would be to allow
 more fine-grained 'status' queries. Let's say (and here I'm just tossing
 out a possible syntax) your status argument looked like this:

 {{{
 'status' => array(
     'relation' => 'OR',
     array(
         'status' => 'approve',
     ),
     array(
         'status' => '0',
         'author_email' => 'foo at example.com',
     ),
 ),
 }}}

 This would be a general framework for complex status queries, and would
 simultaneously fix #29612.

 I think that this kind of framework is probably more than is feasible for
 4.1. But I want the record to show that I think it's probably the kind of
 thing we should be shooting for in the medium to long term. And I don't
 want the decisions made in the short term to affect these longer term
 plans. In the current case, it's fairly easy to see how
 'unapproved_author_email' etc could, at some point in the future, be
 translated into a query of the syntax above. So, I do think that the
 suggested fix is probably good enough for us to fix the problem for 4.1
 (and it's definitely better than doing nothing at all). But I wanted to
 throw this comment out there to see if anyone had ideas for a slightly
 more elegant approach to the issue.

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