Network Settings

Previously on the CogitActive Saga:
After completing these steps, I logged in again using the link provided. I was now the Network Super Admin.

Once you have created a Multisite Network, you become the Network Admin (aka Super Admin). As such, you can manage the overall settings for your network.

Because network settings are pulled from [the] original site’s options¹, the first thing to do – immediately after creating a Multisite Network – is to configure the Network Settings; hence the timing of this post.

In spite of this, I configured the settings of my Multisite installation belatedly. There are two reasons behind this deferment that I will explain in this post…

A very quick tour

… but let me start with a quick tour of the Network Admin screen. Since it differs from the regular Administration screen, a quick description may indeed be suitable.

Even if you’re familiar with WordPress, the location and behavior of Multisite Network Administration can be confusing.The WordPress codex

The visit starts with the My Sites link on the top-left corner of the admin bar. Using this drop-down menu, you can access the Network Admin link and reach the dashboard.

While the latter looks similar to a regular site dashboard, you will notice two differences: one additional widget – Right Now – and the site specific widgets removed¹. The new widget gives a real-time count of how many sites and users you have in your network, as well as links and search boxes. While this widget may prove useful when you have a community of users and sites within your network, it will not be particularly valuable for my small personal/private network (see Multiple installations vs WordPress Multisite?).

Other than the actual dashboard (Dashboard > Home), there are two additional screens under the Dashboard menu: Updates and Upgrade Network. Moving down the navigation menu (on the left side of the Network Admin), the other menus are Sites, Users, Themes, Plugins and Settings. I will come back to each item in due time (i.e. I will cover each functionality separately in future posts). For now, let me jump directly to the last menu.

Settings

This is where you can access the Network Settings: Settings > Network Settings. From there, you can – as the Super Admin – [set] and [change] settings for the network as a whole¹. This screen contains several sections (see below). Regrettably, the WordPress codex³ doesn’t offer much explanation to help you configure your network.

Operational Settings

Admittedly, this section does not require a manual. Besides, the two fields – Network Title and Network Admin Email – are pre-filled with the information you provided during the Multisite creation. Still, it is good to know that you can change these two items at any time.

Registration Settings

The first thing to do
. . . is to configure the Network Settings.

