You changed one line in .htaccess to raise an upload limit, saved it, and now the whole site returns a 500 Internal Server Error. Revert the line and everything works again. If that sounds familiar, you've hit one of the most common side effects of moving a site to PHP-FPM or a newer PHP handler: php_value and php_flag directives no longer belong in .htaccess.

Symptom: 500 error right after editing .htaccess

The typical lines that trigger it look like this:

php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value memory_limit 256M
php_flag display_errors off

They worked for years on the old setup. Then you switched PHP versions, someone enabled PHP-FPM, or the site moved to a new server, and suddenly the same file kills the site. You'll also see this in the Apache error log:

/home/youruser/public_html/.htaccess: Invalid command 'php_value',
perhaps misspelled or defined by a module not included in the server configuration

Cause: those directives only exist in mod_php

php_value and php_flag are not Apache or PHP features in general. They're provided by the mod_php (DSO) Apache module. When PHP runs through PHP-FPM or FastCGI, Apache has no idea what those words mean, so it refuses to parse the file and returns a 500 for every request in that directory tree.

That's why the error shows up for the whole site and not just one script. Apache reads .htaccess on every request, and one unknown directive is fatal.

PHP handlerphp_value in .htaccessWhere to set limits
mod_php (DSO)Works.htaccess or php.ini
PHP-FPM500 errorMultiPHP INI Editor or .user.ini
FastCGI / suPHP500 errorphp.ini or .user.ini

Fix: pick one of three clean options

Option 1: MultiPHP INI Editor (easiest)

  1. Log in to cPanel and open MultiPHP INI Editor.
  2. Choose your domain from the dropdown.
  3. Change upload_max_filesize, post_max_size, memory_limit and so on, then click Save.

This writes the values for that domain's PHP-FPM pool, so it applies cleanly with no file hunting.

Option 2: a .user.ini file

Create public_html/.user.ini with the same settings, minus the php_value prefix:

upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
display_errors = Off

PHP re-reads .user.ini about every five minutes (the user_ini.cache_ttl default is 300 seconds), so don't panic if the change isn't instant. Booleans use On/Off, not php_flag.

Option 3: guard the lines so they never crash the site

If you maintain a file that may run on either handler, wrap the directives in a module check:

<IfModule mod_php.c>
  php_value upload_max_filesize 64M
  php_value post_max_size 64M
</IfModule>
<IfModule mod_php7.c>
  php_value upload_max_filesize 64M
</IfModule>

On PHP-FPM those blocks are simply skipped. It's a safety net, though, not a fix: the limits won't apply either, so you still need option 1 or 2.

Getting the site back first

If you're locked out right now, do this before anything else:

  1. Open File Manager and enable Show Hidden Files in Settings.
  2. Rename .htaccess to .htaccess-old. The site should load again.
  3. Copy back only the lines that aren't php_value/php_flag (rewrite rules, redirects, and so on).
  4. For WordPress, if permalinks 404 afterwards, go to Settings → Permalinks and click Save to regenerate the default rules.

To confirm the cause, check Metrics → Errors in cPanel. The "Invalid command 'php_value'" line is unmistakable.

Check the change actually applied

Don't trust the file, trust PHP. Create a temporary info.php containing <?php phpinfo();, load it, and search for upload_max_filesize. The "Local Value" column is what your site really uses. Delete the file when you're done, since phpinfo() output leaks server details.

WordPress users can also look under Media → Add New, where the maximum upload size is printed, or Tools → Site Health → Info → Server.

Prevention

  • Before switching PHP versions or handlers, search your tree for leftovers: grep -rn "php_value\|php_flag" ~/public_html --include=.htaccess
  • Back up .htaccess before editing. A copy named .htaccess.bak takes five seconds.
  • Keep PHP limits in one place (the MultiPHP INI Editor) so you don't hunt through three files later.
  • Some plugins and installers still write php_value lines into .htaccess. After running one, load the site straight away to catch a 500 early.
  • Remember that hosting plans can cap values. If you set memory_limit higher than your plan allows, the cap wins.

Frequently Asked Questions

Why did my site work before I changed PHP versions?

Your old setup probably used mod_php, which understands php_value. The new handler (PHP-FPM or FastCGI) doesn't, so Apache rejects the file.

Can I use php_value and PHP-FPM together if I enable some module?

No. The directives are tied to mod_php itself. Use the MultiPHP INI Editor or .user.ini instead.

My .user.ini change isn't showing up. What now?

Wait up to five minutes for PHP to re-read it, then check phpinfo(). Also make sure the file sits in the same folder as the script, or in a parent folder up to the document root.

Does this affect only the main domain?

It affects every directory that inherits the broken .htaccess, including subfolders and often addon domains living below it.

Will raising limits fix my "file exceeds upload_max_filesize" error?

Yes, as long as you raise both upload_max_filesize and post_max_size, with the second at least as large as the first. If you still hit limits, check for a web server cap as well.