Support for WordPress Multisite WPMU
Before you start
- You have reviewed the installation prerequisites and have installed the WPO365 | LOGIN plugin (see Tutorial - Installation from WordPress.org).
- You are a Global Administrator for your company’s Office 365 tenant / Azure AD directory (or have at least the ability to create (or edit an existing) Azure Active Directory App registrations).
- You are an Administrator for your WordPress website.
Related configurations
- Create a new WPMU blog upon first login read more
- Add all users to all subsites upon login read more
- Redirect users from a central login to their subsite by configuring a mapping table between Azure AD groups on the one and WordPress subsites on the other hand read more.
- Configure a default WP User Role for a new user for a subsite read more.
Choose a WordPress Multisite Mode
Network administrators now must choose one of two possible configurations:
- Shared All subsites in the network share the same Azure AD App registration. When a user successfully signs in with Microsoft, they are always redirected back to the network's main site, though they don't need to be added as a user there. Once the plugin processes Microsoft's authentication response, it will redirect the user to the URL they initially requested, whether it's the main site or one of the WPMU network subsites.
- Dedicated Each subsite in the network operates independently and must be configured separately. While you can use a single Azure AD App registration, you must add each site's URL as a Redirect URI. If a subsite isn't configured, SSO or other functionality will simply not be enabled. Mainly if you’d need to isolate each site in the network for reasons of security, if you need support for mapped domains, or if you wish to configure different role-assignment rules you should choose the dedicated mode.
Please note If you configure shared mode, you must network activate the WPO365 plugin(s). But if you choose dedicated mode, the decision is yours. If all sites need WPO365 features, network activation makes sense. However, if only one or a few sites require WPO365 features, you can activate the plugin just for those specific sites. |
Switching between WPMU mode is very easy. Simply go to My Sites > Network Admin > WPO365 > User Registration, scroll down to the section New User Experience (WordPress Multisite) and operate the toggle, as shown below.
Also note that prior to WPO365 | LOGIN version 35.0, administrators needed to configure the WPMU mode by adding the following line to the site's wp-config.php file.
define( 'WPO_MU_USE_SUBSITE_OPTIONS', true );
Whilst this configuration is still supported, it's now recommend to remove that line and instead operate the toggle on the plugin's User Registration configuration page.
Troubleshoot If you don't see a WPO365 menu entry when you go to My Sites > Network Admin, then please double check that the WPO365 | LOGIN is either network activated or has been activated for at least one of the (sub) sites. |
Creating new users / adding members to a blog
The plugin treats new users / existing users differently, depending on the aforementioned Multisite Mode and additional WPO365 configuration(s). The following table should help to understand the options available to you.
Desired outcome | Necessary configuration |
New user is (not) added to the network's main site. |
Dedicated Mode
|
New user is (not) added to a subsite of the network. | Dedicated Mode
|
Important In shared mode the plugin treats a signed-in user slightly different than a user who is not signed in.
|
Considerations Shared Mode with subdomain installations
When you configure shared mode and set up WordPress Multisite to run on subdomains, each subsite will have a unique URL, such as subsiteA.your-wpmu.site and subsiteB.your-wpmu.site. This is important because WPO365 will authenticate each user in the context of the network's main site, which might be www.your-wpmu.site in this example. Without additional configuration, WPO365 will sign the user into WordPress and set a cookie valid only for the main domain: www.your-wpmu.site. Consequently, a user trying to access subsiteA.your-wpmu.site won't be able to reach the admin dashboard due to the cookie's domain restriction. To resolve this, you may need to add the following line to your site's wp-config.php, just above the line that reads /* That's all, stop editing! Happy publishing. */
define( 'COOKIE_DOMAIN', '.your-wpmu.site' );
Please note that '.your-wpmu.site' is used as an example, and you should replace it with your own URL. The period ('.') before the domain acts as a wildcard, instructing WordPress to set a cookie valid for all subdomains, even though this is generally not required anymore.
Recommended configuration Dedicated Mode
When you configure the dedicated scenario you must configure the WPO365 | LOGIN plugin and its single sign-on separately for a subsite by navigating to each subsite's WP Admin (Dashboard) and then click WPO365 from the main admin menu on the left. However, you can define a default configuration when you navigate to WP Admin > My Sites > Network Admin > WPO365.
Perform the following steps to create a local copy of the default (central) configuration for the current subsite.
- Go to WP Admin > WPO365 > ... > Import / Export for the subsite in question.
- Locate the line Copy central WPO365 configuration (WordPress multisite) and click Copy options. Please note that this is a destructive action and will replace the existing configuration of the subsite in question.
- The Copy options will automatically replace the Redirect URI options in a configuration with the subsite's home URL address. But you must still manually add that URL to list of Redirect URIs on the App registration's Authentication page in Azure AD (also see the comment immediately beneath the table below).
If you set up WordPress Multisite to run on subdomains, you may need to add the following line to your site's wp-config.php, just above the line that reads /* That's all, stop editing! Happy publishing. */ Adding this line may help to ensure that WordPress's authentication cookie is really limited to the one site that the user logged in to.
define( 'COOKIE_DOMAIN', $_SERVER[ 'HTTP_HOST' ] );
Important When you selected dedicated mode and users are allowed to sign in to the site's main page and the URL for that main page is - for example - https://your-wpmu.site/ instead of https://www.your-wpmu.site/, then it may confuse WordPress and users may be able to sign in to subsites that live in subdomains such as https://subsiteA.your-wpmu.site/. In this case, it's recommended to use the "long" version for the URL in question for the main site: https://www.your-wpmu.site/. |
Single sign-on
Troubleshooting
The plugin tries to catch as many exceptions as possible, especially those that cause the user to be trapped in an infinite loop. Still, if users complain about this then consult the corresponding knowledge base article https://docs.wpo365.com/article/5-infinite-loop.