> ## Documentation Index
> Fetch the complete documentation index at: https://help.noxity.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Options
> Tune core php.ini directives: memory_limit, upload_max_filesize, max_execution_time, and others. Plus when .htaccess overrides this page.
The Options tab is a form for the most-tweaked `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.
**`.htaccess`, `.user.ini`, and per-script `ini_set()` overrides win.** If your application sets a directive any of those ways, the value here is ignored for that request. WordPress installs frequently bundle a `.user.ini` that pins memory\_limit; check there before debugging why your changes aren't taking effect.
## 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](/web-hosting/cpanel/metrics-analytics/errors) tool reads these. |
The other directives in the form are rarely worth tweaking. Defaults are sensible.
## 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. |
If a value here doesn't seem to take effect, search for an override in this order: WP/Laravel/etc. config, `.user.ini`, `.htaccess`, then `ini_set()` in the running script.
## Common issues
`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](/web-hosting/cpanel/metrics-analytics/errors) log mentions memory, this is the fix.
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`: 128M
* `post_max_size`: 256M
* `max_execution_time`: 300 (5 minutes)
If only one of those is too low the upload silently fails. WooCommerce CSV imports and WordPress media-library backups are the cases we see most often.
Almost always `max_input_vars`. Each menu item posts back a few input variables; a large nav can exceed the default 1000. Bump to 3000 or 5000.
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.
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](/web-hosting/cpanel/software/php-xray) to find the actual slow function.
## Need a hand?
Best for anything that needs an account check or a config change on our end.
Faster for quick questions during business hours.