Intranet & Private Site - All-In-One Intranet

Plenty of companies run their intranet on WordPress. The problem is that WordPress was built for public-facing sites. Making it work as a private intranet typically requires installing multiple plugins, configuring each one separately, and hoping they all play nicely together. All-In-One Intranet solves this by giving you everything you need in a single plugin to turn your WordPress site into a fully private intranet. Enable privacy with one checkbox, set up auto-logout to protect sensitive information, configure where users land after login, and manage multisite access controls - all from one settings page. Corporate intranet, private knowledge base, restricted client portal, internal comms hub: the privacy and access control are the same job in each case, and this plugin does that part. What is an Intranet? An intranet is a private website or network used internally by an organization. Unlike a public website, an intranet is only accessible to authorized users - typically employees, contractors, or specific team members. Common uses for a WordPress intranet include:

• Internal company communications and announcements
• Employee handbooks, policies, and procedures
• Knowledge bases and documentation wikis
• Project collaboration and team coordination
• HR portals for onboarding and training materials
• Client portals with restricted access to project files

WordPress already has the editing interface and the user roles for all of these. What it does not have is the access control layer, which is what All-In-One Intranet adds. Features All-In-One Intranet has five features, covering what most intranets need: One-Click Private Site Enable the "Force site to be entirely private" checkbox, and your entire WordPress site becomes restricted to logged-in users only. Anyone who is not logged in gets redirected to the WordPress login page automatically. This single setting handles multiple layers of privacy at once:

• Page and post access - all frontend content requires authentication
• REST API protection - unauthenticated REST API requests are blocked with a 401 error, preventing data leaks through the API
• XML-RPC blocking - XML-RPC is disabled entirely when privacy is active, closing another potential access vector
• Search engine blocking - the robots.txt file is automatically updated to disallow all crawling, keeping your private content out of search indexes
• Pingback suppression - outgoing pingbacks and trackbacks are disabled so your private site does not announce itself to external services
• Feed protection - RSS, Atom, and comment feeds require authentication, so protected posts and comments cannot be read through /feed/ or crafted feed URLs
• Comment and trackback blocking - unauthenticated visitors cannot post comments or trackbacks to protected content through wp-comments-post.php or wp-trackback.php
• Admin endpoint gating - the admin-ajax.php and admin-post.php handlers require a valid login, so public "nopriv" actions registered by your theme or other plugins do not run for logged-out visitors
• Entry-point coverage - WordPress files that load the site outside the normal page render, such as wp-links-opml.php (the blogroll and OPML export) and wp-activate.php, are sealed so they cannot leak post content, feeds, your site title, or the WordPress version number
• Slug enumeration prevention - WordPress's canonical redirect no longer reveals the slugs of private posts to unauthenticated visitors on pretty permalinks
• Role and membership enforcement - the REST API and comment gates apply the same role and sub-site membership checks as the rest of the site, so a logged-in user with no role, or who is not a member of the current sub-site, cannot read API content or post comments they would otherwise be blocked from

The plugin also monitors your WordPress registration settings. If "Anyone can register" is enabled on a single site, or if open registration is allowed on a multisite network, the plugin displays a warning on the settings page so you can fix it before it becomes a problem. Auto-Logout for Inactive Users Shared workstations and forgotten browser tabs are a real security risk for intranets. The auto-logout feature lets you set a maximum idle time - in minutes, hours, or days - after which users are automatically logged out. The plugin tracks each user's last activity timestamp. On every page load, it checks whether the configured idle time has been exceeded. If a user has been inactive for too long, they are logged out immediately and redirected back to the page they were viewing, which triggers the login wall if the site is private. This protects sensitive company information without requiring users to remember to log out manually. Set it to 30 minutes for high-security environments, a few hours for typical office use, or leave it blank to disable the feature entirely. Custom Login Redirect By default, WordPress sends users to the dashboard after they log in. For an intranet, this is not useful - your team is logging in to read content, not to manage the site. The login redirect feature lets you set any URL on your site as the post-login landing page. Point it to your company homepage, a news feed, or a team dashboard so users see relevant content right away. This redirect only applies when users log in directly through the standard WordPress login page. If a user tries to access a specific page and gets redirected to log in first, they will be sent back to that page after authentication, not to the custom redirect URL. Multisite Sub-site Privacy If you run a WordPress multisite network, you can require logged-in users to be members of a specific sub-site before they can view it. This is useful for organizations with multiple departments, teams, or client areas - each with their own sub-site that should only be visible to relevant people. When a user who is logged in but not a member of the current sub-site tries to access it, they see a message listing all the sub-sites they do have access to, with clickable links to navigate there. Access to the Network Admin area is never restricted by this setting. This option works in combination with the main privacy setting. Enable private site first, then add sub-site membership requirements for per-site access control across your network. Multisite Default Role Assignment Managing user access across multiple sub-sites in a WordPress network can be tedious. Every time you add a new user or create a new sub-site, you would need to manually assign roles across all the relevant sites. The default role assignment feature automates this. Choose a role (Subscriber, Editor, Administrator, or any custom role), and the plugin handles the rest:

