Add site_id to WP_Post object

[Spidlace]

Hi,

I work on a multisite, where each website can get all posts (from one post type or not).
It seem interesting to add new line in object response (get_post() for example) : "site_id" (where site_id is an int)

• site_id is 1 per default (if no multisite)

WP_Post Object
(
    [ID] =>
    [post_author] =>
    [post_date] => 
    [post_date_gmt] => 
    [post_content] => 
    [post_title] => 
    [post_excerpt] => 
    [post_status] =>
    [comment_status] =>
    [ping_status] => 
    [post_password] => 
    [post_name] =>
    [to_ping] => 
    [pinged] => 
    [post_modified] => 
    [post_modified_gmt] =>
    [post_content_filtered] => 
    [post_parent] => 
    [guid] => 
    [menu_order] =>
    [post_type] =>
    [post_mime_type] => 
    [comment_count] =>
    [filter] =>
    [site_id] =>
)

If this feature is good for some people, I can make this change and submit here

[nerrad]

What is the use-case for adding blog_id to the WP_Post object? How does this proposal solve this use-case requirement in a way that is superior to existing methods in WordPress core?

[johnjamesjacoby]

Hey @Spidlace, thanks for creating this ticket.

My name is John and I’m one of several maintainers of the Multisite component inside of WordPress.

I, for one, think this is a neat idea that could be expanded upon for any non-global object (everything but Users, basically.)

This would be useful for prepopulating the blog ID for an object in a core-approved way that could be expanded or improved at a later date.

As far as implementation details go, this might be a bit harder than it first appears. Posts, for example, have some magic associated with them, where they will look into Post-Meta for non-existent keys (like blog_id in your suggestion.)

It is also highly unlikely that a literal blog_id column would be added to the database for any of the relevant object types, simply due to the low demand and high complexity of the necessary code changes to support this natively.

That means we would be introducing something I’d conceptually refer to as a smart key (or just a key that has a private method associated with it to prime the value for the associated key.)

This key, for example, would probably need to be assigned on __construct() as that’s where switch_to_blog() is guaranteed to be accurate.

One other option is to actually store the value in meta. This is kinda redundant and a bit lazy, but is also super easy.

[johnjamesjacoby]

Maintainers note: blog_id should be site_id and I believe, if implemented, we should support network_id at the same time.

[Spidlace]

Replying to nerrad:

What is the use-case for adding blog_id to the WP_Post object? How does this proposal solve this use-case requirement in a way that is superior to existing methods in WordPress core?

The use-case is when I have 5+ sites on multisite, I want to get posts from site A/site B/site C on site D.
But I only have array of post_id.
I don't know where first post_id come from, where second post_id come from (...).
The only thing to do, is like @johnjamesjacoby say, create meta when we create a post to save current blog_id
But if we can access to blog_id when we make get_post(), it will be more simplified.

Replying to johnjamesjacoby:

Hey @Spidlace, thanks for creating this ticket.
My name is John and I’m one of several maintainers of the Multisite component inside of WordPress.
I, for one, think this is a neat idea that could be expanded upon for any non-global object (everything but Users, basically.)
This would be useful for prepopulating the blog ID for an object in a core-approved way that could be expanded or improved at a later date.
As far as implementation details go, this might be a bit harder than it first appears. Posts, for example, have some magic associated with them, where they will look into Post-Meta for non-existent keys (like blog_id in your suggestion.)
It is also highly unlikely that a literal blog_id column would be added to the database for any of the relevant object types, simply due to the low demand and high complexity of the necessary code changes to support this natively.
That means we would be introducing something I’d conceptually refer to as a smart key (or just a key that has a private method associated with it to prime the value for the associated key.)
This key, for example, would probably need to be assigned on construct() as that’s where switch_to_blog() is guaranteed to be accurate.
One other option is to actually store the value in meta. This is kinda redundant and a bit lazy, but is also super easy.

Hey @johnjamesjacoby, thanks for your response.
I'm totally agree with you. All type of post (post, page, attachment... except user) can have blog_id, for localize witch website is the "owner"
Your second option is like you say, redundant.. If we can add this directely in object, it would be awesome ! (for some people ! :-))

Replying to johnjamesjacoby:

Maintainers note: blog_id should be site_id and I believe, if implemented, we should support network_id at the same time.

Yes ! Good bye keyword "blog" for WordPress !

[giuseppe.mazzapica]

3 years now, let's try to put back some interest in this.

To me it look pretty straightforward:

• Add a new site_id property to WP_Post
• In the class constructor, set the property to get_current_blog_id()

With the property being there, __get() would not be called, so no risk it would look into metadata, and there's no need to involve DB at all.
There's the precedent of $filter property being in WP_Post but not in the DB, and that had never been a problem.

Doing that in "userland" is not possible, because the WP_Post constructor does not trigger any filter (nor does get_post), but for core is literally a 100% backward compatible 2 lines change.

The best way would be a private prop with a getter method, but even a public property (for consistence with the other class properties) would be already better than nothing.

Maybe, just maybe, it could be nice to have a pre-save check to not store the post in DB if the current site ID is different than what stored in the post object. If you think that can never happen, you have never worked with sites that make heavy use of switch_to_blog.

[manfcarlo]

#51373 was marked as a duplicate.

[SergeyBiryukov]

Renaming the ticket per comment:3.