[wp-trac] [WordPress Trac] #31985: WP_Network class

[WordPress Trac]

#31985: WP_Network class
--------------------------------+------------------------
 Reporter:  johnjamesjacoby     |       Owner:
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  4.3
Component:  Networks and Sites  |     Version:  3.0
 Severity:  normal              |  Resolution:
 Keywords:  dev-feedback        |     Focuses:  multisite
--------------------------------+------------------------

Comment (by jeremyfelt):

 Replying to [comment:8 johnjamesjacoby]:
 > 2.diff looks fine, but the original patch is farther along than this.
 Was my patch causing tests to fail for you?
 >
 > I understand the unwinding process, so I can appreciate wanting to see
 the meaty middle and present it for others to digest. I think, though,
 that the original patch (despite missing the inevitable `WP_Network_Query`
 class) makes for a better foundation to iterate from since it already
 brings parity to the single-site `wp-settings.php` file, and isolates many
 of the existing multisite gotchas.

 I think I left out half of what I originally wanted to say in my comment.
 :) Definitely digesting and figuring out where things lay. I agree that we
 can do a more comprehensive patch and the original is in a good place.
 Part of this was me trying to understand what belongs elsewhere and what's
 absolutely required here. Part of it was that multisite tests weren't
 passing and I dug from the opposite end.

 A riff directly off the 31985.01.patch,
 [https://core.trac.wordpress.org/attachment/ticket/31985/31985.diff
 31985.diff] makes these changes:

 * Includes `class-wp-network.php` in `ms-settings.php` so that
 `WP_Network` is available.
 * `get_core_options()` was returning the original options rather than the
 rebuilt array.
 * `set_site_name()` had an opposite `empty()` check for site name.
 * Revert the use of `get_active_network_plugins()` and continue handling
 `wp_get_active_network_plugins()` as is. I'm not really understanding why
 this isn't working yet, but the tests for network activated plugins are
 failing and an empty array is coming back every time.

 It's almost terrifying how clean `ms-settings.php` is. :)

 Other thoughts:

 It may be nice if `get_site_option()` (and friends) supported a network ID
 argument. Could that route lead to nicer things rather than maintaining a
 `get_core_options()` method?

 * The network ID is already stored as part of the cache key. See #25883,
 [26304]
 * `site-options` is already a global cache group.
 * `$wpdb->site_id` is only used in the query. This could easily be
 replaced with a network ID if passed.

 Would it be crazy to wrap a `WP_Network()->get_option()`? It would go a
 ways toward solving a naming annoyance.

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