Project: Network Login Plugin for WordPress Multisite

Introduction and Business Problem

WordPress Multisite is a great way to run a set of sites, without having to deal with the hassles of upgrading and managing multiple installations of WordPress. But it works best if the sites are somehow related to each other — for example, maybe all the sites belong to the same company. The primary reason for this limitation is that the users in the database are assumed to be the same users across all the sites. So a user who is already registered on site #1 is expected to know their password from site #1 if they want to register on site #2.

This means that if a operator wanted to run a set of sites on Multisite where the users were not related to each other, then they run the risk of a user getting confused when they went to register on site #2. The user would be puzzled as to how their name/email address is associated with a site that they never registered on. If the user decided to do a password reset so that they could login to site #2, they would have no way of knowing that the reset also applied to site #1, since the operator would probably not want the user to know that the sites are related.

If the sites being run are generally unrelated, then the chances of this situation occurring is low. But the chances rise dramatically if all the sites are in the same industry.

Engineering Challenge

The challenge was to find a way around this problem while not creating an impediment to the registration workflow. The original idea was to hack the WordPress core code, but that was quickly thrown out, since it would be a maintenance nightmare. Quite a few other ideas were considered and thrown out as well. It turned out to be a lot more of an engineering puzzle than was originally envisioned.

The Proposed Solution

Ultimately, we realized that the only time this would be an issue would be when the user tried to register. So we decided to build a plugin that would intercept any pages which would cause a registration process to be initiated. However, to make things simple, it would be up to the administrator to tell the plugin which pages to “intercept” — i.e., which pages would cause a registration event.

When a page where a registration event would occur was intercepted, the plugin would take over and change the registration workflow. The new registration workflow would be as follows:

1. Ask for the user’s email address only.
2. Check if the user’s email address already exist in the multisite.
   1. If it exists in the multisite database, but not on the current site the user is trying to register on, send an email with a PIN to the email address, and ask the user to confirm the PIN.
   2. If it exists in the current site the user is trying to register on, ask for the password.  Also, send a PIN just in case they do not know their password.
   3. If it does not exist, go through the regular registration process.

At the end of any of the three processes, the user is automatically logged in. The PIN process prevents someone who doesn’t control the email address from registering the address on a site. Plus, it prevents the user from having to remember a password. The downside is that every login will most likely require the user to enter the PIN, since they may or may not know their password.

Wrap Up

This solution took three months to engineer, build and test. Some examples of pages that could be intercepted are:

• WooCommerce Check-out Pages
• WP-LOGIN pages
• Custom Registration Pages
• Plugin-Specific registration pages such as the AwesomeSupport Plugin

In our experience, large sites that use this plugin will have two or three different registration methods or plugins, whose registration pages need to be intercepted for the new workflow.