[wp-trac] [WordPress Trac] #36717: Allow to access network and site properties using the current naming conventions

[WordPress Trac]

#36717: Allow to access network and site properties using the current naming
conventions
-------------------------------------+------------------------
 Reporter:  flixos90                 |       Owner:  flixos90
     Type:  enhancement              |      Status:  reopened
 Priority:  normal                   |   Milestone:  4.6
Component:  Networks and Sites       |     Version:  4.5
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  multisite
-------------------------------------+------------------------

Comment (by flixos90):

 Replying to [comment:30 jeremyfelt]:
 > Some thoughts after pondering and discussing the cache conundrum over
 the last couple days...
 >
 > * It seems the right approach for 4.6 is to make `blog_id` and `site_id`
 public again. Cached public properties via `get_blog_details()` is one
 scenario, and we can probably do a bunch of work to get around that, but
 it seems possible that others have serialized versions of `WP_Site` that
 would break.

 Okay that may be the best solution for now. We only made these private to
 be able to ensure they are passed a string right? So we wouldn't really
 make something worse. In fact it would just work like before (you can pass
 anything).

 > Separately:
 >
 > * That we're storing `WP_Site` objects in cache is an issue in waiting
 anyway. We should decide if it's worth upgrading (downgrading?) these to
 `stdClass` when storing in cache. If so, that's a new ticket.
 > * It may be that we'll be ready to deprecate `get_blog_details()` in the
 near future or at least stop relying on it. If we treat #36935 as
 something entirely different—maybe with new cache keys—then `get_sites()`
 / `get_site()` could be used instead. Maybe a last modified needs to be
 added to the key to help with future invalidation.

 Where exactly do we store `WP_Site` in cache? Are there other locations
 than `get_blog_details()`? I generally think we should switch to storing
 plain `stdClass` everywhere to prevent issues like the above in the
 future. I agree that new cache keys for the `get_details()` method in
 #36935 would totally make sense as a first step.

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