Why You Don’t See All Plugins on WordPress Multisite Installs: A Comprehensive Guide

WordPress Multisite is a powerful feature that allows you to manage multiple websites from a single WordPress installation. It’s ideal for agencies, universities, franchises, or anyone needing to oversee multiple sites with shared resources. However, one common frustration among Multisite users—especially site admins—is the inability to see all installed plugins. You might upload a plugin, only to find it missing from the “Plugins” menu, or notice that some plugins visible to the network admin don’t appear for site-level admins.

This discrepancy isn’t a bug; it’s a result of WordPress Multisite’s unique architecture, role-based permissions, and intentional design choices. In this guide, we’ll demystify why some plugins vanish, breaking down the technical, structural, and user-based reasons behind this behavior. By the end, you’ll understand how Multisite manages plugins, how to troubleshoot missing plugins, and best practices to ensure plugins are visible (or hidden) as needed.

Table of Contents#

  1. Understanding WordPress Multisite Architecture
  2. Network-Only vs. Site-Level Plugins: The Core Distinction
  3. User Roles and Capabilities: Who Sees What?
  4. Plugin Compatibility: Why Some Plugins Hide Themselves
  5. Network Admin Settings: Restricting Plugin Visibility by Design
  6. MU-Plugins (Must-Use Plugins): The Invisible Workhorses
  7. Caching and Transients: When Plugins “Disappear” Temporarily
  8. File Permissions and Ownership: Technical Blockers to Visibility
  9. Troubleshooting: Step-by-Step to Fix Missing Plugins
  10. Best Practices for Managing Plugins in Multisite
  11. Conclusion
  12. References

1. Understanding WordPress Multisite Architecture#

To grasp why plugins behave differently in Multisite, let’s first recap how Multisite works under the hood.

What Is WordPress Multisite?#

WordPress Multisite (formerly known as WordPress MU) is a feature that transforms a single WordPress installation into a network of multiple sites. Instead of managing separate WordPress instances for each site, you use one core WordPress setup, shared themes, and shared plugins, with each site having its own content, settings, and users (in most cases).

Key Architectural Differences from Single-Site#

  • Shared Core Files: All sites in the network use the same wp-includes and wp-admin directories. There’s no need to update WordPress core separately for each site.
  • Database Structure: Multisite uses a modified database schema. Instead of a single wp_posts table, for example, it uses wp_#_posts (where # is the site ID) for each site, plus global tables like wp_sites (to track sites) and wp_users (to manage network-wide users).
  • Dual Admin Interfaces: There are two types of admin dashboards:
    • Network Admin: Accessible only to “Super Admins,” this dashboard manages network-wide settings, plugins, themes, and user roles.
    • Site Admin: Accessible to site-specific admins, this dashboard manages individual site content, settings, and (in some cases) plugins/themes.

This shared architecture is efficient, but it introduces unique rules for plugin management—rules that directly impact which plugins are visible to whom.

2. Network-Only vs. Site-Level Plugins: The Core Distinction#

In Multisite, plugins are categorized into two primary types: network-activated plugins and site-activated plugins. This distinction is the single biggest reason some plugins don’t appear to all users.

Network-Activated Plugins#

A “network-activated” plugin is installed once and automatically active across all sites in the network. Super Admins control network activation via the Network Admin > Plugins menu.

Key Traits:#

  • Visible to Super Admins Only: Once network-activated, the plugin appears in the Network Admin’s Plugins list but not in individual site admins’ Plugins lists. Site admins can’t deactivate, edit, or delete network-activated plugins—only the Super Admin can.
  • Shared Functionality: All sites in the network use the same version of the plugin with the same core settings (though some plugins allow site-specific configurations).

Example: If you network-activate “Wordfence Security,” every site in the network gets Wordfence protection, and site admins won’t see Wordfence in their site’s Plugins menu—they’ll only see its settings if the plugin allows site-specific configurations.

Site-Activated Plugins#

A “site-activated” plugin is installed at the network level but can be activated/deactivated per site by site admins (if permitted). Super Admins first install the plugin via Network Admin > Plugins, then choose to “Allow site admins to activate this plugin” (or similar, depending on the plugin).

