[wp-trac] [WordPress Trac] #46641: Add blog_id to post object

[WordPress Trac]

#46641: Add blog_id to post object
--------------------------------+------------------------------
 Reporter:  Spidlace            |       Owner:  (none)
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  Networks and Sites  |     Version:  5.1
 Severity:  normal              |  Resolution:
 Keywords:                      |     Focuses:  multisite
--------------------------------+------------------------------

Comment (by Spidlace):

 Replying to [comment:1 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 [comment:2 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 [comment:3 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 !

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/46641#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform