[wp-trac] [WordPress Trac] #64362: Support for Faux WP_Post Objects

[WordPress Trac]

#64362: Support for Faux WP_Post Objects
-------------------------------+-----------------------------
 Reporter:  Howdy_McGee        |      Owner:  (none)
     Type:  enhancement        |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Posts, Post Types  |    Version:
 Severity:  normal             |   Keywords:
  Focuses:                     |
-------------------------------+-----------------------------
 Hello!

 This is in reference to a recent Core update to the
 `WP_Post::get_instance()` method (#63850).

 I'm a plugin author who used negative WP_Post IDs and am unfortunately
 affected by this change. Granted, these are not public plugins but
 customized frontend portal systems for various clients who don't use
 WordPress in a traditional manner. I'd like to explain why I think Faux
 WP_Posts should be supported 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/64362>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform