WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 3 years ago

#46641 new enhancement

Add blog_id to post object

Reported by: Spidlace Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.1
Component: Networks and Sites Keywords:
Focuses: multisite Cc:

Description

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) : "blog_id" (where blog_id is an int)

  • blog_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] =>
    [blog_id] =>
)

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

Change History (4)

#1 follow-up: @nerrad
3 years ago

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?

#2 @johnjamesjacoby
3 years ago

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.

#3 @johnjamesjacoby
3 years ago

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

#4 in reply to: ↑ 1 @Spidlace
3 years ago

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 !

Note: See TracTickets for help on using tickets.