[wp-trac] [WordPress Trac] #32450: WP_Site class
WordPress Trac
noreply at wordpress.org
Wed Jan 20 23:37:44 UTC 2016
#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
More information about the wp-trac
mailing list