Support for Faux WP_Post Objects

[Howdy_McGee]

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.

[iflairwebtechnologies]

Introduce pre_wp_post_get_instance filter to allow short-circuiting WP_Post creation for virtual/faux posts

[iflairwebtechnologies]

Title
Introduce pre_wp_post_get_instance filter to allow short-circuiting WP_Post creation for virtual/faux posts

Description
This patch introduces a new filter, pre_wp_post_get_instance, allowing developers to short-circuit WP_Post::get_instance() and return a virtual or faux post object before any database query is performed.
This restores compatibility with plugins and routing systems that rely on dynamic content not stored in the WordPress posts table.

https://core.trac.wordpress.org/ticket/64362

[Howdy_McGee]

@iflairwebtechnologies Thanks for the patch! I can verify that this works for my usecase. This allows me to supply a Faux WP_Post during wp and consistently return it when WP_Post::get_instanace() is requested.

Would we also want to ensure that the return data is valid WP_Post data? For example, errors if a Boolean is returned since the construct expects an Object or Array.

[westonruter]

@Howdy_McGee I didn't actually provide a patch. I'm unsure if this is the right approach or something core should support. There is a related very old ticket #12955 which is to add a filter for get_post but it has not yet been resolved.

[jorbin]

This feels like a fancy way to get around the fact that WP_Post is final, but ultimately https://core.trac.wordpress.org/ticket/12955#comment:35 feels like the correct path, not a filter here.

Also relevant for this discussion: https://core.trac.wordpress.org/ticket/24672

Either way, I think this is a duplicate of one of those two tickets.

[Howdy_McGee]

@westonruter Whoops!

I'm unsure if this is the right approach or something core should support. There is a related very old ticket #12955 which is to add a filter for get_post but it has not yet been resolved.

I sorta of agree. It is niche, but if we cannot provide a Faux WP_Post, that forces Endpoints to use multiple points of entry (filters) to integrate easily into templates and themes. Endpoints IMO should be a high-level object, so it seems to me that it would be confusing track the multiple hooks a WP_Post may be attached to via themes and plugins. Having a centralized place to provide this information up-front just seems beneficiary.

Otherwise, on Endpoints, WordPress could end up with a global WP_Post Object that isn't necessarily attached to the Endpoint itself which further complicates how WordPress handles Endpoints.

Global objects are already modifiable via the wp hook. Since they're both global and modifiable, I feel like it should stay consistent throughout somehow.

Also, I'm absolutely for making some of the WordPress classes not Final. It may be nice to extend them during custom development.

[iflairwebtechnologies]

Thanks for the feedback. I understand the concerns around scope and assumptions within WP_Post.

I’ll explore whether this can be reframed as a smaller, interface-based proposal or documented best practices for virtual content, rather than altering WP_Post behavior directly.

I appreciate the guidance and links to related tickets.