If you've ever chased down a WordPress upload error, then a memory exhausted error a week later, then a plugin timeout after that — and fixed each one in a different place — there's a faster way. cPanel's MultiPHP INI Editor puts the PHP settings that actually cause these problems on one screen, per domain, with no file editing required.
Here's how to use it properly, what each setting actually controls, and the mistakes that get people locked out of it or ignored by their own server.
Where to Find It
Log into cPanel and search for MultiPHP INI Editor in the top search box, or find it under the "Software" section. You'll see two modes:
- Editor mode — pick a domain from the dropdown, edit a raw
php.ini-style text block, click Save. - Basic mode — the same settings shown as individual form fields with dropdowns. Safer if you're not sure of exact syntax.
Basic mode is enough for 90% of what people actually need to change. Switch to Editor mode only when you need a directive that isn't exposed as a field — disable_functions or a custom session.save_path, for example.
The Settings That Matter Most
These five cause the majority of support tickets we see, so they're worth understanding rather than just cranking up:
| Setting | What it controls | Common symptom when too low |
|---|---|---|
memory_limit | Max RAM one PHP process can use | "Allowed memory size exhausted" fatal error |
upload_max_filesize | Max size of a single uploaded file | Media upload fails silently or with an HTTP error |
post_max_size | Max size of the whole POST request (must be ≥ upload_max_filesize) | Large forms or bulk uploads fail even if the file itself is small enough |
max_execution_time | How long a script can run before PHP kills it | Plugin imports, large SQL restores, or theme installs time out mid-way |
max_input_vars | How many form fields/array items a request can carry | WordPress menus or Elementor pages silently drop items on save |
Notice the dependency between upload_max_filesize and post_max_size. If you set the file size limit to 128M but leave post_max_size at 64M, uploads still fail — the request itself gets rejected before PHP even looks at the file size setting. Always raise post_max_size to match or exceed upload_max_filesize.
A Sane Starting Point
For a typical WordPress or WooCommerce site on shared or VPS hosting, this combination clears almost every "resource limit" ticket we get without being reckless about memory usage:
memory_limit = 256M
upload_max_filesize = 128M
post_max_size = 128M
max_execution_time = 300
max_input_vars = 3000If you're running a resource-heavy site — large product catalogs, PDF generation, big SQL imports through a plugin — push memory_limit to 512M and max_execution_time to 600. Don't go much higher than that by default. A generous limit doesn't fix a slow query or a memory leak in a plugin; it just lets it run longer before failing, which can make a struggling server worse under load, not better.
Why Changes Sometimes Don't Take Effect
This is the part that trips people up the most, and it's rarely a cPanel bug:
- Wrong PHP handler. If the domain uses
mod_php/DSO instead of PHP-FPM or suPHP, the MultiPHP INI Editor settings may not apply cleanly — check MultiPHP Manager first and confirm the domain is on FastCGI or PHP-FPM. - An .htaccess override. A line like
php_value upload_max_filesize 20Mleft over from an old migration or plugin will silently override whatever you set in cPanel, because .htaccess is read after the INI editor's config. Search the site's .htaccess for strayphp_value/php_flaglines and remove them. - Caching. OPcache and some page caches hold onto old PHP-FPM worker state. Restart PHP-FPM for the domain (MultiPHP Manager → Restart, or via WHM if you have root) after a change, then hard-refresh.
- Wrong domain selected. If the site runs on an addon domain, the INI Editor treats it as its own entry separate from the main account domain — double check you edited the right one from the dropdown.
To confirm a setting actually applied, don't trust memory — check it. Create a file called phpinfo.php with just <?php phpinfo(); in it, load it in a browser, find the value, then delete the file immediately afterward. Leaving a phpinfo file live on a public site hands an attacker your server paths and loaded modules for free.
Root-Level Access (WHM)
If you manage WHM as a reseller or server owner, the same tool exists at WHM → MultiPHP INI Editor, but with an extra option: you can set defaults at the PHP-version level (affecting every account using that version) instead of per-domain. That's the better place to set a sane baseline across all accounts, letting individual customers override it per-domain only when they genuinely need to.
Prevention
A few habits keep this from becoming a recurring ticket:
- Set your baseline (the table above) once, right after provisioning a new account, instead of reacting to each error as it appears.
- Keep a note of what PHP handler each domain uses — it saves time the next time a setting "doesn't stick."
- Audit .htaccess after any theme, plugin, or migration tool install — many of them insert their own php_value lines without telling you.
- Re-check limits after every PHP version upgrade. cPanel keeps separate INI settings per PHP version, so moving a site from PHP 8.1 to 8.3 can reset it to that version's defaults.
Frequently Asked Questions
Does changing memory_limit here affect the whole server?
No — settings made in the MultiPHP INI Editor at the account level apply only to that domain (or addon/subdomain). Server-wide defaults are set separately in WHM, and individual domains can still override them upward, but not usually past a ceiling the server admin has set.
Why can't I set memory_limit above a certain number?
Hosting plans often cap this in WHM at the package or PHP-version level. If the field won't accept a higher value or resets after saving, the ceiling is set above your account — contact support to raise the package limit rather than fighting the field.
I changed upload_max_filesize but WordPress still shows the old limit
WordPress reads whichever of upload_max_filesize or post_max_size is lower, and it also checks a couple of other spots — some managed hosting setups and security plugins define their own upload cap on top of PHP's. If phpinfo() shows the new value but WordPress's Media settings page doesn't, the override is coming from a plugin, not PHP.
Editor mode vs Basic mode — which should I use?
Basic mode for routine changes; it validates input and won't let you save a syntax error. Editor mode is for directives that don't have their own form field, like disable_functions — be careful there, since a malformed line can break PHP for that domain until it's corrected.
Do I need to restart anything after saving?
Usually the change is picked up on the next request, but if you don't see it immediately, restart PHP-FPM for that domain in MultiPHP Manager (or ask your host if you're on shared hosting) and clear any object/page cache before retesting.
