[wp-trac] [WordPress Trac] #36935: Implement lazy-loading blog details in `WP_Site`

WordPress Trac noreply at wordpress.org
Tue May 24 18:14:01 UTC 2016


#36935: Implement lazy-loading blog details in `WP_Site`
-------------------------------------+------------------------------
 Reporter:  flixos90                 |       Owner:
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Networks and Sites       |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------
Changes (by flixos90):

 * keywords:  needs-patch => has-patch needs-testing


Comment:

 [attachment:36935.diff] is an initial patch. I added a magic getter (and
 issetter) to `WP_Site` for the additional properties `blogname`,
 `siteurl`, `post_count` and `home` which were originally dealt with in
 `get_blog_details()`.

 Whenever one of these properties is now requested through a `WP_Site`
 object, a new private method `get_details()` is called which basically
 contains the code from `get_blog_details()`. To be backwards compatible
 with the filter `blog_details` (that is now part of this method as well),
 a raw object copy of the site object is created there. Note that I got rid
 of the `{$blog_id}short` cache key since it is of no use here (and it
 actually contains exactly the same like the `sites` cache key that was
 introduced with `WP_Site`.

 The function `get_blog_details()` now only contains the code to retrieve
 the site object, including taking care of the `blog-lookup` cache key. The
 `$get_all` parameter is not of any use at this point since all site
 objects now automatically lazy-load these additional properties as
 described above. We might wanna deprecate that parameter.

 `get_blog_details()` now isn't of any more use than getting a site object
 by its domain, path or id (for the latter, `get_site()` is the better
 function though). This function should probably make use of
 `WP_Site_Query` now that it is merged in. However I didn't want to include
 this in this first iteration (I'm not sure whether we should do it in this
 ticket at all).

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


More information about the wp-trac mailing list