Change PHP settings in cPanel

In addition to the PHP version, PHP has numerous settings that influence the behavior of a website or web application. These include, for example, memory limits, maximum upload sizes, execution time limits, or error reporting settings.

In CURIAWEB-cPanel you can configure many of these values via the MultiPHP INI Editor manage.

In this guide, we will show you step by step how to check and change PHP settings for a domain, what the basic and editor modes mean, and what you should pay attention to when making changes to the PHP configuration.

Important: Change PHP settings only if you know why a specific setting needs to be adjusted. Higher values do not automatically make a website faster or better and cannot arbitrarily override server-side limits.

PHP version and PHP settings are not the same #

First, you should differentiate between the PHP version used and its configuration.

For example, the PHP version could be a current version available on your hosting.

Within this PHP environment, in turn, there are settings such as:

memory_limit
upload_max_filesize
post_max_size
max_execution_time
max_input_time
max_input_vars
display_errors

You generally set the PHP version in CURIAWEB via the MultiPHP Manager celebration.

You can find the instructions for this at Change PHP version in cPanel.

What is a php.ini? #

PHP uses configuration directives, which traditionally with a configuration file named:

php.ini

are connected.

This allows PHP directives to be defined with corresponding values.

For example:

memory_limit = 256M

or:

max_execution_time = 60

In cPanel, you don't necessarily have to edit such settings manually in a file for typical adjustments. For that, there is the MultiPHP INI Editor available.

CURIAWEB recommends the MultiPHP INI Editor #

For PHP settings that can be managed via this function, you use in CURIAWEB cPanel:

Software → MultiPHP INI Editor

This keeps the PHP configuration clear and allows it to be managed directly via cPanel.

CURIAWEB recommendation: Do not blindly copy PHP configuration lines from old online tutorials into files like .htaccess, php.ini or .user.ini. For supported settings, please use the designated cPanel management interface first.

When do you need to change PHP settings? #

An adjustment may be necessary, for example, if an application explicitly requires a specific PHP value or a concrete error message indicates a limitation.

Typical situations are:

• an application needs more PHP memory
• a file exceeds the maximum upload size
• a PHP process reaches its maximum execution time
• an application processes a very large number of input fields
• a developer temporarily needs certain diagnostic settings

Therefore, the setting should always have a concrete technical reason.

1. Log in to cPanel #

Log in to your CURIAWEB cPanel.

Then open:

Software → MultiPHP INI Editor

There you can manage the PHP configuration for the available areas or domains.

2. Select the correct domain or home directory #

In the MultiPHP INI Editor, select the domain whose PHP settings you want to edit.

Depending on the cPanel configuration, for example, a domain or the Home Directory are offered for selection.

Carefully check which area you are editing.

Attention: If multiple websites are hosted in your account, you should check before every change which area the setting will apply to. Do not accidentally change the PHP configuration of another website or a parent area.

3. Distinguish between Basic Mode and Editor Mode #

The MultiPHP INI Editor typically offers two different modes of operation:

• Basic mode
• Editor mode

For normal adjustments, the basic mode is usually the simpler and safer option.

What is the basic mode? #

In basic mode, cPanel displays selected PHP directives as individual settings.

You don't have to write a complete configuration file yourself as a result.

Depending on the server configuration, settings such as these may be available there:

memory_limit
max_execution_time
max_input_time
max_input_vars
post_max_size
upload_max_filesize

Which values can actually be displayed and changed depends on the PHP and server configuration.

What is the editor mode? #

The editor mode enables direct editing of PHP configuration directives in text form.

For example:

memory_limit = 256M
max_execution_time = 60

This mode offers more direct control, but also requires a more precise understanding of the respective PHP directives and their valid values.

Important: Do not use the editor mode just because it makes more settings visible. For typical changes, the basic mode is often clearer and less error-prone.

4. Note the current value before the change #

Before changing a PHP setting, note down the previous value.

For example, if currently:

max_execution_time = 30

