[wp-trac] [WordPress Trac] #63850: Avoid doing an extra call to cache/wpdb when post_id is not valid

[WordPress Trac]

#63850: Avoid doing an extra call to cache/wpdb when post_id is not valid
-------------------------------+-----------------------------
 Reporter:  bor0               |       Owner:  SergeyBiryukov
     Type:  defect (bug)       |      Status:  closed
 Priority:  normal             |   Milestone:  6.9
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:  fixed
 Keywords:  has-patch          |     Focuses:
-------------------------------+-----------------------------

Comment (by Howdy_McGee):

 Hello!

 I'm a plugin author who used negative WP_Post IDs and am unfortunately
 affected by this change. I'd like to explain why and hopefully work to
 find a workaround for this core update.

 WordPress endpoints are... obtuse. This is doubly so when I need many
 endpoints / dynamic endpoints for custom frontend systems. It's multi-step
 and exhausting. I've personally found it much easier to inject my endpoint
 rewrites (via filters) and provide WordPress with a faux WP_Post object at
 the top of load `wp` so that there's easy / seamless template integration.

 I understand there are various hooks for `the_content`, `the_title`,
 `document_title_parts` and more, but these quickly add up when instead I
 was previously able to associate these value with the Faux WP_Post and
 have the theme template functions pull in the endpoint specific values
 organically. Additionally, having the Faux WP_Post set at a high level
 (wp) provides additional easy associations when integration with other
 plugins that may $_POST values when working with custom endpoints or more.

 Previously, it was pretty benign since negative numbers still wouldn't end
 up in the database. The additional queries could be circumvented and
 prevented. For example, the negative number could be cached preventing the
 `get_row()` query.

 Would it be feasible to add a hook onto `WP_Post::get_instance()` for the
 returned value, verifying that the filtered value is an instance of
 `WP_Post` or returning false? Otherwise, are there any other suggestions
 on how to go about creating a Faux WP_Post object? I really do think there
 is a use for this seeing as how integrated the WP_Post object is to
 WordPress Core and template display.

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