Make WordPress Core

Opened 13 months ago

Last modified 12 months ago

#51373 new enhancement

Include Site ID In WP_Post

Reported by: xedin.unknown Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords: 2nd-opinion
Focuses: multisite Cc:


Right now, it is not possible to, given a WP_Post instance, determine which site on a multi-site network that post came from. This is extremely inconvenient for many cases:

  1. Serialization/deserialization. When a post is de-serialized, it cannot be known what site it came from. Therefore, the data in that instance is completely irrelevant, since a post with the same ID can exist in any site.
  2. Separation of Concerns. When doing something with a post, only the WP_Post instance should be required at most. All basic information, and even a map of custom field names to their values, can be derived from a WP_Post instance; but not its site ID.

So, the site ID is a critical part of the post that is required for actually identifying the post on a network, and is an integral part of what a post _is_. And yet, that crucial data is missing from WP_Post instances.

## Solution
Add a site_id property to WP_Post instances. Any code that is in charge of fetching one or multiple posts from the database can know what site it belongs to by checking get_current_blog_id(). That code can then assign the site_id property. All consumers of WP_Post will then be guaranteed to have that data available, without making WP applications wrap their posts into ad-hoc interfaces etc.

Change History (3)

#1 @johnbillion
13 months ago

  • Focuses multisite added
  • Keywords 2nd-opinion added

This is an interesting idea @xedinunknown , thanks for raising it.

#2 @manfcarlo
12 months ago

I am developing a plugin that handles post objects from foreign sites within a network and I can see this being helpful, but I also think it would be somewhat impotent given the bigger problem that is the widespread use of post ID alone to identify posts.

As an example, get_permalink can take either an ID or a post object.

Currently, if a foreign post object is provided, get_permalink returns an incorrect and broken permalink that mixes the foreign post properties with the local permalink structure and homeurl.

If the site ID were included as a property on the WP_Post class, it would make it possible for get_permalink to return the correct permalink for a foreign post.

What it won't solve is when get_permalink and similar functions are called up with only a post ID. Core and plugins do this pervasively, even in cases where they have direct access to the full post object and are literally extracting the ID from it using $post->ID.

What I encounter a lot with my plugin is to fetch foreign posts from the database using switch_to_blog, only to have core and other plugins discard all of their data other than the post ID.

Example: this method calls up get_post_type using the ID only. Even if the original post object was a product from a foreign site, get_post_type ends up checking the current site and finding the ID is most likely not associated with a product. The post object, however, was withheld by an earlier method, so a site ID property would not be of much help to correct the subsequent output of get_post_type.

Including the site ID on WP_Post is only half of the solution. The second half is ensuring the site ID is routinely able to flow through to widely used functions such as get_permalink, get_post_type and similar.

Note: See TracTickets for help on using tickets.