Key Traits:#

  • Visible to Site Admins: Site admins will see these plugins in their site’s Plugins menu (under “Installed Plugins”) and can activate/deactivate them for their specific site.
  • Per-Site Control: Each site can have its own activated/deactivated state for these plugins.

Example: If a Super Admin installs “Yoast SEO” but does not network-activate it, and allows site admins to activate plugins, site admins will see Yoast SEO in their Plugins list and can activate it for their site.

Why This Causes “Missing” Plugins#

If you’re a site admin and don’t see a plugin, it’s often because:

  • The plugin is network-activated (so it’s hidden from your site’s Plugins menu, but still active).
  • The Super Admin hasn’t allowed site admins to activate it (so it’s installed network-wide but hidden from your view).

3. User Roles and Capabilities: Who Sees What?#

WordPress Multisite has strict role-based access control (RBAC) that limits which users can see and manage plugins. Understanding these roles is critical to solving visibility issues.

Super Admin: The Network Overlord#

The Super Admin is the only user with full control over the Multisite network. They can:

  • Install, activate, deactivate, and delete plugins (network-wide).
  • Decide which plugins site admins can see/activate.
  • Manage network settings, themes, users, and sites.

Super Admins access the Network Admin dashboard (e.g., yoursite.com/wp-admin/network/) and see all plugins in both the Network Admin > Plugins menu and individual site Plugins menus (though they rarely need to manage site-level plugins).

Site Admin: Limited Control#

A Site Admin manages a single site in the network. By default, their capabilities are restricted:

  • They cannot install new plugins (only the Super Admin can install plugins network-wide).
  • They cannot activate/deactivate network-activated plugins.
  • They can only activate/deactivate plugins that the Super Admin has explicitly made available for site-level activation.

By default, Site Admins lack the activate_plugins capability (the permission to activate plugins). If the Super Admin grants this capability (via plugins like “User Role Editor” or custom code), Site Admins will see site-activatable plugins.

Other Roles (Editor, Author, Subscriber): No Plugin Access#

Editors, Authors, and Subscribers have no access to the Plugins menu, regardless of network settings. Only Admins (Site or Super) can interact with plugins.

Scenario: Site Admin Can’t See Plugins#

If you’re a Site Admin and don’t see any plugins, the Super Admin likely hasn’t granted you the activate_plugins capability. To fix this, the Super Admin can:

  1. Install a role-management plugin like User Role Editor (network-activated).
  2. Navigate to Network Admin > Users > Edit (for the Site Admin).
  3. Under “Capabilities,” check the activate_plugins box.

4. Plugin Compatibility with Multisite#

Not all WordPress plugins are designed to work with Multisite. In fact, some plugins will intentionally hide themselves or fail to appear if they detect a Multisite environment—often because they’re incompatible.

Why Plugins Fail to Support Multisite#

Multisite’s unique database structure and shared architecture can break plugins that assume a single-site setup. Common issues include:

  • Hardcoded Database Tables: Plugins that use $wpdb->posts (single-site) instead of $wpdb->base_prefix (Multisite) may fail to write to the correct wp_#_posts table for a site.
  • Lack of Network Activation Support: Some plugins don’t include code to handle network activation (e.g., no register_activation_hook for network-wide setup).
  • Per-Site vs. Network-Wide Settings: Plugins that store settings in wp_options (single-site) may conflict if multiple sites try to use them, leading developers to hide the plugin in Multisite.

How Incompatible Plugins Hide Themselves#

Many plugin developers add checks to hide their plugins in Multisite. For example, they may include code like:

if (is_multisite()) {  
    return; // Don't load the plugin in Multisite  
}

This prevents the plugin from appearing in the Plugins menu (or loading at all) to avoid errors.

How to Check Multisite Compatibility#

To avoid invisible plugins due to incompatibility:

  • Check the plugin’s WordPress.org page for “Multisite Compatible” in the “Tags” section.
  • Read the plugin’s documentation for notes on Multisite support.
  • Test the plugin in a staging Multisite environment before deploying to production.

Examples of Multisite-Compatible Plugins: WooCommerce, Yoast SEO, WP Rocket, and Akismet (all explicitly support Multisite).
Examples of Incompatible Plugins: Older or niche plugins (e.g., some custom-coded plugins) may lack Multisite support.