is set and you change the value as a test, you should know what initial value you can return to if needed.

Practical Tip: If there are multiple changes, you can take a screenshot of the current values beforehand. This makes later troubleshooting considerably easier.

5. Change desired PHP setting #

Search for the desired PHP directive in basic mode and enter the intended value.

Which setting you should change depends on the specific problem or the requirements of your application.

Change only the setting for which there is an actual reason, if possible.

6. Save or apply changes #

Then apply the changed PHP configuration.

Wait for confirmation from cPanel that the settings have been saved.

Check afterwards whether the desired value is still displayed.

7. Test website immediately afterwards #

Test the website or function in question directly after the change.

For example, if you changed a setting because of a failed upload, specifically retry that upload.

If an application has failed due to a runtime limit, specifically test the relevant operation.

Basic rule: Change one value, test the specific problem, and document the result. If you change five settings at the same time, you will no longer know which change was actually relevant.

memory_limit – PHP memory limit #

The Directive:

memory_limit

limited simplifies the memory that a PHP process or PHP script is allowed to use within the respective configuration.

A value can be specified in megabytes, for example:

256M

If an application requires more memory, an error message may indicate an exhausted PHP memory, for example.

More memory_limit doesn't automatically make a website faster #

A higher memory_limit PHP merely provides a higher allowed memory limit.

It does not automatically speed up poorly written code and does not eliminate the cause of unusually high memory consumption.

If a website regularly requires very large amounts of PHP memory, the cause should also be investigated.

upload_max_filesize – maximum size of an uploaded file #

The Directive:

upload_max_filesize

determines the maximum size of a single file uploaded via PHP.

An example would be:

64M

This can be relevant, for example, when uploading via WordPress or other PHP applications.

post_max_size – maximum size of POST data #

The Directive:

post_max_size

limits the size of data that can be transferred to PHP via an HTTP POST request.

Therefore, in the case of file uploads, this setting is closely related to:

upload_max_filesize

If upload_max_filesize greater than post_max_size is set, the smaller POST limit can still restrict the upload.

Important: In case of upload problems, you should not only upload_max_filesize Consider. Also post_max_size and further technical limitations may be relevant.

max_execution_time – maximum execution time #

The Directive:

max_execution_time

limits the maximum execution time of a PHP script.

An example:

60

typically stands for seconds in this directive.

A longer execution time can be relevant for certain import, export, or processing operations.

Very high execution time is not automatically a solution #

If a PHP process regularly takes an unusually long time, you should check why this is the case.

A very high value for max_execution_time for example, does not fix an infinite loop, an external network disruption, or inefficient program code.

max_input_time – time for processing input data #

The Directive:

max_input_time

relates to the time PHP is allowed to use for processing input data.

She is not with:

max_execution_time

to equate.

Change this value only if an application or a specific diagnosis indicates that it is relevant.

max_input_vars – Number of input variables #

The Directive:

max_input_vars

limits the number of input variables that PHP can process in a single request.

This setting can become relevant, for example, in the case of very extensive forms, menus, or administration interfaces of certain applications.

If an application explicitly requires a higher value, you can check the current setting in the MultiPHP INI Editor.

display_errors – Display PHP errors in the browser #

The Directive:

display_errors

determines whether certain PHP error messages are displayed directly in the output web page.

This can be helpful during development work, but should be used with caution for a publicly accessible production website.

Attention: PHP error messages can contain internal file paths, function names, or other technical details. Public error output should not be unnecessarily enabled on production websites.

Error log instead of public error output #

For diagnosing a production website, an error log is often more suitable than directly outputting technical errors to visitors.

We explain how to investigate existing errors in cPanel under Read cPanel Error Log and find website errors.

Modifiable and non-modifiable PHP settings #

Not every PHP directive can be changed at the website or user level in every hosting environment.

PHP distinguishes between different configuration levels, and certain values may be preset or limited server-side.

