[wp-trac] [WordPress Trac] #32450: WP_Site class

[WordPress Trac]

#32450: WP_Site class
--------------------------------+-------------------------
 Reporter:  jeremyfelt          |       Owner:  jeremyfelt
     Type:  task (blessed)      |      Status:  accepted
 Priority:  normal              |   Milestone:  4.5
Component:  Networks and Sites  |     Version:
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:  multisite
--------------------------------+-------------------------
Changes (by jeremyfelt):

 * keywords:  needs-patch dev-feedback => has-patch
 * status:  assigned => accepted


Comment:

 Another refresh in [attachment:32450.2.diff].

 In the previous patch, I was hoping we could populate the `blogname`,
 `home`, `siteurl`, and `post_count` properties as part of the `WP_Site`
 object. This relies on `get_option()` which in turn relies on `wp-
 includes/formatting.php`—which is not included during the bootstrap
 process—and on setting the `$wpdb` table prefixes. Chicken meet egg. :)

 That's been backed out to focus only on mirroring the database structure
 for the time being. This seems to provide a pretty clear path.

 The latest patch also adds `sites` to our global groups and ensures the
 site's `sites` cache is cleared in `clean_blog_cache()`. (See #29247,
 #35251)

 ----
 Replying to [comment:22 johnjamesjacoby]:
 > Do we want to consolidate the individual status properties immediately
 afterwards? It would be nice to avoid having all of those separate object
 variables if we plan to collapse them in a future release.

 Definitely open to this. Am I imagining it correctly as `$wp_site->status`
 with `$wp_site->spam` still accessible (via `_get()`)? Are there any
 downsides to consolidating those?

 Replying to [comment:23 johnjamesjacoby]:
 > The `blog-details` & `blog-lookup` cache keys contain the same data,
 which is essentially the details of a blog look-up (imagine that.) I'm not
 confident how to best combine these into 1 canonical place, since sites
 are queried both by site ID and by domain & path, but I think it'd be nice
 to have a single bucket for sites rather than 2.

 It would be nice to pre-populate these on object creation if possible. We
 might be able to rework `get_blog_details()` a bit, especially as
 `WP_Site_Query` starts to be more obvious.

 Replying to [comment:24 johnjamesjacoby]:
 > There is also the `is_blog_installed` cache key that we might be able to
 tack onto this. A site should know if it's installed correctly, especially
 if that's a thing whole WordPress installations need to be cognizant of.

 This one looks a little harder since it deals with the options tables.
 Worth exploring in another ticket once we have `WP_Site` in?

 -------------

 @toscho and I also had a [https://wordpress.slack.com/archives/core-
 multisite/p1453237754000543 discussion yesterday in Slack] around
 public/private properties. After poking around some more, I'm still
 inclined to leave them as `public`.

 The `$current_blog` object has been around and stompable for years. We've
 also provided a `blog_details` filter since pre-merge that allows a site's
 object to be directly filtered. It's tempting to protect the properties,
 but I'd rather error on the side of back-compat here.

 I can see adding getters/setters to help ensure the quality of the data.

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