Safety & limits

A "just works" plugin must never leave a site worse off. Two failure modes are handled explicitly: the write that takes a site down, and the write that silently does nothing. Below that, the limits no plugin can raise.

No persistent 500

.user.ini cannot cause a fatal — a bad directive is logged and ignored. The one 500 vector is a php_value block in .htaccess on a mod_php host where AllowOverride forbids it, and IfModule cannot guard against that.

So before the live .htaccess is touched, the plugin pre-flights the same directives in a throwaway subdirectory. A server that rejects them 500s the probe, not the site, and the live file is never written.

Only when the pre-flight cannot prove it unsafe does the plugin write — and then it still runs a loopback probe against the WordPress directory URL, the directory the block governs. If that returns 500 or above, or cannot be confirmed, the plugin rolls back to the exact previous file and shows an admin notice pointing you at server config. The site stays up; worst case the limit is simply unchanged.

Success is measured, not assumed

After writing, the plugin reads the real directives back with ini_get — immune to other plugins filtering the limit WordPress displays — and compares them against the target. If the file wrote but the limit never rose (the host ignores .user.ini, or imposes a hard cap), you get an admin notice.

That check waits out a grace window matching PHP's .user.ini cache (user_ini.cache_ttl, about 5 minutes on a stock install), so the cache is not mistaken for a failure. A renamed user_ini.filename is honoured; a disabled (empty) one reports as unsupported instead of pretending.

It says the limit is still 2 MB

.user.ini changes can take up to 5 minutes to apply. If it never updates, your WordPress root may not be writable, or your host may serve PHP through a handler that reads neither .user.ini nor .htaccess — you get an admin notice in that case.

The limit went up, but large uploads still fail

PHP's limit is not the only one in the chain. A web server or proxy in front of PHP — nginx's client_max_body_size, a CDN or load balancer body cap — rejects big requests before PHP ever sees them, and no plugin can raise or even detect those from inside PHP. If the Media screen shows the new limit but uploads over a certain size still fail (often with a 413), raise the cap in that layer too.

Going higher than 64 MB

Set FRESHET_UPLOADMAX_MB to any value up to 2048 (2 GB) — see Getting started. Some hosts impose their own hard ceiling above which nothing in userland can raise it.

Multisite

The written limit is one shared, network-wide setting — a single file in the WordPress root — so it is network-admin territory: activate the plugin network-wide as a network administrator. A site admin activating it on one subsite gets a notice instead of a write, and deactivation cleanup needs a network administrator for the same reason. The network's own Max upload file size setting (Network Settings) also caps uploads, independently of PHP.

WordPress in its own subdirectory

Supported for the Media library and everything in wp-admin, which is where WordPress uploads happen. One edge: front-end upload forms — page-builder or form-plugin uploads posted to a page URL — execute from the parent directory in that layout and will not see the raised limit.

Time limits

Not changed. The plugin only touches size (upload_max_filesize, post_max_size) plus the memory_limit floor for image processing. Very large files on slow connections may also need max_input_time / max_execution_time raised in server config.