cPanel gives you two separate controls over PHP, and knowing which one you are looking at prevents most of the confusion here. One selects the PHP version your site runs. The other adjusts the settings within whichever version you selected. Changing the second when you meant the first is why people report that raising a limit did nothing.
Changing the PHP version
In cPanel, look for MultiPHP Manager or Select PHP Version depending on your account's setup. Both do the same job: pick a PHP version for a domain.
Select the domain, choose the version, and apply. The change takes effect immediately, no restart, no waiting.
Move up one major version at a time rather than jumping several. Then load the site properly: homepage, a deep page, the admin area, and any checkout or form. Old code occasionally calls functions removed in newer PHP, and the failure is usually loud and immediate, which makes it easy to reverse.
Running a current version is worth doing. PHP performance has improved substantially across recent releases, and old versions stop receiving security fixes. Staying on an unsupported version to keep one abandoned plugin working is a poor trade; the plugin is the thing to replace.
If several sites share the account, each domain can run its own version. That is useful during a migration, and a nuisance if you forget: check what each domain is set to instead of assuming they match.
Changing PHP settings
The screen is called PHP Options, MultiPHP INI Editor, or something similar. It edits values within the version already selected.
Four settings account for nearly every real need:
memory_limit: how much memory one script may use. Raise this when you see "Allowed memory size exhausted". 256M is comfortable for most WordPress sites.
upload_max_filesize. The largest file that can be uploaded. This is the one behind "the file exceeds the maximum upload size" in WordPress media.
post_max_size; the largest complete form submission. It must be at least as large as upload_max_filesize, because an upload arrives inside a form submission. Raising only the first and not the second is the single most common mistake on this screen, and it produces the confusing outcome where the limit says 64M and a 20M file still fails.
max_execution_time: how long a script may run. Relevant to imports, backups and migrations. Prefer doing the work in smaller pieces over setting a very large value.
Save, then confirm the change actually applied rather than trusting the form. WordPress shows the effective values under Tools then Site Health then Info; a small PHP file calling phpinfo() works anywhere, and should be deleted immediately after use.
When a setting will not change
Some values are capped at the server level, and no amount of editing raises them past that ceiling. If you set memory_limit to 1024M and it reports 256M afterwards, that is the cap in place of a failed save.
It is also worth checking whether something else is overriding you. A php.ini or .user.ini in the site directory, or PHP directives in .htaccess, can take precedence over the cPanel setting. If a value refuses to move, look for those files before assuming the panel is broken.
Extensions
The same screen usually lists PHP extensions with checkboxes. Applications need specific ones: image processing, a particular database driver, encryption libraries.
The important detail is that extensions are enabled per PHP version. Switch a domain from one version to another and the extensions you enabled do not follow. A site that worked yesterday and fails today after a version change is very often missing an extension rather than incompatible with the version.
Enable only what is needed. Every extension loads on every request.
A working order
- Choose the PHP version for the domain.
- Enable the extensions that version needs.
- Adjust the settings.
- Confirm the effective values, not the form values.
- Load the site: front end, admin, and any transactional flow.
Steps two and three come after step one for a reason: changing the version resets both.
When more resources is the wrong answer
Raising a limit is quick, which makes it tempting when something else is wrong.
A site that needed 128M last month and needs 512M today has usually acquired a plugin doing something expensive, and raising the number hides that until it stops working again. An import that times out at 300 seconds will time out at 600 with slightly more data. And a site that is slow rather than failing needs a different approach entirely. Optimizing WordPress performance goes over what actually costs the time.
When a setting change does not fix the symptom, read the log rather than raising the number again. Understanding cPanel error logs goes into which log holds which failure.
If PHP is configured correctly and a file still appears as plain source, the extension is not being handed to PHP at all. There is more on that case in Apache Handlers and MIME Types in cPanel.