Skip to main content
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.
Options tab with PHP directive sliders and inputs

Select PHP Version → Options

.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

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

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 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 to find the actual slow function.

​
Need a hand?

Open a ticket

Best for anything that needs an account check or a config change on our end.

Live chat

Faster for quick questions during business hours.