5. Network Admin Settings Restricting Plugin Visibility#

Super Admins can intentionally hide plugins from site admins using built-in Multisite settings. Here’s how:

Hiding Plugins via Network Admin > Settings#

The Super Admin can restrict which plugins site admins see by configuring network settings:

  1. Navigate to Network Admin > Settings > Network Settings.
  2. Scroll to the “Plugins” section.
  3. Check “Allow site administrators to activate plugins” to let site admins see and activate site-level plugins. Unchecking this hides all non-network-activated plugins from site admins.

Disabling Individual Plugins Network-Wide#

If a plugin is installed but deactivated network-wide, it won’t appear in site admins’ Plugins lists (unless the Super Admin has allowed site admins to activate deactivated plugins, which is rare).

To check:

  • Super Admins: Go to Network Admin > Plugins. If a plugin is listed as “Inactive,” site admins won’t see it (unless they have activate_plugins capability and the plugin is allowed).

Using “Plugin Visibility” Plugins#

Super Admins can use specialized plugins to hide specific plugins from site admins. For example:

6. MU-Plugins (Must-Use Plugins): The Invisible Workhorses#

“Must-Use Plugins” (MU-Plugins) are a special category of plugins in WordPress that are automatically active and not visible in the Plugins menu—even to Super Admins. This makes them a common culprit for “missing” plugins.

What Are MU-Plugins?#

MU-Plugins are stored in the wp-content/mu-plugins directory (not the standard wp-content/plugins). They:

  • Activate automatically for all sites in the network (no manual activation needed).
  • Cannot be deactivated via the WordPress dashboard (they must be deleted via FTP/SSH).
  • Do not appear in the Plugins menu (network or site-level).

Why MU-Plugins Are Invisible#

MU-Plugins are designed for critical, network-wide functionality (e.g., security hardening, custom network features). Hiding them prevents accidental deactivation by site admins (or even Super Admins).

Example: A Super Admin might add a custom MU-Plugin to restrict file uploads network-wide. Site admins will never see this plugin in their dashboard, but it will still enforce the upload restrictions.

How to Check for MU-Plugins#

If you suspect an invisible plugin is an MU-Plugin:

  1. Access your server via FTP/SSH.
  2. Navigate to wp-content/mu-plugins.
  3. Look for PHP files or subdirectories here—these are your MU-Plugins.

7. Caching and Transients: When Plugins “Disappear” Temporarily#

Sometimes plugins are installed and configured correctly, but caching or stale transients (temporary database entries) prevent them from appearing in the dashboard.

How Caching Causes Invisibility#

WordPress and third-party caching plugins (e.g., WP Rocket, W3 Total Cache) store copies of dashboard pages to speed up load times. If you recently installed or activated a plugin, the cached version of the Plugins menu may not reflect the change.

Transients: Stale Plugin Lists#

WordPress uses transients (stored in wp_options) to cache lists of plugins, themes, and settings. If the transient for the plugins list isn’t refreshed, the dashboard may show an outdated list (missing new plugins).

Fixing Caching/Transient Issues#

To resolve:

  1. Clear Dashboard Caching: If using a caching plugin, go to its settings and clear the “admin” or “dashboard” cache.
  2. Clear Transients: Install a plugin like Transient Cleaner (network-activated) to delete stale transients.
  3. Force a Refresh: Log out and log back in, or hard-refresh your browser (Ctrl+Shift+R / Cmd+Shift+R).

8. File Permissions and Ownership: Technical Blockers to Visibility#

Incorrect file permissions or ownership on your server can prevent WordPress from detecting plugins, making them invisible in the dashboard.

How Permissions Work#

WordPress needs read access to plugin files to list them in the dashboard. The wp-content/plugins directory and its subdirectories should typically have:

  • Directories: 755 permissions (read/write/execute for owner, read/execute for group/others).
  • Files: 644 permissions (read/write for owner, read for group/others).

What Causes Permission Issues?#

  • Incorrect FTP/SFTP Settings: Uploading plugins with overly restrictive permissions (e.g., 600 for files, which blocks WordPress from reading them).
  • Server Ownership Conflicts: If the server user (e.g., www-data for Apache) doesn’t own the plugin files, WordPress can’t access them.

