Freshet Upload Max

The 2 MB cap is not a WordPress setting. It is a pair of PHP directives, upload_max_filesize and post_max_size, and the plugin writes them as a small, marker-delimited block to whichever mechanism the host actually reads: a .user.ini in the WordPress root on FastCGI, PHP-FPM and LiteSpeed, or a php_value block in .htaccess on Apache mod_php, and only there, because php_value directives 500 a FastCGI host. The rest of the file is preserved. post_max_size gets 8 MB of headroom so a full-size file plus its form fields fits, and memory_limit is floored for image processing, never lowered. On a handler that reads neither file, you get an admin notice and no change. What it writes, and where, is in the docs.

A plugin can filter the number WordPress displays on the Media screen and call it done. That leaves the server rejecting the file anyway, with a confusing error. This one raises the real PHP directive or tells you it could not. After writing, it reads the directives back with ini_get, immune to other plugins filtering the displayed limit, and compares them against the target. If the file wrote but the limit never rose, because the host ignores .user.ini or imposes a hard cap, you get an admin notice rather than a mystery at upload time. That check waits out PHP's .user.ini cache window, so the cache is not mistaken for a failure. The measured check is in the docs.

.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 file is touched, the plugin pre-flights the same directives in a throwaway subdirectory: a server that rejects them 500s the probe, not the site. Only then does it write, and it still probes the site with a loopback request afterwards. If that returns a 500 or cannot be confirmed, the previous file is restored exactly and a notice points you at server config. Worst case, the limit is simply unchanged. The pre-flight and rollback are in the docs.

The default is 64 MB. To go higher, in wp-config.php: define( 'FRESHET_UPLOADMAX_MB', 128 );, or set the environment variable FRESHET_UPLOADMAX_MB. The constant wins over the environment variable and both win over the default; the value is clamped to 2048 MB. Some hosts impose their own hard ceiling above which nothing in userland can raise it. Scope is deliberately size-only: time limits for very large files on slow connections, max_input_time and max_execution_time, stay a server-config concern. On multisite the written limit is one network-wide file, so it is activated network-wide by a network administrator; a site admin activating it on one subsite gets a notice instead of a write. Changing the limit is in the docs.

The block is marker-delimited, so deactivation removes exactly what the plugin wrote and nothing else, and the previous limit is back. A .user.ini is deleted if it becomes empty; .htaccess, which WordPress owns, is only stripped of the block. Deleting the plugin also removes its own options, including the record of a block that deactivation could not clear. File writes go through the WordPress filesystem API where the host allows it, falling back to a direct write otherwise, so it never asks for FTP credentials to raise an upload limit. There are no tables, no settings and no dashboard to clean up after.

PHP's limit is not the only one in the chain. A web server or proxy in front of PHP, such as nginx's client_max_body_size or 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. The tell is the Media screen showing the new limit while uploads over a certain size still fail, often with a 413. Raise the cap in that layer too. One more edge: with WordPress in its own subdirectory, front-end upload forms posted to a page URL will not see the raised limit; the Media library and everything in wp-admin will. The limits no plugin can raise are in the docs.