PHP Settings for a Domain: Version, Extensions, and Limits

Your site won't come up. It's a white screen, or it's throwing a 500 Internal Server Error, or WordPress is showing the "allowed memory size exhausted" message. If you've just installed a script or changed the PHP version from the panel, there's a good chance the issue is exactly the PHP settings, not your code. This text was written for that very moment: what to change and where, why some changes don't take effect, and which number you actually need to raise.

First, figure out which PHP version is running

Before any change, look at the actual output. Create a file called info.php in the domain root with this content:

<?php phpinfo(); ?>

Then open its address in a browser. Look for two things: the Loaded Configuration File line, which shows the real path to php.ini, and the PHP Version line. If the Loaded Configuration File path is empty or (none), it means no custom php.ini file has been loaded and any change you make in other files will have no effect. This is one of the most common causes of confusion.

A faster way from the command line, if you have SSH:

php -v
php -i | grep -E "memory_limit|max_execution_time|upload_max_filesize"

Note that the CLI version can differ from the version the web server runs for the domain. The number you see in phpinfo() is the reference, not the terminal output.

Change the PHP version for one domain, not the whole server

On shared hosting, the PHP version is usually selected from the domain management panel. In cPanel the path is MultiPHP Manager; in DirectAdmin it's the PHP Version Selector section. You pick the version from the dropdown and save. The change takes effect immediately, but not always without a cost.

The point that catches many people off guard: upgrading from PHP 7.4 to 8.1 or 8.2 can break old extensions. If the site went white after the version change, first look at the error log instead of immediately reverting to the previous version. In cPanel the log is usually visible in ~/logs or from the Errors section. Look for a line like PHP Fatal error: Uncaught Error: Call to undefined function; this means an extension isn't compatible with the new version.

Which version should I choose

If you have a WordPress site and your extensions are up to date, choose PHP 8.1 or 8.2. The speed difference is noticeable and security support for older versions has ended. If you have an extension that hasn't been updated in years and you're forced to keep it, stay on 7.4 until you find a replacement. This is a real trade-off: security and speed versus compatibility. In practice, I choose 8.1 and if an extension breaks, I replace that extension, not the PHP version.

Enable PHP extensions only when you need them

Extensions are enabled from the panel. In cPanel, the Select PHP Version section and then the Extensions tab. You tick the checkboxes and save. The list usually includes mysqli, curl, gd, mbstring, zip, intl, opcache and dozens of other items.

Here's the mistake people make: the user enables all the extensions to "fix the problem." The result is higher memory usage per request and sometimes conflicts between extensions. If you have WordPress, the necessary minimum is these: mysqli, curl, gd or imagick, mbstring, zip, json, xml. Enable the rest only when a specific extension has been named in an error message.

The sign of wrongly enabled extensions is this: the site works but TTFB has gone up and the memory usage of each PHP process is higher than before. If you're facing this situation, the complete reference of hosting resource limits explains what each number counts.

Set memory_limit and max_execution_time correctly

The two numbers that generate the most support tickets are these. The default value of memory_limit is usually 128M or 256M and max_execution_time is at 30 seconds. For WordPress with several heavy extensions, 256M is low and 512M is more reasonable. For max_execution_time, a value of 300 is sensible for content import or backup operations.

You can change these values in three places and the order of precedence matters:

1. A custom php.ini file in the domain root or the path specified by the host. It's the strongest option and affects all requests for that domain.
2. The .htaccess file with lines like php_value memory_limit 512M. It only works when PHP runs as an Apache module, not CGI or PHP-FPM.
3. The wp-config.php file with define('WP_MEMORY_LIMIT', '512M');. It only has an effect inside WordPress and if the host has set a strict ceiling, it stays ineffective.

If you got a 500 Internal Server Error after changing .htaccess, it means the server doesn't allow this directive. Remove that line and use php.ini. This error is immediate and clear, but if you edit .htaccess incorrectly and the site goes down, reverting it becomes harder. Always take a copy before editing.

Limits that won't go higher from the panel

On shared hosting, the ceiling for memory_limit and max_execution_time is set by the provider. If you set a number above the ceiling, the panel ignores it or reverts it to the ceiling. Check this in phpinfo() after the change; if the number hasn't changed, it means the ceiling has been applied. In that case you have two options: optimize the code and extensions, or move to a dedicated server that gives you full control over php.ini.

Check PHP settings from the command line and script

When the site won't come up and you can't view phpinfo(), use SSH. If you don't have SSH access, through the free webmaster tools you can check the domain status and DNS records to make sure the problem is with PHP and not with the path to the server.

To see the actual errors instead of a white screen, temporarily add these two lines at the top of the executable file:

ini_set('display_errors', 1);
error_reporting(E_ALL);

And after finding the error, be sure to turn display_errors off. If it stays on, file paths and database details become visible to everyone. This is one of the mistakes I see a lot in audits and it has security consequences.

For WordPress errors, the fixing white screen in WordPress and PHP guide explains this same task step by step in more detail. If the problem came up after a domain change, the guide to moving a site to a new domain has points related to PHP settings.

A note about resource usage

Raising memory_limit hides the problem, it doesn't solve it. If a script runs out of memory at 128M, it probably has an infinite loop or works on large data without pagination. Raising the ceiling only lets it consume more and on shared hosting, it eats into everyone else's share too. If your site's memory usage keeps climbing, before increasing the number, read the Entry Process and how it differs from a visit section to understand what's actually being consumed.

For high-traffic sites or applications that need precise PHP settings, ServerNet Linux hosting lets you choose the version and configure parameters from the panel; but if you need full control over php.ini and compiling custom extensions, a dedicated server is the better choice.

Frequently asked questions

Why do I see no change after changing memory_limit in wp-config.php?

Because the host has set a strict ceiling at the server level and your value is above it. Check the actual number in the phpinfo() output; if it's the same as before, the change hasn't been applied. In this case you should use a custom php.ini or talk to support about the allowed ceiling.

What's the difference between php_value in htaccess and php.ini?

php.ini is loaded at the domain or server level and affects all requests. php_value in .htaccess only works when PHP runs as an Apache module. If the server is PHP-FPM, these lines are ignored or give a 500 error. To be sure, try php.ini first.

Which PHP version is suitable for WordPress?

For recent versions of WordPress, PHP 8.1 or 8.2 is the best choice. Version 7.4 no longer gets security support and staying on it is risky. If an extension isn't compatible with the new version, replace it; keeping an old PHP version for the sake of one extension is a bad trade.

How do I tell if the problem is from PHP settings or from the site code?

Create a simple file with <?php echo "ok"; ?> in the domain root and open it. If this file opens but the site doesn't, the problem is with the site's code or extensions. If this same file also errors, the problem is with the PHP settings or the server. This simple test points you in the right direction most of the time.

Next step: right now, open phpinfo() and note down the three numbers memory_limit, max_execution_time and upload_max_filesize. If they don't match what you expect, start right there.