Why Your php.ini File Differs from Your Neighbor's
A site that throws Fatal error: Allowed memory size of 134217728 bytes exhausted and a site that sees the same error with the number 268435456 do not have the same problem. The first is limited to 128 MB, the second to 256 MB. Both are hitting the memory ceiling, but someone else set that ceiling. On shared hosting, the main php.ini is not in your hands; what you see is the result of three layers: the value compiled into PHP itself, the value from the server's main file, and the value from the .user.ini or dedicated php.ini file placed in your site's root. This article explains what each directive does, what its default value is, and whether you can even change it in a shared environment.
Memory and Execution Directives; Where 90% of Errors Come From
memory_limit
The memory ceiling a single script can consume. The default in PHP 8.x is 128M, but many shared hosts set it to 256M. If WordPress hits an exhausted error, the first culprit is a low-quality plugin, not this setting. Indiscriminately raising this number on shared hosting is a recipe for crashing the entire server; so if you need more than 256 MB, the problem lies elsewhere.
On shared hosting, you can usually raise it up to a cap set by the provider (for example, 512 MB). Above that, no. This is where people make a mistake: they raise the number to the allowed cap, the error disappears for a few days, and then they face a 503 Service Unavailable error because the entire site has exceeded the CPU limit. More memory means more processing, and more processing means a larger share of the CPU. Solve the problem by checking logs, not by enlarging the cap.
max_execution_time
The allowed execution time for each script, in seconds. The default in PHP is 30; on shared hosting it is usually 60 or 120. If a script processing images or bulk emails needs more time than this, the right approach is to use a cron job, not to raise this number. A script that runs for 300 seconds will slow down your neighbors on shared hosting too.
Note that in PHP 8, this value only counts the execution of the script itself, not the time spent waiting for input. So if a script is waiting for a response from an external API, this timer pauses. Many people do not know this and assume the timeout comes from I/O.
max_input_vars
The maximum number of input variables a single request can have (GET, POST, and Cookie). The default is 1000. A form with 1,200 fields will silently drop the last 200 fields. You will see no error; the data is simply lost. This is one of those silent errors that can take hours to debug.
On shared hosting, you can usually raise it to 2000 or 3000. Anything higher is a sign of poor form design, not a real need.
Upload Directives; Where the End User Sees Errors
upload_max_filesize and post_max_size
The first is the size cap for each uploaded file; the second is the cap for the entire POST request body. The defaults are 2M and 8M respectively. On shared hosting, they are usually 64M and 128M. The golden rule: post_max_size must always be larger than upload_max_filesize, because the request body includes the file plus all other form fields.
This is where people make a mistake: they only raise upload_max_filesize, and then uploading a 30 MB file fails with a 413 Request Entity Too Large error or a blank PHP error. The real cap is the smallest number among these two settings and the web server limit (for example, client_max_body_size in Nginx). You must align all three.
max_file_uploads
The maximum number of files in a single request. Default is 20. If you have a form where a user must upload 30 images, the rest are silently dropped. On shared hosting, changing this value is usually possible, but raising it to 50 or 100 puts real pressure on memory and execution time.
Security Directives; Defaults Are Not Trustworthy Here
display_errors
In a development environment, it should be On so you can see errors. In production, it should be Off. The default in PHP 8 is On, but shared hosts usually set it to Off and write errors to error_log. If you see a WordPress white screen and no message is displayed, check this setting first.
On shared hosting, changing this value via .user.ini is usually possible, but if the provider has set it to Off at the server level, you cannot override it. In that case, you must read the error log. The guide on fixing the white screen in WordPress and PHP walks through exactly this path.
disable_functions
The list of functions that are completely disabled. On shared hosting, dangerous functions such as exec, shell_exec, system, and passthru are usually disabled. This is a security restriction, not a flaw. If a plugin needs these functions, that plugin was not designed for shared hosting.
A subtle point: some functions like mail() may not be disabled but are heavily restricted. If your site's emails go to spam or are not sent at all, check this first, not your SMTP settings.
Execution Directives; The Difference Between Shared Hosting and Dedicated Servers
opcache.enable
The cache for PHP intermediate code. When On, scripts are not recompiled after the first run and execute directly from memory. This is where you see a real difference: a site with opcache disabled is 3 to 5 times slower than the same site with opcache enabled. On shared hosting, it is usually On and you cannot turn it off. If it is off, the provider deliberately disabled it, because opcache consumes server memory on shared hosting.
If you are on a dedicated server, set opcache.memory_consumption to 128 or 256 MB and set opcache.revalidate_freq to 2 to 5 seconds. Do not set it to zero; that means it checks whether the file changed every time and effectively renders the cache useless.
realpath_cache_size
The cache for real file paths. Default is 4096K in PHP 8. A site with thousands of included files will read paths from disk every time if this cache is small. On shared hosting, you do not have access to this value; on a dedicated server, you can raise it to 8192K. The difference is noticeable, but not as much as opcache.
Which Directives You Cannot Change on Shared Hosting at All
The following list contains directives that are locked at the server level on 99% of shared hosts, and no matter what you write in .user.ini, it will have no effect:
allow_url_fopen— usuallyOnand you cannot turn it offopen_basedir— directory access restriction, set by the providersession.save_path— the path where sessions are storederror_log— the path to the error log fileextension— loading PHP extensions
If you see these in phpinfo with values different from what you wrote in your file, they are locked. Fighting these restrictions is a waste of time. Either work within the limitation or migrate to an environment with more access.
The Correct Way to Change Settings on Shared Hosting
On cPanel hosts, the .user.ini file in the public_html root is valid, and its settings propagate to all subdirectories. If you only want to change a specific subdirectory, place the file there. The syntax is simple:
memory_limit = 256M
max_execution_time = 120
upload_max_filesize = 64M
post_max_size = 128M
max_input_vars = 3000
display_errors = OffAfter making changes, verify with a test file containing <?php phpinfo(); ?> whether the new value has been applied. If it has not, the provider has locked it. You can also check this method with the free webmaster tools.
Quick Comparison: Directives You Should Know
| Directive | PHP 8 Default | Typical on Shared Hosting | Changeable on Shared Hosting? |
|---|---|---|---|
| memory_limit | 128M | 256M | Up to the provider's cap |
| max_execution_time | 30 | 60–120 | Usually yes |
| upload_max_filesize | 2M | 64M | Yes |
| post_max_size | 8M | 128M | Yes |
| max_input_vars | 1000 | 2000–3000 | Yes |
| display_errors | On | Off | Depends on the provider |
| opcache.enable | On | On | No |
Frequently Asked Questions
Where is my php.ini file?
On cPanel shared hosting, you usually need to create a .user.ini file in the public_html root. To find the exact path, create a test file with <?php phpinfo(); ?> and look for the Loaded Configuration File value.
Why are my php.ini changes not being applied?
There are two common reasons: either the directive you changed is locked at the server level (such as disable_functions), or you have not restarted PHP after the change. On shared hosting, changes to .user.ini are usually applied immediately, but if not, wait a few minutes or use the "Restart PHP" option in your control panel.
Which php.ini settings are critical for WordPress?
memory_limit of at least 128 MB, max_execution_time of at least 60 seconds, and upload_max_filesize of at least 32 MB. If your site works with these three numbers and still throws errors, the problem is not PHP; it is a bad plugin or theme. The guide on optimizing WordPress on shared hosting shows a more detailed path.
What is the difference between php.ini and .htaccess?
.htaccess controls Apache web server settings (such as redirects and rewrites), while php.ini controls the settings of the PHP language itself. Some settings like upload_max_filesize can be seen in both, but if your host uses Nginx, .htaccess does not work at all and only .user.ini is valid.
One final note: before making any change, record the current values with phpinfo. If the site breaks later, the first thing you do is restore those values. Without a reference point, every subsequent change is a gamble.