Dion Hulse

<p>On a large multisite network, granting a group of people the same role across many sites usually means adding each user to each site by hand — and remembering to remove them everywhere when they leave. User Teams turns that into:</p>
<ol>
<li>Create a team, pick a role.</li>
<li>Add the user to the team.</li>
<li>They have that role everywhere the team applies.</li>
<li>Remove them from the team <span aria-hidden="true" class="wp-exclude-emoji">→</span> access is gone everywhere.</li>
</ol>
<p>User Teams is multisite-only by design — on a single-site install, native WordPress roles and capabilities already cover the whole feature set, so WordPress won’t offer it for activation there.</p>
<h4>Features</h4>
<ul>
<li><strong>Teams with roles.</strong> Each team carries a WordPress role (editor, administrator, a custom role, or none).</li>
<li><strong>Runtime capability grants.</strong> Team access is added via the <code>user_has_cap</code> filter, so removing a user from a team drops their access on the next request — no stale capabilities usermeta to clean up.</li>
<li><strong>Multisite-native.</strong> Team definitions are real <code>wp_users</code> rows (“team accounts”), so <code>WP_Users_List_Table</code>, <code>is_user_member_of_blog()</code>, and every column-adding plugin “just work”.</li>
<li><strong>Site scoping.</strong> A team can apply network-wide (including sites added later) or to a specific list of sites, each with its own role.</li>
<li><strong>Admin UI.</strong> Network Admin <span aria-hidden="true" class="wp-exclude-emoji">→</span> Users <span aria-hidden="true" class="wp-exclude-emoji">→</span> Teams. Per-user checkboxes on the Edit User screen. Team rows with “— Team” markers on the Users list table.</li>
<li><strong>Cleans up after itself.</strong> Deleting a team removes its memberships. Deleting a user drops their memberships. Deleting a site removes its grants from any team that targeted it.</li>
</ul>
<h4>How access is granted</h4>
<p>Team-derived capabilities are merged in at runtime, never written into the member user’s own meta:</p>
<ul>
<li><code>user_has_cap</code> — adds the team role’s capabilities to the user’s effective caps, plus <code>role-{slug}</code> for plugins that check by role.</li>
<li><code>get_blogs_of_user</code> — adds team-linked sites to the user’s “My Sites” navigation.</li>
<li><code>get_user_metadata</code> — returns an empty-array <code>{prefix}{blog_id}_capabilities</code> for team members so <code>is_user_member_of_blog()</code> returns true without stamping real capabilities on the user. Workaround for <a href="https://core.trac.wordpress.org/ticket/65096" rel="nofollow ugc">Core #65096</a>.</li>
</ul>
<p>The user’s actual <code>{prefix}capabilities</code> usermeta is never modified. That’s what makes team-based access instantly revocable.</p>
<h4>Capability requirements</h4>
<ul>
<li>Managing teams (create / edit / delete) requires <code>manage_network_users</code> — super admin only.</li>
<li>Attaching an existing team to the current site uses <code>promote_users</code>, the same cap as inviting an individual user there.</li>
</ul>
<p>Team management is restricted to super admins so a compromised single-site admin can’t grant themselves access across the network.</p>
<h4>Extension filters</h4>
<ul>
<li><code>user_teams_team_caps_for_user( $caps, $user_id, $blog_id )</code> — modify the capability map computed from a user’s teams.</li>
<li><code>user_teams_team_applies_to_site( $applies, $team_id, $blog_id, $team )</code> — gate coverage (e.g. pause a team during a freeze).</li>
<li><code>user_teams_team_save_data( $data, $team_id_or_null, $op )</code> — filter sanitised input on create/update.</li>
</ul>


User Teams

Unix-style user groups for WordPress multisite. Create a team, give it a role, drop users in — access lights up across the network.

10up

Jeffrey Paul

Oomph, Inc.

Taylor Lovett

Jake Goldman

Siddharth Thevaril

<p>Limit access your site to visitors who are logged in or accessing the site from a set of specified IP addresses. Send restricted visitors to the log in page, redirect them, or display a message or page. A great solution for Extranets, publicly hosted Intranets, or parallel development / staging sites.</p>
<p>Adds a number of new configuration options to the Reading settings panel as well as the Network Settings panel in multisite. From these panels you can:</p>
<ul>
<li>Enable or disable site restriction</li>
<li>Change the restriction behavior: send to login, redirect, display a message, display a page</li>
<li>Add IP addresses to an unrestricted list, including ranges</li>
<li>Quickly add your current IP to the unrestricted list</li>
<li>Customize the redirect location, including an option to send them to the same requested path and set the HTTP status code for SEO friendliness</li>
<li>Define a simple message to show restricted visitors, or select a page to show them – great for “coming soon” teasers!</li>
</ul>


Restricted Site Access

This plugin serves what it says. I was trying to solve an issue to restrict my site to specific IP addresses. This plugin solves it. Kudos team. 

Super Helpful Tool

Thanks for this. Works 100%, super helpful. 

Nice work

I have activated the plugin as a replacement for a maintenance plugin on a WordPress instance that I use as an extranet. It does exactly what I was looking for. The settings are absolutely sufficient and completely fulfill their purpose.
Great !!!

Great Plugin for Intranet/Extranet

Limit access to visitors who are logged in or allowed by IP addresses. Includes many options for handling blocked visitors.

User Teams vs Restricted Site Access