php.ini directives: memory limit, upload size, execution time, and a few others. Save the form and the values apply on the next PHP request.
The directives most people change
| Directive | What it controls | Sensible default |
|---|---|---|
memory_limit | Maximum RAM a single PHP request can use. | 256M for WordPress; 512M if you run heavy plugins; 1G for Magento or LMS-style sites. |
upload_max_filesize | Single-file upload cap. | 64M is generous for most sites. Larger only if you accept video uploads. |
post_max_size | Total POST body size, including files. Must be ≥ upload_max_filesize. | At least equal to upload_max_filesize, often 1.5x. |
max_execution_time | Seconds before PHP kills a long-running request. | 30 for a normal site; 300 for a long import; never under 30. |
max_input_vars | Max number of POST/GET variables PHP will parse. | 1000 default; 5000 if you save WordPress menus or large WooCommerce orders. |
max_input_time | Time limit for parsing the request body. | 60 is fine for most cases. |
display_errors | Whether PHP prints errors to the response body. | Off in production (errors go to logs instead). |
log_errors | Whether PHP writes errors to the error log. | On. The Errors tool reads these. |
Save the form
Click Save at the bottom of the page. Changes apply to the next PHP request. There’s no service restart, no cache to clear (PHP-FPM handles it).When this is overridden
| Higher-priority source | What it does |
|---|---|
.htaccess php_value memory_limit 1024M | Per-directory override. Wins for any request under that directory. |
.user.ini in the request’s directory | Per-directory override; same effect as .htaccess. WordPress sometimes ships with one. |
ini_set('memory_limit', '1024M') in the script | Wins for the rest of that request. |
Plugin-specific config (e.g., WordPress WP_MEMORY_LIMIT in wp-config.php) | Overrides on top of all the above for that plugin’s scope. |
.user.ini, .htaccess, then ini_set() in the running script.
Common issues
WordPress shows 'Allowed memory size of 67108864 bytes exhausted' (500 error)
WordPress shows 'Allowed memory size of 67108864 bytes exhausted' (500 error)
memory_limit is too low for WordPress with the plugins you have running. Raise it to 256M in the form, save, and reload. If WordPress still errors, check wp-config.php for define('WP_MEMORY_LIMIT', '64M') and either remove the line or raise it.Reverse: a too-low memory limit is the single most common cause of WordPress 500 errors we see in support tickets. If your WordPress is throwing 500s and the Errors log mentions memory, this is the fix.Large uploads fail mid-way (CSV import, video upload, etc.)
Large uploads fail mid-way (CSV import, video upload, etc.)
Three values usually need to move together:
upload_max_filesize (single file), post_max_size (total POST body), and max_execution_time (the wall-clock limit). For a 100 MB import, set:upload_max_filesize: 128Mpost_max_size: 256Mmax_execution_time: 300 (5 minutes)
WordPress menu save says '413 Request Entity Too Large' or fails silently
WordPress menu save says '413 Request Entity Too Large' or fails silently
Changes don't take effect after Save
Changes don't take effect after Save
Either an override is winning (see “When this is overridden” above), or you’re testing a value PHP reads at startup only and a long-lived process is holding the old value. For HTTP, the next request always picks up the new value. For PHP-CLI cron jobs, the next invocation does. For long-running daemons, you need to restart them.
WooCommerce checkout fails with 'Maximum execution time exceeded'
WooCommerce checkout fails with 'Maximum execution time exceeded'
Either a slow payment gateway is timing out within
max_execution_time, or a heavy cart has too much processing. Bump max_execution_time to 120 first; if it still fails, profile the request with X-Ray to find the actual slow function.