Root cause: the export embeds the whole gallery as base64 directly in the
JSON (that's how it stays a single self-contained file), which pushes a
realistic export well past 40MB. PHP's post_max_size/upload_max_filesize
default to values well under that on most hosting, so the browser's
upload got silently discarded before the app ever saw it - PHP clears
$_FILES and $_POST once post_max_size is exceeded, and the leftover raw
body in php://input is unparsed multipart data, not JSON, so it fell
into a generic "invalid file" 422 with no indication of what actually
went wrong. Reproduced locally with a real ~43MB export against the
previous 40M limit.
Raises the limits to 200M via two paths, since we don't know which PHP
SAPI the various hosting targets (All-Inkl, the Plesk test server) use:
hifi/.htaccess sets php_value overrides for classic Apache module PHP,
guarded by <IfModule> checks for several common module names so hosts
running PHP-FPM/CGI (which ignore php_value and would otherwise choke on
an unrecognized directive) skip the block instead of 500ing the entire
site; hifi/api/public/.user.ini covers exactly that FPM/CGI case, which
mod_php hosts in turn simply don't read.
Also makes SettingsController::importData() detect an oversized upload
by comparing Content-Length against the configured post_max_size, and
report the actual limit instead of the generic corrupt-file message -
so if some host's real limit is still too low, the admin sees why
instead of a dead end.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
a9aea99028