Therefore, if a setting is not available in the MultiPHP INI Editor or if a change does not have the expected effect, you should not try to force it through more and more configuration files.

Important: A shared hosting account does not have unlimited control over the entire PHP and server configuration. Certain limits are deliberately set at the server level.

PHP value and server limit are not the same #

A value set in PHP can only operate within the technical limits of the entire hosting environment.

For example, if you enter a very high PHP value, this does not automatically mean that the web server, PHP process manager, or hosting resources will provide this value without limit.

Therefore, a high numerical value is no substitute for a proper server and application configuration.

CloudLinux resources must also be considered separately #

PHP settings like memory_limit are not the same as the resource limits of the hosting account.

CloudLinux can, for example, manage resources at the account level, whereas memory_limit is a PHP setting.

These levels should not be confused with each other during troubleshooting.

We will discuss resource utilization later under Understanding CloudLinux Resource Usage in cPanel.

PHP setting changed, but application still shows old value #

If an application continues to report a different value after a change, you should first check:

• Was the correct domain or area edited?
• Was the change saved?
• is the website actually using the expected PHP configuration?
• Are there any other local PHP configuration files?
• Is the value limited at a different configuration level?

Do not immediately modify the same directive in multiple places as well.

Multiple PHP configurations can make debugging more difficult #

When the same setting is defined simultaneously via different mechanisms, it becomes difficult to trace which value is actually used.

Possible locations can be – depending on the server configuration – for example:

MultiPHP INI Editor
php.ini
.user.ini
Application Configuration

Older ones too .htaccess-Instructions can play a role in certain environments or cause errors precisely because of an inappropriate configuration.

CURIAWEB recommendation: Keep the PHP configuration as simple and comprehensible as possible. Use the MultiPHP INI Editor for supported settings and do not spread the same setting unnecessarily across multiple files.

Old php.ini files after a website migration #

During a website migration, configuration files from the previous hosting can be copied over as well.

This may include, for example:

php.ini

or:

.user.ini

Such files may contain settings intended for the old hosting environment.

If unexpected PHP values or errors occur after a move, you should therefore check whether old local PHP configurations are present.

.Do not delete .user.ini on suspicion #

If a .user.ini exists, you shouldn't just remove it.

First check their content and whether they are needed by the website or a previous configuration.

Document existing settings before making a change.

Do not blindly adopt PHP settings from foreign tutorials #

On the internet, you will often find configuration examples such as:

memory_limit = 1024M
max_execution_time = 600
upload_max_filesize = 512M

Such values are not a universally applicable recommendation.

They can be unnecessarily high for a specific application, technically ineffective, or not provided for in a hosting environment.

Attention: Do not use extremely high PHP values just because they are mentioned in a guide for another server or another application.

Test PHP settings individually after a change #

When investigating a specific problem, you should change as few relevant values as possible.

For example:

Problem:
PHP memory is not sufficient

Check:
memory_limit

or:

Problem:
File cannot be uploaded due to its size

Check:
upload_max_filesize
post_max_size

This makes it traceable which setting actually had an impact on the problem.

Check PHP settings after a PHP version change #

If you have changed the PHP version of a website and subsequently notice unexpected behavior, you should not only check application compatibility.

Check the PHP settings that apply to the website if necessary.

You can change the PHP version itself at CURIAWEB via the MultiPHP Manager.

PHP extensions are another area #

If an application reports that a certain PHP extension is missing, for example, this is not automatically an issue with the MultiPHP INI Editor.

PHP directives and PHP extensions are different components of the PHP environment.

We cover extension management under Enabling and Managing PHP Extensions in cPanel.

Set PHP limits selectively #

The settings that are needed particularly often:

memory_limit
upload_max_filesize
post_max_size
max_execution_time

let's discuss it in detail and with concrete use cases in the next article.

You can find the instructions under Set PHP memory limit, upload size, and execution time.

PHP settings in WordPress #

WordPress and its extensions can have different PHP requirements.

