[wp-trac] [WordPress Trac] #36208: Comment queries should ignore comments associated with non-active custom post types

[WordPress Trac]

#36208: Comment queries should ignore comments associated with non-active custom
post types
------------------------------------------+-----------------------------
 Reporter:  Clorith                       |       Owner:
     Type:  defect (bug)                  |      Status:  new
 Priority:  normal                        |   Milestone:  Future Release
Component:  Comments                      |     Version:  4.4
 Severity:  normal                        |  Resolution:
 Keywords:  needs-patch needs-unit-tests  |     Focuses:
------------------------------------------+-----------------------------

Old description:

> As of 4.4 we introduced the `_doing_it_wrong()` (r34091) when checking
> meta capabilities on custom post types that aren't registered.
>
> This also spread and affected comments, primarily on the dashboard where
> we show comments and try to add links for these and check the users
> capability against them, they will produce this wonderful output:
>
> > PHP Notice:  map_meta_cap was called <strong>incorrectly</strong>. The
> post type shop_order is not registered, so it may not be reliable to
> check the capability "edit_post" against a post of that type. Please see
> <a href="https://codex.wordpress.org/Debugging_in_WordPress">Debugging in
> WordPress</a> for more information. (This message was added in version
> 4.4.0.) in /wordpress/wp-includes/functions.php on line 3827
>
> Ideally, `WP_Comment_Query` should bypass comments associated to non-
> existing post types as well.
>
> In the attached patch I've introduced both `post_type__in` and
> `post_type__not_in` which accepts an array of post type string names.
>
> I've also added the default value for `post_type__in` to
> `get_post_types()`, as by default you'd never want to query for non-
> existing data any way, but this allows the query to be overwritten via
> filters, or directly with a new construct for those who have the need.
>
> I am wondering if the use of `post_type = 'any'` would need to short-
> circuit the new arguments to avoid breaking BC (current tests all pass
> with the patch applied though) ?
>
> Related #16956

New description:

 As of 4.4 we introduced the `_doing_it_wrong()` (r34091) when checking
 meta capabilities on custom post types that aren't registered.

 This also spread and affected comments, primarily on the dashboard where
 we show comments and try to add links for these and check the users
 capability against them, they will produce this wonderful output:

 > PHP Notice:  map_meta_cap was called <strong>incorrectly</strong>. The
 post type shop_order is not registered, so it may not be reliable to check
 the capability "edit_post" against a post of that type. Please see <a
 href="https://codex.wordpress.org/Debugging_in_WordPress">Debugging in
 WordPress</a> for more information. (This message was added in version
 4.4.0.) in /wordpress/wp-includes/functions.php on line 3827

 Ideally, `WP_Comment_Query` should bypass comments associated to non-
 existing post types as well.

 In the attached patch I've introduced both `post_type__in` and
 `post_type__not_in` which accepts an array of post type string names.

 I've also added the default value for `post_type__in` to
 `get_post_types()`, as by default you'd never want to query for non-
 existing data any way, but this allows the query to be overwritten via
 filters, or directly with a new construct for those who have the need.

 I am wondering if the use of `post_type = 'any'` would need to short-
 circuit the new arguments to avoid breaking BC (current tests all pass
 with the patch applied though) ?

 Related #16956

 What this looks like (from #34918):

 [[Image(http://crosseyedeveloper.com/wp-
 content/uploads/2015/12/commentcap.jpg)]]

 It also shows up on the Dashboard in the comments widget:
 [[Image(http://crosseyedeveloper.com/wp-
 content/uploads/2015/12/commentcap21.jpg)]]

--

Comment (by chriscct7):

 In #34918, a exact duplicate, there was discussion that followed a
 different approach than the one on this ticket. Therefore, while closing
 #34918 as duplicate of this ticket, I've updated this ticket's description
 with some information the other had, and will quickly summarize the
 patches + discussions of the other ticket, as it took a different approach
 to solving the issue.

 It was pointed out that hiding the comments of post types that don't
 exist/inactive would make them inpossible to edit or remove. It was then
 noted that while this was likely by design, WordPress does not show posts
 from unregistered post types, and thus this served as an argument to hide
 comments that are orphaned.

 The ticket consensus then agreed that it made sense to hide posts if the
 post type they are connected to is "gone", particularly from a consistency
 standpoint.

 Component maintainer, @boonebgorges agreed to this approach
 (https://core.trac.wordpress.org/ticket/34918#comment:10), and then a
 patch was produced (attaching it below) that hides the errors in the
 comments list table by checking to see if the post type object exists.
 This patch however, did not address the implications of a plugin using a
 wp comment query or the dashboard widget.

 @Funkatronic, @jdgrimes, @lukecavanagh, @nekojira, @obrienlabs, @wesm87

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