UPDATE: After Our Kinsta Migration
The migration of Questromworld onto Kinsta has changed the way we add users to our intranet.
The implementation of Shibboleth played a role in the way we could add users to their sub-sites.
Because we only have 1 Shibboleth license for the whole intranet, and because the plugin does not support a multi-site environment (yet), we have come up with a redirect (in the backend) affecting the way users can login to their sub-sites, without them even noticing what is going on behind the scenes.
They will login to the main site via Kerberos, then they will be redirected to their sub-site.
Here is the step-by-step guide to add any new user to our intranet:
- In main site, add new user (BU email as username, BU email as email) with role subscriber
- Check skip confirmation email
- In sub site, add new user by adding existing user, with proper role
- Check skip confirmation email
Anything else just works the same way as explained in depth below.
Users Within a Multi-site Environment
Here you will find all the users currently registered within the Network.
WordPress uses a concept of Roles, designed to give the site owner the ability to control what users can and cannot do within the site. A site owner can manage the user access to such tasks as writing and editing posts, creating Pages, creating categories, moderating comments, managing plugins, managing themes, and managing other users, by assigning a specific role to each of the users.
WordPress has six pre-defined roles: Super Admin, Administrator, Editor, Author, Contributor and Subscriber. Each role is allowed to perform a set of tasks called Capabilities. There are many capabilities including “publish_posts“, “moderate_comments“, and “edit_users“. A default set of capabilities is pre-assigned to each role, but other capabilities can be assigned or removed.
The Super Admin role allows a user to perform all possible capabilities. Each of the other roles has a decreasing number of allowed capabilities. For instance, the Subscriber role has just the “read” capability. One particular role should not be considered to be senior to another role. Rather, consider that roles define the user’s responsibilities within the site.
If you want to know more about user roles with WP, you can find exhaustive tutorials here, here, and here.
In our network roles view, we will be shown something like this:
In the example above, you can see aburgio labelled as a “Super Admin”, and then other registered users with no label.
They will be users of specific sub-sites, without super admin capabilities.
You can also see which sub-site each user belongs to.
Navigate to that sub-site, and you will be shown its actual role. For example, navigate to our Root Site Questromworld and you will be shown this Users page.
Super Admin & Other Roles in our intranet
Super administrator (AKA network admin): This Super Administrator role in WordPress is reserved for WordPress multisite networks. Individuals that are assigned as Super Administrator role have full responsibilities for all sites within the network and can manage all site features within each site.
Super Administrators have the power to delete other users (even Administrators), create new websites, manage themes and plugins across the multisite network, add, manage or delete content on every site. The Super Administrator controls the network with all settings and security issues.
The first user setting up the multisite network is the default Super Admin.
Administrator: In a single WordPress installation, the Administrator user role has full access to every feature within the site. The site Administrator role is almost always assigned to the website owner and/or the main developer and has access to all of the WordPress features, settings and options.
The WordPress administrator role has full access to add and edit posts and pages, change or update site settings, add and install plugins, and much more.
In our case, this will be the client, and every action that can be performed will be relevant to the specific sub-site only. So, for instance, the client of the DEI sub-site will be admin for that sub-site, and will be able to activate a plugin for the DEI sub-site, as long as the plugin has been downloaded by the super-admin of the network.
Editor: An Editor can create, delete and edit any site content including content that was produced by other users with permissions equal to or lower than Editor.
Editor users manage all site edits and approve/schedule content submitted by Contributors and Authors. However, an Editor doesn’t have any access to things such as plugins, widgets, WordPress settings, or adding or removing users.
Below a nice overview of roles and capabilities (find link to infographic here).
Keep in mind that the Administrator role will be specific to the sub-site: so “install plugins” means for that specific sub-site only.