For example, if WordPress displays an upload limit, it must be taken into account that multiple PHP settings and, if applicable, other technical limits can interact.

Therefore, do not randomly change all visible PHP values.

Distinguish between WordPress Memory Limit and PHP memory_limit #

Additionally, an application-specific memory configuration can play a role in WordPress.

However, a value defined in WordPress cannot enforce a higher server-side PHP limit than the hosting environment actually provides.

That is why PHP configuration and application configuration are separate layers.

PHP settings for large imports #

For large imports, upload size, POST size, execution time, or memory may be relevant.

However, that does not mean that every failed import can be solved by higher PHP limits.

For example, a SQL error within a database is not caused by an increase in memory_limit Fixed.

We cover typical phpMyAdmin import errors under phpMyAdmin import not working: Errors and large SQL files.

Reset PHP settings #

If a change does not bring the desired result or causes new problems, you should restore the previously documented baseline value.

Open this again:

Software → MultiPHP INI Editor

Select the correct range and restore the previous value.

Then save the change and test the website again.

The error persists after resetting #

If the original value has been restored and the error still persists, there may be a different cause.

Then check in particular:

• whether further PHP settings have been changed
• whether local configuration files exist
• whether the PHP version has been changed
• whether there is a user error
• whether the error log contains any clues

PHP Settings for Production Websites #

On a production website, you should make changes in a controlled manner.

Avoid in particular:

• changing many values at the same time
• Permanently enabling error output publicly
• to adopt unknown configuration lines
• delete existing configuration files without checking
• to set extremely high limit values without any technical reason

Instead, document initial values and test specifically.

Recommended procedure for changing a PHP setting #

1. First, determine which PHP setting is relevant to the specific problem.
2. Log in to cPanel.
3. Open Software → MultiPHP INI Editor.
4. Select the correct domain or the correct area.
5. Use basic mode for typical changes.
6. Find the relevant PHP directive.
7. Note the previous value.
8. Enter the designated new value.
9. Save the change.
10. Check the saved value.
11. Test the affected website feature specifically.
12. Change another setting only afterwards if necessary.
13. Restore the initial value if the change does not make sense.

Recommended troubleshooting when a PHP setting does not take effect #

1. Check if you have edited the correct area.
2. Check if the change was saved.
3. Check if the website is using the expected PHP version.
4. Check potential local php.ini- or .user.ini-files.
5. Check if another configuration level affects the value.
6. Consider server-side limits.
7. Check the error log for specific clues.
8. Do not add the same setting elsewhere on suspicion.

Basic rule: A PHP setting should serve a specific technical purpose. Document the initial value, change it in a targeted manner, save it, and then test the exact function affected.

When should you contact support? #

If a required PHP setting is not available, a change does not take effect, or your website subsequently shows errors, you should document the current state as precisely as possible.

For an analysis, the following information is particularly helpful:

• affected domain
• PHP version used
• Name of the PHP directive in question
• previous value
• newly set value
• Reason for the requested change
• exact error message
• or local php.ini- or .user.ini-files are present, if known
• which application or website function is affected

Do not transmit any passwords or other confidential access credentials.

Summary #

You manage PHP settings in the CURIAWEB cPanel via Software → MultiPHP INI Editor. For typical changes, the basic mode is the clearest option, while the editor mode is intended for direct editing of PHP directives.

Note the previous value before making a change, and change only the setting that is relevant to your specific problem, if possible. Higher values do not automatically improve a website and cannot arbitrarily lift server-side resource or security limits.

PHP version, PHP settings, PHP extensions, and CloudLinux resources are different levels. At CURIAWEB, you generally manage the PHP version via the MultiPHP Manager and the supported PHP configuration values via the MultiPHP INI Editor.

If a change does not take effect, you should not enter the same directive in multiple places at the same time. Check the selected area, existing local configuration files, and potential server-side limits first.

The most important rule is: Do not change PHP settings on suspicion – determine the cause, document the initial value, make targeted changes, and then test.