[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