[wp-trac] [WordPress Trac] #29684: Add get_main_site_id() function (was: Add get_main_site() function)

WordPress Trac noreply at wordpress.org
Thu Jul 27 16:45:21 UTC 2017


#29684: Add get_main_site_id() function
--------------------------------------+------------------------
 Reporter:  rmccue                    |       Owner:  flixos90
     Type:  enhancement               |      Status:  assigned
 Priority:  normal                    |   Milestone:  4.9
Component:  Networks and Sites        |     Version:  3.9
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  multisite
--------------------------------------+------------------------
Changes (by flixos90):

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


Comment:

 [attachment:29684.5.diff] is a combination of all previous patches and
 follows mostly what we discussed on Monday:

 * It introduces a method `get_main_site_id()` (consistent with
 `get_main_network_id()`) that accepts a `$network_id` parameter.
     * The initial check is based on the multisite constants set, they
 basically overrule everything else. The network passed to the function
 must either have the same domain/path-combination or the same ID so that
 it is identified as ''that'' very network. Maybe we should make this even
 stricter and require it to have the same ID/domain/path-combination, let's
 think about this.
     * If the constants did not find the main site ID, we look at the
 current site and whether it has the same domain/path combination as the
 network. If so, we return that site's ID. This is similar behavior to what
 currently happens at the bottom of `ms_load_current_site_and_network()`.
     * If that wasn't successful either, we do a cache lookup and otherwise
 use `get_sites()` do detect the proper main site. This as well is similar
 to what currently happens at the bottom of
 `ms_load_current_site_and_network()`.
     * A filter `get_main_site_id` is run at the end so that the value can
 be adjusted. Something to think about here: The constant results currently
 do not go through this filter. Should they?
 * The existing `is_main_site()` method now accepts an additional parameter
 for the network ID and simply uses the new `get_main_site_id()` to get its
 result.
 * The bottom of `ms_load_current_site_and_network()` is now simplied since
 it simply needs to call `get_main_site_id()`. This also makes it simpler
 for authors of custom `sunrise.php` files.
 * `WP_Network` now includes a private `get_main_site_id()` method that is
 called by the magic getters for `blog_id`/`site_id` (as a reminder, these
 affect the same value). The method looks at the actual property and if it
 is not set calls `get_main_site_id()`. This enables us to access a valid
 `$network->blog_id` property from anywhere, even for a network that is not
 the "current" network.
 * Unit tests for `get_main_site_id()` and the related `is_main_site()`
 changes have been introduced as well.

 There is one thing I did not do in this patch: I didn't introduce a
 `main_site` network option. Having had a second look, I don't think this
 makes sense. A simple multisite network doesn't need it anyway, and even
 for a multi-network it would be somewhat unreliable since it would only be
 set when calling `get_main_site_id()`. That is because it is impossible to
 set it in `populate_network()` when creating a network since in that
 function the ID of the site that belongs to the network is unknown unless
 multisite is initially set up. More importantly though is the following:
 Our original reason for introducing this was that it would be filterable.
 This is not a valid reason anymore though, since `get_main_site_id()` has
 a filter anyway which can be used for that purpose.

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


More information about the wp-trac mailing list