Common PHP configuration settings and what they do
Kort antwoord
A handful of PHP settings cause most of the support questions: memory_limit, upload_max_filesize, post_max_size, max_execution_time, and display_errors. They're typically set in php.ini, and on some setups can be overridden per site or per directory.
Where these settings live
PHP reads its configuration from a file called php.ini when it starts. On a typical Linux server there's often more than one copy, for example a separate one for the command-line interface and one for whatever runs PHP for the web server (PHP-FPM or an Apache module), so a change in the wrong file can look like it had no effect. Some hosting setups also allow overriding a subset of these settings per site or per directory, through an .htaccess file, a pool configuration file for PHP-FPM, or settings exposed in a control panel. Which method applies depends on how the server is set up, see Choosing a control panel: cPanel vs. DirectAdmin vs. no panel if a panel is involved. After changing php.ini directly, the web server or PHP-FPM service usually needs a restart before the new value takes effect.
The settings that come up most often
| Setting | What it controls | What happens if it's too low |
|---|---|---|
memory_limit | The maximum amount of memory a single PHP script is allowed to use before PHP kills it. | A script fails partway through with a fatal "Allowed memory size exhausted" error. This is a common cause of a large operation, such as a big file import or an image-processing job, failing partway rather than at the start. |
upload_max_filesize | The largest single file a script can accept through a file upload. | An upload larger than this limit is rejected before the script even gets to process it. |
post_max_size | The largest total size of an entire HTTP POST request, which includes the uploaded file plus any other form fields sent alongside it. | The whole request is rejected, including any files within it, regardless of how upload_max_filesize is set. |
max_execution_time | How long, in seconds, a script is allowed to run before PHP forcibly stops it. | A long-running operation, such as an import, export, or report generation, appears to hang and then fails partway through with no useful output. |
display_errors | Whether PHP prints error messages, including file paths and stack traces, directly onto the page. | Turned on: useful for spotting problems while developing locally. Left on for a public production site: a real information-disclosure risk, since error output can reveal file paths, database details, or other internals to anyone who triggers an error. |
Two settings that need to move together
upload_max_filesize and post_max_size are frequently misunderstood as independent settings, but they work together. post_max_size caps the entire request, not just the file within it, so it needs to be equal to or larger than upload_max_filesize for a raised upload limit to actually take effect. Raising upload_max_filesize to allow a 50 MB file while leaving post_max_size at a smaller value simply means the request gets rejected at the post_max_size stage instead, with an error that can look confusingly unrelated to file size.
A typical pairing in php.ini looks like this:
upload_max_filesize = 64M
post_max_size = 72M
memory_limit = 256M
max_execution_time = 300
Setting post_max_size slightly above upload_max_filesize gives a small amount of headroom for the other form fields sent alongside the file, which is a reasonable default when in doubt.
Production versus development defaults
display_errors deserves particular care because the right setting is different depending on the environment. On a local development machine, seeing the full error output on the page is genuinely useful, it's the fastest way to spot what broke. On a public-facing production site, that same behaviour hands anyone who can trigger an error a look at internal file paths, database queries, or other details that shouldn't be public. The usual production approach is to turn display_errors off and instead log errors to a file (via log_errors and error_log), so the information is still available to whoever is debugging the issue, without being shown to visitors.