No description
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> |
||
|---|---|---|
| hifi | ||
| hifi-src | ||
| .gitignore | ||
| DEPLOY.md | ||