WordPress.org

Make WordPress Core

Opened 8 months ago

Last modified 5 months ago

#51852 assigned defect (bug)

"any" value in "post_type" param in "get_posts" by default ignore attachments

Reported by: dam6pl Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Query Keywords: needs-patch needs-unit-tests early
Focuses: docs Cc:

Description

When creating a simple call to get all posts for all post types by default to the parameters are adding post_status parameter with publish value.

<?php
get_posts(['post_type' => 'any']);

To the WP_Query instance are supplied followed arguments:

<?php //wp-includes/post.php:2053
[ 
  "numberposts" => 5
  "category" => 0
  "orderby" => "date"
  "order" => "DESC"
  "include" => []
  "exclude" => []
  "meta_key" => ""
  "meta_value" => ""
  "post_type" => "any"
  "suppress_filters" => true
  "post_status" => "publish"
  "posts_per_page" => 5
  "ignore_sticky_posts" => true
  "no_found_rows" => true
]

All attachment posts have inherit post status so by default are ignored in this query.

To actually get all post types the first function parameters should be expended by post_status parameter with ['publish', 'inherit'] value.

<?php
get_posts(['post_type' => 'any', 'post_status' => ['publish', 'inherit']]);

Attachments (1)

51852.diff (695 bytes) - added by peterwilsoncc 8 months ago.

Download all attachments as: .zip

Change History (7)

#1 @peterwilsoncc
8 months ago

  • Component changed from General to Query
  • Keywords needs-patch needs-unit-tests added

@dam6pl Hello and welcome to trac.

I've been able to reproduce this issue (or more accurately, hit it recently).

I suspect the reason behind this is because there would need to be fairly unperformant database queries in order to correctly determine the attachment's inherited status based on the parent post, ie does it inherit from publish or private. Knowing this becomes important when considering the user's permissions with the WP_Query perm argument.

This is not to rule out a fix but to let you know it's more complicated than it might appear at first so any fix is unlikely to have a quick turnaround as it's not a simple case of adding inherit.

Again, welcome and thanks for logging the report.

#2 @dam6pl
8 months ago

@peterwilsoncc fully understand and agree with you. But for me this behavior was unclear and I had to check the get_posts function source to find the reason so maybe it could be a good point to mention that somewhere in the documentation?

#3 @peterwilsoncc
8 months ago

  • Focuses docs added

Yes, some clearer docs can certainly be added.

Does this work:

I have added a docs focus to this ticket for the original commit to clarify.

@peterwilsoncc
8 months ago

#4 @peterwilsoncc
8 months ago

  • Milestone changed from Awaiting Review to 5.7

I have updated the WP_Query documentation in the developer handbook to note that the `inherit` status is also excluded from any.

In 51852.diff I have changed the get_posts() documentation to:

Retrieves an array of the latest posts, or posts matching the given criteria.

For more information on the accepted arguments, see the WP_Query documentation in the Developer Handbook.

The $ignore_sticky_posts and $no_found_rows arguments are ignored by this function and both are set to true.

Following out discussion above, I've moved this on to the 5.7 milestone for the documentation changes.

#5 @peterwilsoncc
6 months ago

In 50257:

Posts/Post Types: Improve documentation of get_posts().

Add references to WP_Query to the documentation of get_posts(). As the developer documentation for WP_Query includes an expanded explanation a full link to developer.wordpress.org is included rather than a standard @see.

Props dam6pl, peterwilsoncc.
See #51852, #51800.

#6 @lukecarbis
5 months ago

  • Keywords early added
  • Milestone changed from 5.7 to Future Release
Note: See TracTickets for help on using tickets.