A WordPress network turns plugin management into a single decision. You open Network Admin, press Network Activate once, and every site has the plugin at the same version on the same afternoon. Updates work the same way, from one screen. That suits a caching plugin, and it is a large part of why a university web team runs one network rather than sixty installs.
The FastPix plugin does not accept that activation. It refuses it, and the refusal is a design decision rather than a gap in the build. Each site keeps its own connection, library and capability grants. A shared activation would put sixty sites on one workspace, and one department's unlisted recordings in another department's admin.
That single boundary changes how you install, how you pay and how you grant access. What follows covers activating per site without opening sixty admin screens, and what one credential pair per workspace does to your bill. It then covers how roles land under a Super Admin, and when a network is the wrong shape.
TL;DR
Network activation is refused, not unsupported. A connection is one credential pair pointing at one workspace, and the workspace defines the library, so a shared activation would share the library. Activate per site with wp plugin activate and --url, then connect each site separately. Isolation and a single consolidated bill pull against each other, because usage is recorded per workspace. Roles are per site, though a Super Admin holds every capability everywhere. Multisite fits one organisation with many similar sites, and fits forty independent clients badly.
Why network activation is refused
A network activation writes one activation record and gives every site the same plugin with the same network-level options. That is fine when a plugin holds settings. It stops being fine when a plugin holds a credential pair and a media library.
A FastPix connection is one access token ID and one secret key, stored on the site that owns them. Those credentials point at exactly one workspace, and the workspace decides which videos the Videos screen can list. Share the activation and you share the workspace.
The leak that follows is a real one. On a university network with sixty departmental sites, the music department would open its Videos screen and find the medical school's unlisted lecture recordings there, with delete actions attached. Nobody would have chosen that. It is simply what a shared activation implies.
An agency with forty client sites has the same problem with sharper edges, because the tenants are separate companies. Refusing the activation does not stop you sharing a workspace between sites that genuinely belong to one owner. It stops the network doing it silently, the moment you press a button in Network Admin.
| Question | Network-wide activation | Per-site activation, what the plugin does |
|---|---|---|
| Who owns the credentials | The network | Each site |
| Which library a site sees | One shared workspace | Its own workspace |
| Who can reach the workspace key | Anyone with the network settings screen | A site admin holding fastpix_manage_settings |
| A new site joins | Inherits someone else's library | Starts empty, needs its own connection |
| A site leaves | Its media stays in the shared library | It takes its own library with it |
| Usage and billing | One record for everything | One record per workspace |
Turning it on across sixty sites without opening sixty admins
The plugin files install once, because a network has one wp-content/plugins directory. Only the activation is per site, and WP-CLI does that in a loop rather than sixty browser tabs.
NETWORK=/var/www/university
wp --path="$NETWORK" plugin install fastpix
for URL in $(wp --path="$NETWORK" site list --field=url); do
wp --path="$NETWORK" --url="$URL" plugin activate fastpix
doneLeave the --network flag off plugin activate. With --url and without that flag, WP-CLI activates the plugin for one site inside the network, which is the form the plugin accepts.
Activation runs its own checks on each site, so a loop can fail unevenly. PHP and WordPress versions are shared and pass or fail everywhere at once. HTTPS is per domain, and that is where a subdomain network trips. A wildcard certificate never extended to a new subdomain fails on that one site alone.
Connecting is a separate step from activating. Each site needs its own access token ID and secret key, entered in its own Settings screen or provisioned from the command line. Managing a large WordPress video library from WP-CLI covers the seven wp fastpix subcommands and the provisioning loop.
One workspace per site, and what that does to your bill
Usage is recorded against a workspace, and a site with its own connection has its own workspace. Sixty isolated sites therefore produce sixty usage records, and the finance conversation turns on that.
Isolation and a single consolidated bill pull against each other, and no setting resolves it. Put several sites on one workspace and you get one usage record, plus the shared library the refusal exists to prevent. Keep every site separate and you accept separate records. Pick one.
Which way to go depends on whether the tenants really are separate parties. Sixty departmental sites belong to one university, so grouping a faculty onto one workspace is defensible if those administrators are meant to see each other's video. Forty client sites belong to forty companies, and a shared library there is something you have to explain in writing.
Ask the FastPix team how workspaces map to invoices on your plan before you design around either answer. It is cheaper to ask than to rebuild.
How roles land on a network with a Super Admin
Multisite shares one wp_users table, so a person has one account for the whole network. Roles do not work that way. A role is granted per site, so the same account can be an editor on the history site and hold nothing on the site next door.
Video capabilities ride on those per-site roles, so the grant a person holds on one site says nothing about the next one.
| Capability | Admin | Editor | Author |
|---|---|---|---|
| fastpix_manage_settings | Yes | ||
| fastpix_view_videos | Yes | Yes | Yes |
| fastpix_upload_video | Yes | Yes | Yes |
| fastpix_edit_video | Yes | Yes | |
| fastpix_edit_video_own | Yes | Yes | Yes |
| fastpix_delete_video | Yes | Yes | |
| fastpix_delete_video_own | Yes | Yes | Yes |
| fastpix_view_analytics | Yes | Yes | Yes |
Only an admin reaches the workspace key. A departmental editor uploads lecture video, adds subtitles and reads playback numbers without seeing a credential. Granting video access on sixty sites stops meaning sixty copies of a secret. The roles and capabilities reference lists the full grant table, and WordPress video analytics covers the Analytics screen.
One caveat belongs next to all of this. Super Admin is a network-level grant rather than a site role, and it carries every capability on every site. The boundary the plugin enforces sits between sites and their users. It does not sit between a Super Admin and anything on the network they run.
Driving the network from WP-CLI
Every wp fastpix subcommand takes the same --path and --url pair, so a network loop looks like a fleet loop with URL iteration swapped in for directory iteration.
NETWORK=/var/www/university
for URL in $(wp --path="$NETWORK" site list --field=url); do
echo "== $URL"
wp --path="$NETWORK" --url="$URL" fastpix doctor
wp --path="$NETWORK" --url="$URL" fastpix status
doneRun doctor before status on a network you inherited. doctor re-runs the activation checks and reports environment problems, which on a subdomain network usually means a certificate. status then reports the connection, schema, queue and scheduler for that one site.
Each site needs its own webhook signing secret, because each has its own receiver at /wp-json/fastpix/v1/webhook. Generate the secret inside the loop rather than sharing one value, and set it with wp fastpix webhook-secret. The WP-CLI reference lists the full flag set, and the WP-CLI article covers the scheduler failure that stops a queue draining on a quiet site.
When a Multisite network is the wrong shape
Multisite answers one question well: how does one organisation run many similar sites with shared identity and one update cycle. A university, a newspaper with regional editions, a company with a site per product. On those the network pays for itself.
| Signal | Multisite fits | Separate installs fit better |
|---|---|---|
| Who owns the sites | One organisation | Independent clients |
| User identity | One login across every site | Each site owns its own users |
| Themes and plugins | Largely the same everywhere | Each site wants its own stack |
| PHP and WordPress version | Same for all, upgraded together | One site can stay behind |
| Restoring a single site | Tables are shared, so it is delicate | Restore the install and stop |
| A fatal error in a shared plugin | Can reach the whole network | Contained to one site |
| Handing a site to its owner | An export and a migration project | Hand over the install |
| Video connection | One per site | One per site |
For an agency with forty client sites, most of that table points the other way, and the honest recommendation is separate installs. Clients are separate parties with separate backup obligations, separate offboarding and sometimes a plugin one of them insists on. Multisite gives you one update cycle and charges a shared database for it.
Keep the network when the sites share an owner, an identity system and an update cadence. Break it up when the only thing they share is you. On a network you cannot split, the per-site boundary at least makes the video side behave like separate installs.
Start with one site on the network
Connect a single site before you loop over the whole network. Run the three-step wizard there, upload a couple of videos, then open the Videos screen on a second site and confirm it is empty. That check takes two minutes and settles the isolation question with your own eyes. The WordPress integration docs cover the connection wizard, and the free plan covers 10 videos with no card, enough to test both sites. Once that site behaves, the loop is the same command with a different --url.
Frequently Asked Questions (FAQs)
Can you network activate a video plugin on WordPress Multisite?
Not this one. The FastPix plugin refuses network activation and asks you to activate it per site. A connection is one access token ID and one secret key pointing at one workspace, and the workspace decides which library the site can list. A network-wide activation would put every site on the same workspace, so one site would read and delete another site's media from its own Videos screen.
Do subdomain and subdirectory networks behave differently for video?
For activation and libraries, no. Both types activate per site and keep a separate connection per site. The difference that matters is HTTPS, which activation checks. A subdomain network needs a wildcard certificate or one per subdomain, so a newly added subdomain can fail on its own. A subdirectory network inherits the parent certificate.
Does one bill cover every site on a WordPress Multisite network?
Usage is recorded against a workspace, and an isolated site has its own workspace, so sixty isolated sites produce sixty usage records. Sharing a workspace consolidates the usage and removes the isolation in the same move. No setting gives you both, so ask the FastPix team how workspaces map to invoices before provisioning a network.
How do WordPress Multisite roles work with video capabilities?
Multisite shares one wp_users table, so a person has one account, but roles are granted per site. The same account can be an editor on one site and hold nothing on the next. Only an admin holds fastpix_manage_settings, while editors and authors upload and manage video without reaching the credentials.
Does a Super Admin bypass the per-site video boundary?
Yes. Super Admin is a network-level grant rather than a site role, and it carries every capability on every site. The boundary the plugin enforces is between sites and their users. It is not a boundary between a Super Admin and a site they administer, so plan the Super Admin list accordingly.
When is WordPress Multisite the wrong choice for a set of sites?
Multisite suits one organisation running similar sites with shared identity and one update cycle. It suits independent client sites badly. The database is shared, so restoring one client is delicate. Every site runs the same PHP version, a fatal error in a shared plugin can reach the network, and handing a site back becomes an export.
Does migrating an existing library work the same way on a network?
Yes, per site. Each site scans its own Media Library and moves its own attachments into its own workspace, so a network of sixty runs sixty scans. Moving a WordPress Media Library off your server covers the verification sequence to run first.