How to Fix Permissions#

  1. Check Permissions: Use FTP/SSH to inspect permissions. For example, in FileZilla, right-click a plugin file > “File Permissions.”
  2. Recursively Set Permissions:
    • For directories: chmod -R 755 wp-content/plugins/ (via SSH).
    • For files: chmod -R 644 wp-content/plugins/*.php (via SSH).
  3. Fix Ownership: If ownership is the issue, run chown -R www-data:www-data wp-content/plugins/ (replace www-data with your server’s user, e.g., nginx for Nginx).

9. Troubleshooting: Step-by-Step to Fix Missing Plugins#

If you’re still struggling to see a plugin, follow this step-by-step troubleshooting workflow:

Step 1: Confirm Your User Role#

  • If you’re a Site Admin: Ask the Super Admin if the plugin is network-activated or if site admins are allowed to activate plugins.
  • If you’re a Super Admin: Proceed to the next steps.

Step 2: Check the Network Plugins List#

Go to Network Admin > Plugins. Is the plugin listed here?

  • Yes, and it’s network-activated: The plugin is hidden from site admins but active. No action needed unless you want to allow site-level activation.
  • Yes, but it’s deactivated: Activate it network-wide, or allow site admins to activate it (via Network Admin > Settings).
  • No: The plugin isn’t installed network-wide. Install it via Network Admin > Plugins > Add New.

Step 3: Verify Multisite Compatibility#

Check the plugin’s documentation or WordPress.org page for Multisite support. If it’s incompatible, contact the developer or find an alternative plugin.

Step 4: Check for MU-Plugins#

Via FTP/SSH, navigate to wp-content/mu-plugins. If the plugin is here, it’s an MU-Plugin (invisible by design).

Step 5: Clear Caching and Transients#

Clear your caching plugin’s cache and delete transients (using a plugin like Transient Cleaner).

Step 6: Inspect File Permissions#

Check that wp-content/plugins and its subdirectories have correct permissions (755 for dirs, 644 for files).

Step 7: Enable Debugging#

Enable WordPress debugging to check for errors that might be hiding the plugin:

  1. Edit wp-config.php (via FTP/SSH).
  2. Replace define('WP_DEBUG', false); with: 
    define('WP_DEBUG', true);  
define('WP_DEBUG_LOG', true); // Logs errors to wp-content/debug.log  
define('WP_DEBUG_DISPLAY', false); // Hide errors on the frontend
  3. Check wp-content/debug.log for plugin-related errors (e.g., “Plugin file not found”).

10. Best Practices for Managing Plugins in Multisite#

To avoid plugin visibility issues and keep your Multisite network running smoothly, follow these best practices:

1. Network-Activate Only Essentials#

Network-activate plugins that all sites need (e.g., security, analytics). Avoid network-activating niche plugins (e.g., a plugin for a single site’s event calendar)—this clogs the network and hides plugins from site admins unnecessarily.

2. Document Plugin Policies#

Create a shared document for your team that:

  • Lists network-activated plugins (and why they’re network-wide).
  • Specifies which plugins site admins can activate.
  • Notes MU-Plugins and their purpose (for Super Admins).

3. Test Plugins for Multisite Compatibility#

Always test new plugins in a staging Multisite environment before deploying to production. Look for errors in the debug log and ensure the plugin appears in the Plugins menu as expected.

4. Limit Site Admin Capabilities#

By default, don’t grant activate_plugins to site admins unless necessary. This reduces the risk of conflicting plugin setups across sites.

5. Use MU-Plugins Sparingly#

Reserve MU-Plugins for critical, network-wide functionality (e.g., custom user roles, security rules). Overusing MU-Plugins makes troubleshooting harder (since they’re invisible).

11. Conclusion#

WordPress Multisite’s plugin visibility issues are rarely “bugs”—they’re intentional design choices to ensure security, control, and efficiency in a networked environment. Whether a plugin is hidden due to network activation, user role restrictions, incompatibility, or caching, the solution almost always lies in understanding Multisite’s architecture and role-based access.

By following the troubleshooting steps and best practices outlined here, you can ensure plugins are visible to the right users and hidden from others—keeping your network organized, secure, and easy to manage.

12. References#

2025-11