TL;DR - The Quick Fix
You’re seeing this error because the data you’re sending—usually a large image or video—is bigger than what PHP is configured to accept. To fix it, you need to bump up two specific settings in your php.ini file.
- Locate your
php.inifile (often found in/etc/php/8.x/fpm/or/etc/php/8.x/apache2/). - Set
post_max_size = 64M(or whatever size you need). - Set
upload_max_filesize = 64M. - Restart your web server (e.g.,
sudo systemctl restart php-fpm).
Why this error feels different
The error message mentions "Unknown on line 0" for a specific reason. PHP triggers this warning during the request startup phase, before it even begins executing your script. By the time your code would normally run, PHP has already realized the incoming data is too large. It then wipes the $_POST and $_FILES superglobals to protect itself.
If you see this warning, your script will behave as if the user submitted an empty form. It’s a common frustration when building file uploaders or handling large JSON payloads.
Step-by-Step Fixes
1. Update your php.ini (The Standard Way)
Modifying the main configuration is the most reliable approach. To find the right file, run php --ini in your terminal or check the "Loaded Configuration File" path in a phpinfo(); page.
; Example: Supporting 100MB uploads
upload_max_filesize = 100M
post_max_size = 100M
Pro tip: post_max_size must be greater than or equal to upload_max_filesize. If you are uploading four 20MB files at once, your post_max_size needs to be at least 80MB, even if upload_max_filesize is only 25MB.
2. Apache Workaround (.htaccess)
Shared hosting users often can't touch php.ini. If your host allows overrides, add these lines to your .htaccess file in the root directory:
php_value upload_max_filesize 100M
php_value post_max_size 100M
3. Nginx and the 413 Error
Increasing the PHP limit isn't always enough if you use Nginx as a reverse proxy. Nginx has its own default limit of 1MB. If a request exceeds this, Nginx might block it before PHP even sees it, often throwing a "413 Request Entity Too Large" error.
Open your Nginx site configuration (e.g., /etc/nginx/sites-available/default) and add client_max_body_size to the server block:
server {
client_max_body_size 100M;
...
}
Apply the changes by running sudo nginx -s reload.
Verification: Did it actually work?
Don't trust the config file alone. Verify the live settings by creating a temporary PHP script:
<?php
echo "Upload Limit: " . ini_get('upload_max_filesize') . "<br>";
echo "Post Limit: " . ini_get('post_max_size');
?>
If the numbers don't match your changes, you likely edited the wrong php.ini. Many systems keep separate config files for the CLI (terminal) and the web server (FPM/Apache).
Final Considerations
Keep an eye on your memory_limit. While post_max_size handles the raw data, your script might still crash if it tries to process that data—like resizing a high-res image—entirely in memory. Generally, memory_limit should be higher than post_max_size.
Managing these values across different environments can get messy. If you're storing settings in YAML or JSON files for automated deployments, I recommend using the YAML ↔ JSON Converter on ToolCraft. It’s a simple way to validate your syntax and ensure your deployment scripts don't fail due to a stray tab or bracket.
Lastly, avoid setting these limits to 2GB just to be "safe." High limits leave your server wide open to Denial of Service (DoS) attacks. An attacker could flood your server with massive requests to exhaust disk space or memory. Stick to the smallest value your users actually need.