[wp-trac] [WordPress Trac] #61773: get_posts() returns posts of removed custom post type

[WordPress Trac]

#61773: get_posts() returns posts of removed custom post type
-------------------------------+------------------------------
 Reporter:  rajanit2000        |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:
-------------------------------+------------------------------

Comment (by rajanit2000):

 The current behavior of the get_posts() function and WP_Query class, where
 posts from an unregistered custom post type are still returned, can be
 seen as consistent with the expectation that these functions should return
 what is in the database. However, there are several potential issues with
 this behavior.

 Firstly, it can lead to inconsistencies and unpredictability for
 developers, who typically expect functions to behave consistently. When a
 custom post type is unregistered, it no longer appears to be part of the
 site’s structure, and continuing to return posts from such a type can lead
 to confusion and unexpected results.

 Secondly, unregistered post types may indicate that the data is no longer
 intended to be used or displayed, and returning posts from these types can
 complicate data management and content strategies by potentially
 displaying outdated or irrelevant content.

 Thirdly, requiring developers to manually check for unregistered post
 types before calling get_posts() adds extra complexity to their code,
 making it less robust and harder to maintain.

 Fourthly, there are security implications, as unregistered post types
 might be used to store sensitive or restricted content, and automatically
 returning such posts without verification can lead to unintended data
 exposure.

 Lastly, while handling unregistered post types might seem like an edge
 case, it can occur more frequently in larger, dynamic sites or during
 development and testing phases.

 Addressing this within the core function makes the WordPress ecosystem
 more resilient and user-friendly. To resolve these issues while
 maintaining flexibility, an enhancement is proposed that introduces a new
 argument, unregistered_post, to the get_posts() function and WP_Query
 class. This argument defaults to false, ensuring unregistered post types
 are excluded by default, but allows developers to include posts from
 unregistered types by setting this argument to true.

 This approach balances returning all data by default with providing an
 easy mechanism to exclude unregistered post types when needed, enhancing
 the predictability, security, and usability of the get_posts() function.

 Replying to [comment:2 knutsp]:
 > What is the prolem with the current behaviour?
 >
 > I would expect it to return what's in the database, and if I wanted to
 exclude unregistered posts, even when I explicitly specify a possibly
 unregsitered post type, to check that before calling get_posts. This very
 edge case, I think.

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