Here you set how you want to handle registration on your network. The Allow new registrations is without a doubt the most important setting in your network setup. Clearly, it is the reason behind the statement in the introduction of this post (see right). Let me explain why it is so and why I didn’t care (i.e. reason #1 of my deferment).

There are four self-explanatory options to choose from:

• Registration is disabled
• User accounts may be registered
• Logged in users may register new sites
• Both sites and user accounts can be registered

By default, registration is disabled, meaning that the Super Admin must create all users and sites. Given that I didn’t intend to use the Multisite feature to allow outside users to create new sites on demand (see Multiple installations vs WordPress Multisite?) and that I didn’t plan to let them register an account either, I didn’t have to change the default settings. The typical use case for Multisite being to develop a full-blown network, it makes sense that the first thing to do (in that scenario) is to release the kraken open your network to registrations.

---

While this explains why I did not rush to the Network Settings immediately after enabling Multisite, it is not enough to justify my determent. What was bothering me?

If registration is disabled, please set NOBLOGREDIRECT in wp-config.php to a URL you will redirect visitors to if they visit a non-existent site.

These instructions are displayed just below the last option of Allow new registrations – if and only if you have a subdomains installation⁴. What does this mean and what is NOBLOGREDIRECT?

Disappointingly, the codex – that I normally praise to the skies – falls short of clarification on that matter. I could find only two mentions of NOBLOGREDIRECT. The first instance is related to a function – maybe_redirect_404() – and the second is in an article about editing wp-config.php:

NOBLOGREDIRECT can be used to redirect the browser if the visitor tries to access a nonexistent subdomain or a subfolder.

I could not find much in books either; therefore, I searched Google for more information. First, what is NOBLOGREDIRECT? In Hypertext Prepocessor (PHP), the server scripting language used by WordPress, NOBLOGREDIRECT is a constant.

A Constant is an identifier (name) for a simple value. As the name suggests, that value cannot change during the execution of the script. A constant is case sensitive by default. By convention, constant identifiers are always uppercase. The PHP Group

Indeed, constants are used for storing data that will not change while the script is running; configuration settings being a good example of such data.

If setting NOBLOGREDIRECT makes WordPress redirect to the defined URL if registration is closed or a site doesn’t exist, what happen if you don’t set it? In theory, when entering a URL with a subdomain that doesn’t exist (e.g. https://wrong.example.com), WordPress redirects to a signup page (e.g. https://example.com/wp-signup.php?new=example.com). On the other hand, when entering a URL with a page that doesn’t exist (e.g. https://www.example.com/non-existing-page), WordPress redirects to the theme-specific 404 page:

OOPS! THAT PAGE CAN’T BE FOUND.
It looks like nothing was found at this location. Maybe try a search?

This bug is not the only problem encountered with NOBLOGREDIRECT. While seeking for information into tickets and forums, I also discovered many incriminating reports – redirect loop errors, in particular. Not very reassuring, hence my determent!

In keeping with my detective of the past hat, I noticed that NOBLOGREDIRECT is not always the problem, but sometimes the solution. The typical scenario involved websites with www in their domain URL (e.g. https://www.example.com). When people try to access such sites without entering the www – just typing example.com in their browser – they are redirected to the signup page. Obviously, the solution is to set https://www.example.com in NOBLOGREDIRECT.

Perhaps, these people didn’t read in full Before You Create A Network where it is specified that it’s not recommended to use www in your domain URL – I did (see To www or not to www?) and I am not troubled by this issue.

However, something else was bothering me. Trying to access my own signup page redirected to my main site with a blank page, apart from a plain message:

Registration has been disabled.

Not such a big deal as nobody is supposed to enter this URL. Nevertheless, I erroneously⁷ believed that setting NOBLOGREDIRECT would fix this behavior. Therefore, I eventually convinced myself to try to set NOBLOGREDIRECT.

To make a long story short, I did not suffer any “redirect loop” error or any particular incident. As expected, I experienced the 404 bug – main site only, this blog not being affected – and, of course, this was not solving my “Registration has been disabled” ugly page. However, I didn’t anticipate something else.

To sum up, the purpose of NOBLOGREDIRECT is to define a URL to which you wish to redirect people attempting to access a non-existing subdomain. You should implement this if registration is disabled (i.e. to avoid the signup page) and if the Multisite installation is domain-based. However, when NOBLOGREDIRECT is set, the 404 pages on the main site will not work anymore; a bug that remains to be fixed⁸.

Given my configuration (i.e. no wildcard subdomain), I didn’t face the signup page issue that NOBLOGREDIRECT is supposed to handle⁹. Putting asides that NOBLOGREDIRECT is not helping with my “Registration has been disabled” page, nothing impelled me to implement NOBLOGREDIRECT.

After this long-winded digression, it’s time to return to the topic at hand (i.e. Network Settings).

---

As stated earlier, given my choice not to allow any registration, the remaining options of this section were not relevant. Nevertheless, I kept the default settings:

• Registration notification: selected, even though I didn’t open my network to registration. Thus, I – the Super Admin – will receive an e-mail every time that I – the Super Admin – create a user or a site.
• Add New Users: deselected
• Banned Names: www web root admin main invite administrator files
• Limited Email Registrations: none
• Banned Email Domains: none

New Site Settings

This section allows you to populate default messages when a new site (or a new user) is created. The list includes the following items: Welcome Email, Welcome User Email, First Post, First Page, First Comment, First Comment Author, First Comment Email and First Comment URL.

In the same way as for the previous section, given my configuration and my use case of Multisite, it was unnecessary to modify the default templates for the first three items or to create any for the remaining ones.

Upload Settings

These settings are intended to keep other admins in check in terms of what kind of content files they can upload to their sites and how larges those files are.

The first option Site upload space corresponds to the total storage space available per site. It is deselected by default, meaning that users are allowed to use all the space they want for uploads. Again, I didn’t have to select the check box (to limit the available space per site to the amount specified; default: 100 MB).

The next option Upload file types is already filled with an extensive list: jpg jpeg png gif mov avi mpg 3gp 3g2 midi mid pdf doc ppt odt pptx docx pps ppsx xls xlsx key mp3 ogg flac m4a wav mp4 m4v webm ogv flv. Unfortunately, Scalable Vector Graphics (SVG) – an XML-based vector image format – is not listed. Indeed, WordPress doesn’t allow downloading this file format due to security concerns. It is possible to add support for this file type. However, adding svg to the list (separated by spaces) would not be sufficient as explained in the codex note³ on that matter.

Last, you can define the Max upload file size. The default setting (1500 KB), while adequate for uploading images, was not suited for other media (e.g. audio files). Therefore, I adjusted this value up to 128000 KB; the maximum allowed by SiteGround on their shared hosting plans.

Language Settings

I may not be a native English speaker, yet, I set this to English (United States). Anyway, this is a perfect occasion to remind me to ask for your indulgence with my English. Thank you.

Menu Settings

As alluded in a previous post, the control exercised by the site administrators is clipped. Selecting the only Enable administration menus option (i.e. Plugins) would give them access to the plugins menu. Doing so will allow them to activate and deactivate plugins on their individual sites, a privilege normally restricted to the Super Admin (except if the latter enabled access to plugins network wide).

As you may have figured out, I didn’t care (being the Super Admin) and let this option unchecked.

---

That is it. I clicked on the Save Changes button (as I changed ONE default setting) and I was done. Essentially, most of the settings were self-explanatory. The only exception was NOBLOGREDIRECT – definitively a stumper!

To be continued…

---

¹ See Network Admin. ^
² Otherwise, you will have access only to the Administration Screen. Beware the latter will be slightly different compared to the one of a regular WordPress installation. ^
³ See Network Admin Settings Screen. ^
⁴ For a while I wondered why many screenshots of the Network Settings screen didn’t have these instructions. I found the answer deciphering the code for the Multisite network settings administration panel. There is indeed a conditional statement – if ( is_subdomain_install() – just before the printing command for the above instructions. In plain English, this means: if and only if Multisite is a domain-based installation (i.e. not a path-based installation), execute the following command (i.e. display the instructions on the Network Settings screen). ^
⁵ Indeed, the maybe_redirect_404() function has a conditional statement – if ( is_main_site()… – that limits its use to the main site. You can find the code (line 2108) at this address if you want. ^
⁶ Interestingly enough, the issue with the maybe_redirect_404() function is linked to subdomains installations. According to one of the developer involved in the aforementioned ticket, the main purpose of this function was intended for sub-directory installs. Accordingly, the patches were trying to limit its use to subdirectories installation only. ^
⁷ Once again, I reiterate my word of caution: you can’t trust everything you read on the Internet (see the “Evaluation of sources” section of my How to podcast? post). ^
⁸ In fact, when I tried with wordpress.org domain name instead, it worked well: non-existing subdomains redirect to their home page and non-existing pages redirect to the correct “404 Page not found”, suggesting they fixed the NOBLOGREDIRECT bug. ^
⁹ On that matter, it is worth mentioning that in the ms-load.php code, there is a comment (lines 418-420) which goes like this: For a ‘subdomain’ installation, the NOBLOGREDIRECT constant can be used to avoid a redirect to the signup form. Using the ms_site_not_found action is preferred to the constant. Quod erat demonstrandum! ^