php.ini has hundreds of directives. In practice you only ever change about ten of them. This guide covers those — what each does, the symptom that tells you it needs raising, and reasonable target values. All values can be set via cPanel’s MultiPHP INI Editor (Basic Mode for the common ones, Editor Mode for the others). INI Editor guide.
memory_limit
What: Maximum memory a single PHP script can use.
Symptom of too low: Fatal error in logs: “Allowed memory size of X bytes exhausted”. White screens on admin pages or imports.
Recommended values:
- 128M — minimum for basic WordPress.
- 256M — recommended for WordPress with several plugins.
- 512M — WordPress + WooCommerce, or heavy admin pages.
- 1024M (1G) — only if specific operations need it. Don’t set this as a default.
Raising memory_limit has no downside as long as your plan has enough actual memory available. Don’t compete with yourself by setting 1G if your server only has 2G total and you run dozens of concurrent scripts.
upload_max_filesize
What: Maximum size of a single uploaded file.
Symptom of too low: Media library rejects files. “File exceeds maximum upload size” errors.
Recommended: 64M for most sites. 128M if you handle videos, large PDFs, design files.
post_max_size
What: Maximum size of the entire POST body (form data + uploaded files combined).
Rule: Must be ≥ upload_max_filesize. PHP’s limit on uploads is whichever is smaller, so a 64M upload_max_filesize with 8M post_max_size means real upload limit is 8M.
Recommended: Set 8M higher than upload_max_filesize. If upload is 64M, set post_max_size to 72M.
max_execution_time
What: Maximum seconds a PHP script can run before PHP kills it.
Symptom of too low: “Maximum execution time exceeded” in logs. Long imports time out. WooCommerce bulk operations fail.
Recommended:
- 30 — default, fine for normal page loads.
- 120-300 — for sites doing imports, reports, longer operations.
- 0 — unlimited; only on CLI scripts, never web requests.
If you’re hitting this regularly, consider whether the operation should be cron-based instead of synchronous. Three-minute page loads are a poor UX.
max_input_vars
What: Maximum number of form fields PHP processes per request.
Symptom of too low: Form fields silently dropped on save (settings pages don’t save changes). Especially common in WordPress admin pages with many fields, WooCommerce settings, Gravity Forms with conditional logic, etc.
Recommended: 5000 covers nearly everything. Default 1000 is too low for serious WordPress / WooCommerce sites.
max_input_time
What: Maximum seconds PHP spends parsing input data (separate from script execution time).
Symptom of too low: Very large form uploads or imports time out before processing starts.
Recommended: 60 default works for most. 300 for bulk import scenarios.
allow_url_fopen
What: Whether PHP’s file functions (fopen, file_get_contents) can open URLs as if they were local files.
Recommended: ON (default). Many plugins use this for legitimate purposes — fetching feeds, calling APIs.
Turning it OFF is a hardening choice that breaks many normal plugins. Most sites should leave it on. cURL is the more controllable alternative for code that needs HTTP fetching.
allow_url_include
What: Whether PHP’s include() can load remote URLs.
Recommended: OFF. ALWAYS. Major security risk — enabling lets attackers turn limited file-write vulnerabilities into full remote code execution.
Default is OFF. If anything claims to need this, find a different way.
display_errors
What: Whether PHP shows errors directly in browser output.
Recommended:
- OFF on production. Errors visible in browser leak path information, framework details, version numbers — useful to attackers.
- ON only when actively debugging. Pair with display_startup_errors and error_reporting.
For WordPress sites, use WP_DEBUG_LOG to write errors to a file instead of displaying them. Error logs guide.
disable_functions
What: Comma-separated list of PHP functions disabled entirely. Critical security setting.
Recommended on production:
disable_functions = system,exec,passthru,shell_exec,popen,pcntl_exec,pcntl_forkThese 7 functions enable shell command execution from PHP. Webshells and post-exploitation tools rely on them. Disabling breaks almost nothing legitimate.
DO NOT add proc_open — Composer, Laravel Artisan, Symfony Process, PHPUnit, and WP-CLI all use it legitimately. Full discussion: disable_functions hardening.
session.gc_maxlifetime
What: How long session data persists before being garbage-collected (seconds).
Symptom of too low: Users get logged out unexpectedly. Cart contents lost on long browsing sessions.
Recommended: 1440 (24 minutes) default is too short for most sites. Raise to 7200 (2 hours) or higher for sites where users do extended sessions.
opcache settings (advanced)
OPcache caches compiled PHP bytecode in memory — significant performance boost. Defaults are usually fine. Common adjustments:
- opcache.memory_consumption — Cache size in MB. 128-256M for typical sites. Larger for sites with many files (10k+ PHP files).
- opcache.max_accelerated_files — How many files OPcache can cache. 10000-50000 for big WordPress installs.
- opcache.revalidate_freq — How often (seconds) to check if cached files changed. 60 default; higher = faster but slower to pick up code changes.
Wrong values cause “Cannot load OPcache” or files randomly not loading. Don’t tune unless you have specific reason.
A safe “high performance” defaults bundle
For a WordPress site with a few plugins, these values handle most needs:
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 72M
max_execution_time = 120
max_input_time = 120
max_input_vars = 5000
allow_url_fopen = On
allow_url_include = Off
display_errors = Off
disable_functions = system,exec,passthru,shell_exec,popen,pcntl_exec,pcntl_fork
session.gc_maxlifetime = 7200Apply via MultiPHP INI Editor (Editor Mode for the full list at once, Basic Mode for individual ones). Match the PHP version your domain runs.
Common questions
“I set memory_limit to 512M but WordPress shows 256M.” WordPress’s WP_MEMORY_LIMIT in wp-config.php overrides downward. Update or remove it.
“Big upload limit set but still rejected at 8M.” post_max_size is the actual cap on POST body. Raise it above upload_max_filesize.
“Settings show in phpinfo but plugin still complains about low values.” Plugin may be looking at WordPress-internal limits, not PHP’s. Check theme/plugin config for its own memory or execution limits.
“Can I set values higher to avoid all errors forever?” Tempting but bad practice. memory_limit at 1G hides memory leaks. max_execution_time at 3600 lets bad code lock up resources. Set values that match actual needs plus moderate headroom.
What’s next
- Where to edit these: MultiPHP INI Editor.
- Security hardening with disable_functions: disable_functions guide.
- Per-domain overrides: .htaccess and .user.ini.
The values above cover real-world tuning needs for almost any site. Set sensible baselines once per server, override per-site when needed. Avoid the temptation to set huge numbers “just in case” — moderate values with proper error logging catch problems early instead of masking them.
Was this helpful?
Thanks for your feedback!