• When a new user is created, they are automatically added to every active sub-site in the network with the selected role
• When a new sub-site is created, all existing users are automatically added to it with the selected role

That saves a lot of clicking, especially in an organization where new employees and new sites turn up regularly. How to Make Your WordPress Site Private Setting up a private WordPress site with All-In-One Intranet takes about one minute:

1. Install and activate the plugin from the WordPress plugin directory
2. Go to Settings > All-In-One Intranet in your WordPress admin (or Network Admin > Settings > All-In-One Intranet for multisite)
3. Check the box labeled "Force site to be entirely private"
4. Click Save Changes

That is all it takes. Your site is now private. Any visitor who is not logged in will be redirected to the WordPress login page. The REST API, XML-RPC, and search engine indexing are all locked down automatically. If you see a warning about registration settings after enabling privacy, follow the link in the warning to disable open registration and close the gap. How to Set Up Auto-Logout for Inactive Users The auto-logout feature protects your intranet from unattended browser sessions:

1. Go to Settings > All-In-One Intranet
2. Find the Auto Logout section
3. Enter a number in the time field (e.g., 30)
4. Select the time unit from the dropdown: Minutes, Hours, or Days
5. Click Save Changes

Users who are inactive for longer than the configured period will be logged out on their next page interaction. Their activity timer resets on every page load, so active users are never interrupted. To disable auto-logout, clear the time field and save. How to Configure Login Redirect To send users to a specific page after they log in:

