Opened 10 years ago
Closed 10 years ago
#30294 closed enhancement (fixed)
Introduce get_main_network_id() function
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.3 | Priority: | normal |
Severity: | normal | Version: | 3.7 |
Component: | Networks and Sites | Keywords: | has-patch |
Focuses: | multisite | Cc: |
Description
r25147 introduced the function is_main_network()
for determining if a network ID was the main/primary one. Coupled to this function is the logic for determining what the primary network ID actually is.
It would be helpful for that logic to be extracted into a separate function for determining the primary network ID.
Attachments (2)
Change History (11)
#2
@
10 years ago
Also worth adding a function to get the data for the primary network to avoid two queries (i.e. get primary network ID, then get network data for that ID). We have this in the multinetwork plugin; pretty easy to do.
#3
follow-up:
↓ 4
@
10 years ago
- Milestone changed from Awaiting Review to Future Release
- Type changed from defect (bug) to enhancement
I think this will make sense at some point. I don't think there's anything stopping us from doing it earlier than later. Now?
My only use case so far has only really been for a shaky switch_to_network()
system. I've spent some time thinking of how else it could be used or when it would be likely for a primary network to ever change. It would be interesting to hear some other possible use cases. I guess sunsetting an entire network and firing up a new one could be interesting.
I do like that having a function available may start to avoid any overuse of the PRIMARY_NETWORK_ID
constant.
One spot in the patch is a bit confusing. A different results is possible in is_main_network()
and get_primary_network_id()
because of this check in the prior:
if ( 1 === $current_network_id ) { return ( $network_id === $current_network_id ); }
I think moving that check to get_primary_network_id()
would make sense.
Also worth adding a function to get the data for the primary network to avoid two queries (i.e. get primary network ID, then get network data for that ID). We have this in the multinetwork plugin; pretty easy to do.
Worth another ticket, though I'd be a little worried at introducing this too early before we really shook out wp_get_network
(s) and what that looks like long term.
#4
in reply to:
↑ 3
@
10 years ago
Replying to jeremyfelt:
My only use case so far has only really been for a shaky
switch_to_network()
system. I've spent some time thinking of how else it could be used or when it would be likely for a primary network to ever change. It would be interesting to hear some other possible use cases. I guess sunsetting an entire network and firing up a new one could be interesting.
For Happytables, we're using networks for each whitelabel instance we have. The main network is our own one, which has different behaviour from the whitelabel platform. We're also loading in things like the super admins from the main network regardless of network settings to simplify the behaviour there.
This ticket was mentioned in Slack in #core-multisite by jjj. View the logs.
10 years ago
#6
@
10 years ago
- Keywords needs-patch added
- Milestone changed from Future Release to 4.3
We should do get_main_network_id()
instead and deprecate PRIMARY_NETWORK_ID
in favor of MAIN_NETWORK_ID
due to unfortunate naming in the past.
#7
@
10 years ago
- Keywords has-patch added; needs-patch removed
30294.diff uses "main" instead of "primary". Official deprecation of the constant would still be required.
It also moves the if ( 1 === $current_network_id )
check to get_main_network_id()
and adds some basic filter docs.
get_primary_network_id() example