WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#31702 closed enhancement (fixed)

Add action to handle network not found for multisite

Reported by: rmccue Owned by: jeremyfelt
Milestone: 4.4 Priority: normal
Severity: normal Version:
Component: Networks and Sites Keywords: has-patch
Focuses: multisite Cc:

Description

In a typical WordPress multisite installation, wp-config.php will contain definitions for both DOMAIN_CURRENT_SITE and PATH_CURRENT_SITE. The current network global is then set up based on this, then the site is searched for using get_site_by_path.

If the site isn't found, the ms_site_not_found action is then fired, allowing plugins to handle this and display an appropriate error, or redirect to the signup page.

However! In a subdomain-based multi-network install, the site is searched for first based on the domain. If one is found, the network is set from that site's data; otherwise, the network is searched for independently.

If no network is found, ms_not_installed() is called, with no way to set a "fallback" network and no actions or filters. The net result of this is that for multi-network installations, handling unknown domains (say, showing an information page as part of a domain mapping tool) is impossible. This means that domains have to show the DB error page, when the error is actually that they haven't been mapped to a site yet.

This was referenced in #30003, to which @jeremyfelt responded:

This is still expected behavior, but WordPress needs either DOMAIN_CURRENT_SITE and PATH_CURRENT_SITE to be populated in wp-config.php, $current_site to be populated through sunrise.php, or the $current_site global to be filled in via the lookup process so that it knows what network to redirect to.

...which is great and all, but the issue is that there's no way to handle this error in a custom way similar to the site-not-found error.

There's two ways I can see to handle this:

  1. Add an action after the site lookup process, to allow setting defaults on the globals or doing other actions.
  2. Add a ms_network_not_found action into the if ( empty( $current_site ) ) branch.

No. 2 is the easy choice, and I'd recommend adding it even if no. 1 is added. However, the first would help out during the normal request process as well.

Attachments (3)

31702-opt-1.diff (817 bytes) - added by rmccue 6 years ago.
Option 1: Add lookup hook
31702-opt-2.diff (800 bytes) - added by rmccue 6 years ago.
Option 2: Add network-not-found hook to match site-not-found hook
31702-opt-both.diff (1.2 KB) - added by rmccue 6 years ago.
Options 1 & 2: Both hooks

Download all attachments as: .zip

Change History (9)

@rmccue
6 years ago

Option 1: Add lookup hook

@rmccue
6 years ago

Option 2: Add network-not-found hook to match site-not-found hook

@rmccue
6 years ago

Options 1 & 2: Both hooks

#1 @rmccue
6 years ago

  • Keywords has-patch added

Various patches added.

This ticket was mentioned in Slack in #core-multisite by rmccue. View the logs.


6 years ago

#3 @jeremyfelt
6 years ago

  • Milestone changed from Awaiting Review to Future Release

Let's look at this for 4.3.

#4 @jeremyfelt
5 years ago

  • Keywords needs-testing added
  • Milestone changed from Future Release to 4.4

#5 @jeremyfelt
5 years ago

  • Keywords needs-testing removed

I'm liking option 2 for this. It does match the title of the ticket perfectly. :)

I do think option 1 has a place, but that needs some more thought on another ticket as it provides more access to modifying bootstrap without requiring a sunrise file.

#6 @jeremyfelt
5 years ago

  • Owner set to jeremyfelt
  • Resolution set to fixed
  • Status changed from new to closed

In 33990:

Multisite: Add action to handle network not found

ms_network_not_found fires when the global $current_site has not been filled and ms_not_installed() is about to fire. It cannot be used to populate $current_site, but can be used to capture the request and redirect or present a custom error.

Props rmccue.
Fixes #31702.

Note: See TracTickets for help on using tickets.