1. Go to Settings > All-In-One Intranet
2. Find the Login Redirect section
3. Enter the full URL of your desired landing page (e.g., https://example.com/welcome)
4. Click Save Changes

Users who log in via /wp-login.php will now land on that page instead of the WordPress dashboard. Users who were redirected to the login page from a specific URL will still return to that URL after logging in. How to Set Up a WordPress Multisite Intranet For organizations running a WordPress multisite network:

1. Go to Network Admin > Settings > All-In-One Intranet
2. Enable "Force site to be entirely private" to restrict the entire network to logged-in users
3. Optionally enable "Require logged-in users to be members of a sub-site to view it" for per-site access control
4. Under Sub-site Membership, select a default role to automatically assign users to sub-sites
5. Click Save Changes

The privacy and membership settings apply network-wide. The default role assignment runs automatically when new users or new sub-sites are created. Existing sub-sites and users are not affected retroactively when you change the role setting. Security Features All-In-One Intranet takes a layered approach to access control:

• Authentication enforcement - uses WordPress's built-in auth_redirect() function for reliable login redirection
• REST API lockdown - blocks unauthenticated API requests, preventing data access through endpoints like /wp-json/wp/v2/posts
• XML-RPC disabling - completely disables XML-RPC when privacy is active
• No-role user handling - on single-site installations, users who are logged in but have no assigned role are logged out and shown an error message, preventing access by deactivated accounts
• Registration monitoring - displays admin warnings if WordPress is configured to allow open registration, which would undermine your private site setup
• Nonce verification - all settings forms use WordPress nonce validation to prevent cross-site request forgery
• Capability checks - settings pages require manage_options (single site) or manage_network_options (multisite) capabilities

Note that media uploads (images, PDFs, etc.) remain accessible to anyone who knows their direct URL. This is a limitation of how WordPress stores media files and is common to most privacy plugins. If you need to protect individual file downloads, consider a dedicated file protection plugin alongside All-In-One Intranet. For Developers All-In-One Intranet provides the aioi_allow_public_access filter for developers who need to make specific pages or endpoints accessible without authentication. This filter runs during both the template redirect check and the REST API dispatch check. Return true to allow public access for the current request: add_filter( 'aioi_allow_public_access', function( $allow ) { // Allow public access to a specific page if ( is_page( 'public-landing' ) ) { return true; } return $allow; } ); This is useful for exposing specific landing pages, webhook endpoints, or custom API routes while keeping the rest of the site private. Two more filters exist for login-screen plugins. Two-factor, passkey, and login-interstitial plugins finish their authentication exchange while the visitor is still logged out, so those specific requests must not be sent to the login wall. aioi_public_actions controls which admin-ajax.php / admin-post.php actions may still run while the site is private. The bundled list covers Wordfence, WP 2FA passkeys, miniOrange 2-Factor, Solid Security, AIO Login's passwordless codes, Limit Login Attempts Reloaded's email second factor, and Login With Ajax passkey login: add_filter( 'aioi_public_actions', function( $actions ) { $actions[] = 'my_plugin_login_challenge'; return $actions; } ); aioi_public_rest_routes does the same for plugins that verify the second factor over the REST API instead. An entry matches the request route exactly, or as a path segment prefix of it. The bundled list covers WP 2FA's code verification and Limit Login Attempts Reloaded's code delivery: add_filter( 'aioi_public_rest_routes', function( $routes ) { $routes[] = '/my-plugin/v1/login/verify'; return $routes; } ); Every bundled entry is tied to the plugin it belongs to and only applies while that plugin is active, so a private site never leaves an endpoint open for a plugin it does not run. A renamed build, or a copy loaded as a must-use plugin, is not recognized: add its action or route with the filters above. Only add authentication endpoints to either list. Anything on them can be called by logged-out visitors, so it must not return site content, and it must do its own credential or token check. Be careful with plugins that funnel every one of their endpoints through a single generic action or route - allowing that one name reopens all of them, which is why Shield Security's shield_action router is not on the bundled list even though its 2FA uses it. Google Workspace Integration If your organization uses Google Workspace (formerly Google Apps), two companion plugins extend your intranet:

• Google Apps Login - lets employees sign in to WordPress using their Google Workspace accounts. Domain admins can manage WordPress access entirely from the Google Admin Console, and only authorized employees can access the intranet.
• Google Drive Embedder - allows authors to embed Google Docs, Sheets, Slides, and other Drive files directly into pages and posts. Useful for intranets where documentation lives in Google Drive.

Visit wp-glogin.com for more information about these and other plugins.

Easiest way:

1. Go to your WordPress admin control panel's plugin page
2. Search for 'All-In-One Intranet'
3. Click Install
4. Click Activate in the plugin card
5. Go to 'All-In-One Intranet' under Settings in your WordPress admin area to configure the plugin

If you cannot install from the WordPress plugins directory for any reason, and need to install from ZIP file:

1. Upload all-in-one-intranet directory and contents to the /wp-content/plugins/ directory, or upload the ZIP file directly in the Plugins section of your WordPress admin
2. Go to Plugins page in your WordPress admin
3. Click Activate
4. Go to 'All-In-One Intranet' under Settings in your WordPress admin area to configure the plugin

1.9.2

• Fixed: Nobody could log in to a "Force private" site while a two-factor authentication plugin such as Wordfence was active.
• Fixed: On multisite, creating a sub-site logged a WordPress deprecation notice.
• Fixed: On multisite with a default sub-site role set, the creator of a new sub-site was demoted from administrator to that role.
• Fixed: With auto-logout enabled, users could be logged out again the moment they passed a two-factor check if it took them too long to enter their OTP code.

1.9.1

• Fixed: Fatal error "Call to undefined function getmypid()" on hosts where the PHP getmypid() function is disabled.

1.9.0

• Changed: Compatibility with WordPress 7.0.
• Changed: The "Force private" auth gate now works correctly when WordPress is installed in a subdirectory.
• Changed: On activation the plugin now plants a small must-use companion (wp-content/mu-plugins/aioi-installing-gate.php); deactivation removes it. It closes a /wp-activate.php content-leak surface that the main plugin cannot reach on its own (see Fixed).
• Changed: The post-login redirect URL is now sanitized and normalized when saved: a bare path such as dashboard is stored as /dashboard, while site-relative paths and full http(s) URLs are kept as entered.
• Fixed: Fixed multiple access-control bypasses in "Force private" mode that allowed unauthenticated visitors to read protected posts and feeds via crafted URLs.
• Fixed: Closed a content-leak on "Force private" sites where unauthenticated visitors could read protected posts, feeds, and REST output through /robots.txt by overriding its query string (for example /robots.txt?robots=0&feed=rss2 or ?robots=0&p=N).
• Fixed: Fixed unauthenticated post-slug enumeration via WordPress's canonical redirect on pretty permalinks.
• Fixed: Closed an access-control bypass on "Force private" sites where unauthenticated visitors could post comments and trackbacks to protected posts via wp-comments-post.php and wp-trackback.php.
• Fixed: Closed a content-leak on single-site (and non-network-activated multisite) "Force private" installs where unauthenticated visitors could read RSS feeds and REST API output through /wp-activate.php (for example ?feed=rss2, ?p=N&feed=comments-rss2, or ?rest_route=/wp/v2/posts). WordPress core skips loading regular plugins on wp-activate.php because of WP_INSTALLING, so the gate is now enforced from a must-use companion file.
• Fixed: Closed a content-leak on "Force private" sites where unauthenticated visitors could read the site's blogroll (the OPML links export), title, and WordPress version through /wp-links-opml.php, which loads WordPress without firing the normal page-render auth gate.
• Fixed: Closed an access-control bypass on "Force private" sites where unauthenticated visitors could reach the AJAX and form-handler endpoints (/wp-admin/admin-ajax.php and /wp-admin/admin-post.php). WordPress treats these as admin requests, so the normal page-render auth gate did not apply to them. Any public ("nopriv") action registered by the active theme or another plugin would run for logged-out visitors even though the site is private, potentially exposing data or triggering actions that should require a login. Both endpoints now require a valid login.
• Fixed: On "Force private" sites the REST API and comment/trackback gates now apply the same role and sub-site-membership checks as the rest of the site, so a logged-in user with no role (or who is not a member of the current sub-site) can no longer read REST API content or post comments that they would otherwise be blocked from.
• Fixed: Additional "Force private" hardening: the inactivity auto-logout now bounces through a host-validated safe redirect instead of trusting the Host header, the network settings save now performs an explicit capability check, and the default sub-site member role is validated against the registered roles when saved.
• Fixed: Minor robustness and standards fixes: the private-site robots.txt now includes a User-agent: * line, the plugin's PHP files guard against direct access, and corrected an internationalization issue in a registration warning notice.

1.8.1

• Changed: Compatibility with WordPress 6.9.
• Fixed: Made sure the XMLRPC is also safeguarded against unauthorized access.

1.8.0

• IMPORTANT: The minimum WordPress version is now WordPress 5.5.
• IMPORTANT: The minimum PHP version is now PHP 7.0.
• Added: Multisite-specific options: "Require logged-in users to be members of a sub-site to view it".
• Added: "Sub-site Membership" - assign a user role for newly added users.
• Changed: Compatibility with WordPress 6.6.
• Fixed: Several security-related improvements in various parts of the plugin.
• Fixed: Code style improvements.

1.7.1

• Security update and added WordPress 5.7 compatibility.

1.7

• Security update and added WordPress 5.6 compatibility.

1.6

• Security update and added WordPress 5.4 compatibility.

1.5

• Ready for WP 4.9. Disables unauthenticated calls to WP REST API by default.

1.4

• Now supports localization - please contribute your translations!

1.3

• Changed which WordPress hooks are used to check for auto-logout. This is to widen compatibility with certain Themes.

1.2

• On non-multisite WordPress, now restricts access to users who have no role, as well as those who aren't logged in at all.

1.1

• Ready for public release.