When a plugin install fails across several WordPress sites, the cause is almost always a size limit on one of two servers: your dashboard’s PHP upload limit, or a firewall on the managed site that refuses large requests (HTTP 413). In Siteward, the fix for the first is raising upload_max_filesize and post_max_size on the dashboard. The second is solved by Siteward Pro 0.11.8 and Siteward Advanced Child 0.7.14: sites now download plugins themselves, from WordPress.org or from your dashboard, so no large request ever reaches their firewall.
Installing one plugin on twenty sites should take one click. When it fails on some of them, the error usually names a symptom rather than the cause, and the cause is rarely the plugin. This guide goes through every message Fleet Plugins can show during an install, what is really behind it, and how to fix it.
Quick reference
| What you see | What it means | Fix |
|---|---|---|
| “This ZIP is larger than your dashboard’s server allows for uploads” (older versions: “ZIP must be between 1 byte and 64MB”) | PHP on the dashboard refused the upload | Raise upload_max_filesize and post_max_size on the dashboard |
| “HTTP 413” or “Request Entity Too Large” on some sites | The site’s firewall refused a large request | Update to Pro 0.11.8 and Advanced Child 0.7.14, or install by name from WordPress.org |
| “too old to install from WordPress.org” | The site runs Advanced Child older than 0.7.14 | Update Siteward Advanced Child on that site |
| “runs Siteward Child, which cannot install plugins” | The site runs the free WordPress.org companion | Switch the site to Siteward Advanced Child |
| “WordPress.org has no plugin with the slug” | The slug is wrong, or the plugin was closed | Copy the slug from the plugin’s WordPress.org address |
| “not activated” with a reason | The plugin installed but refused to start | Read the reason: usually a missing required plugin or an old PHP version |
| “Upload expired. Re-upload the ZIP.” | The uploaded ZIP sat unused for 30 minutes | Upload it again |
“This ZIP is larger than your dashboard’s server allows”
This one happens before any site is involved. PHP on the server that runs your Siteward dashboard has a maximum upload size, and a file over it is discarded before WordPress ever sees it. Many hosts leave PHP’s default of 2MB in place, which is smaller than plenty of popular plugins. A small plugin such as WP Crontrol uploads fine while an 8MB statistics plugin fails, which makes it look like a problem with the plugin when it is not.
Earlier versions of Siteward Pro reported this as “ZIP must be between 1 byte and 64MB”, because PHP reports a refused file as zero bytes. Pro 0.11.7 and later name your server’s actual limit, and check the file size in the browser before uploading.
To fix it, raise two PHP settings on the dashboard’s server. 64M covers almost every plugin:
upload_max_filesize = 64Mpost_max_size = 64M(this must be at least as large as the upload limit)
Most hosting panels have a PHP settings screen for this (cPanel’s MultiPHP INI Editor, CloudPanel’s PHP settings, Plesk’s PHP Settings). Otherwise, ask your host. To see the current values, open Tools → Site Health → Info → Server on the dashboard site. Only the dashboard needs changing: managed sites no longer receive the file as an upload.
HTTP 413 “Request Entity Too Large” on some sites
If the upload succeeds but some sites fail with HTTP 413, the problem is on those sites’ side, in front of WordPress. Before version 0.11.8, Siteward sent each site the whole plugin inside one signed request, around a third larger than the ZIP itself. Web application firewalls such as ModSecurity cap how large an incoming request can be, and many shared hosts set that cap at the network edge where customers cannot change it. 20i’s shared hosting is one example: the limit is fixed for every account and can only be changed on its cloud servers.
Raising PHP limits on the site does not help, because the request is refused before PHP runs.
The fix is to update. With Siteward Pro 0.11.8 on the dashboard and Siteward Advanced Child 0.7.14 on the site, nothing large is sent to the site at all:
- Plugins on WordPress.org can be installed by name. Choose From WordPress.org in the install window and type the plugin’s slug, or paste its WordPress.org link. Each site downloads the plugin from WordPress.org itself.
- Premium and custom plugins are still uploaded to your dashboard once. Each site then downloads the ZIP from your dashboard through a private link that expires, and installs it only if it matches the uploaded file exactly.
A download is a request the site makes, not one it receives, so incoming size limits do not apply to it. Both updates arrive through the normal WordPress update screens.
When a site cannot download from your dashboard
For an uploaded ZIP, each site has to reach your dashboard over the internet. That fails when the dashboard is not publicly reachable: behind HTTP password protection, on a private network, or behind a firewall or bot protection that blocks requests from other servers. Siteward then falls back to sending the ZIP inside the request, as older versions did, so on most hosts the install still works.
If the site also refuses that larger request, the result says both: that the site’s server refused a request this large, and why it could not download the ZIP from the dashboard. To fix it, let your managed sites reach this address on the dashboard: /wp-admin/admin-ajax.php?action=omnis_pro_zip. Each link only works for the one site it was made for, and only while the upload is current. A dashboard that sites must reach at a different public address can set it with the omnis_pro_plugins_pull_url filter.
If the ZIP is too large to send directly with your dashboard’s PHP memory limit, the result says that instead of failing silently. Raising the dashboard’s memory_limit, or fixing the download as above, solves it.
“This site’s Siteward Advanced Child is too old”
Installing by name from WordPress.org needs Siteward Advanced Child 0.7.14 or later on the site. Update it from the site’s Updates screen, or from the dashboard’s Updates page. Uploaded ZIPs still work on older versions, using the old single-request method.
“This site runs Siteward Child, which cannot install plugins”
The free Siteward Child from WordPress.org manages updates and can activate, deactivate and uninstall plugins, but WordPress.org’s rules do not allow it to install them. Sites you want to install to need Siteward Advanced Child, which is also free. Selected sites on the free child are skipped rather than failing, and the install window says how many. How to install a plugin on multiple WordPress sites covers switching a site over safely.
“WordPress.org has no plugin with the slug”
The slug is the last part of the plugin’s WordPress.org address: for wordpress.org/plugins/wp-statistics/ it is wp-statistics. It often differs from the plugin’s display name, so copying the address is the safest way. You can paste the whole address into the box and Siteward picks out the slug. A plugin that has been closed on WordPress.org cannot be installed by name either.
If instead the install window says the dashboard “could not reach WordPress.org”, the dashboard’s server cannot make outgoing requests to WordPress.org. You can still go ahead: each site looks the plugin up for itself and reports if it does not exist.
Installed, but “not activated”
When you tick Activate after install and a plugin installs but does not start, the result line shows a cross with the reason WordPress gave. The usual ones are a plugin that requires another plugin to be active first, or one that needs a newer PHP version than the site runs. Fix the requirement on that site, then activate the plugin from Fleet Plugins.
A plugin that is already installed
Installing from WordPress.org never replaces a plugin that is already on the site, because a premium version can share its folder name with a free listing. Those sites report “already installed”, and the plugin is activated if you asked for that. To replace an existing copy on purpose, for example to push a premium update, upload its ZIP instead: an uploaded ZIP overwrites the existing copy.
“Upload expired” and “Your session has expired”
An uploaded ZIP is kept for 30 minutes after it was last used, then deleted from the dashboard. A long run across many sites keeps it alive, but if you leave the install window and come back later, upload the file again.
If Fleet Plugins says your session has expired, the page has been open long enough for WordPress’s security token to lapse. Reload the page and try again.
Is it safe for sites to download plugins this way?
Every install instruction still travels over the same signed connection as everything else Siteward does: each request is signed with your dashboard’s private key and checked against the public key the site stored when it was paired, with protection against a request being replayed. For a WordPress.org install, the site accepts downloads only from downloads.wordpress.org, using WordPress’s own installer. For an uploaded ZIP, the signed request carries a checksum of the file you uploaded, and the site refuses anything that does not match it exactly, wherever it was downloaded from.
For the full setup, start with how to install a plugin on multiple WordPress sites, or see fleet plugin management for everything Fleet Plugins does.
Common questions
Why does a plugin install fail with HTTP 413 on some of my sites?
HTTP 413 means a firewall in front of the site refused a request because it was too large. Older Siteward versions sent each site the whole plugin inside one request, and hosts such as 20i fix that limit for every shared hosting account. With Siteward Pro 0.11.8 and Siteward Advanced Child 0.7.14, sites download plugins themselves instead, so the limit no longer applies.
How do I fix the dashboard's upload limit for plugin ZIPs?
Raise upload_max_filesize and post_max_size to 64M on the server that runs your Siteward dashboard, either in your hosting panel's PHP settings or by asking your host. You can check the current values under Tools, Site Health, Info, Server on the dashboard site.
Can I install WordPress.org plugins without uploading a ZIP?
Yes. In Fleet Plugins, choose From WordPress.org in the install window and type the plugin's slug or paste its WordPress.org link. Each site downloads the plugin from WordPress.org itself. It needs Siteward Pro 0.11.8 and Siteward Advanced Child 0.7.14 or later.
Do I need to change PHP settings on every managed site?
No. Only the dashboard receives your upload. Managed sites download the plugin, from WordPress.org or from your dashboard, so their upload and request limits do not matter.
Why does a WordPress.org install say the plugin is already installed?
Installing by name never replaces a plugin that is already on the site, because a premium version can share its folder name with a free listing. The plugin is activated if you asked. To replace an existing copy on purpose, upload its ZIP instead.
See it on your own sites.
Monitor unlimited sites free, or add Pro when you want expiry alerts, dynamic tags and integrations.