PHP version keeps changing back in cPanel: causes and fixes
|

PHP Version Keeps Changing Back in cPanel: Causes and Fixes

This is a problem that looks solved and then comes back. A site was running an old PHP version although the control panel showed a newer one. Deleting the .htaccess file fixed it, and about a day later the same problem returned. This post explains why that pattern happens, what to check so you can find the real cause, and why deleting the file is a risky fix. It is the follow-up to the case where Composer demanded PHP 8.3 on a site that cPanel said was on 8.4.

What happened

  • The PHP version was set to 8.4 in cPanel, but the site kept running an older PHP.
  • An .htaccess file I inspected referred to PHP 8.2.
  • When I deleted the .htaccess, the site worked.
  • About a day later, the same problem returned.

The order of these steps is approximate. In the end, my hosting provider’s support team changed a configuration in WHM, which I cannot access, and it was resolved. I was not told what the change was, so the explanations below are possibilities that fit the documentation, not a confirmed diagnosis of my account.

Why deleting the file seemed to work

A PHP handler line in .htaccess can override the version you pick in the control panel. LiteSpeed’s documentation for PHP Selector on cPanel lists the rules for LiteSpeed with CloudLinux, and its first rule is that when no .htaccess is found, the system default PHP version is applied. So removing a file that pinned an old version can let the server fall back to the version it is configured for. That is a plausible reason the site started working at once. (How this works on your server depends on its stack. See which PHP setting wins on cPanel.)

Why the problem can come back

For the problem to return, either the file was recreated or changed, or a different setting started to take effect. Based on the documentation, these are the things worth checking:

  1. cPanel itself rewrites the handler block. A cPanel article about the command-line PHP version says that when the version is changed in MultiPHP Manager, cPanel updates the .htaccess configuration in the domain’s document root. That generated block is marked “php — BEGIN cPanel-generated handler, do not edit”. If the version stored for the domain in MultiPHP Manager is an old one, a later change or re-apply writes the old handler back. I cannot say whether that is what happened here.
  2. MultiPHP Manager and PHP Selector are not set up the way you intend. Different versions in the two tools are normal when PHP Selector supplies ALT-PHP. What matters, according to cPanel’s article on using MultiPHP Manager with PHP Selector, is whether the domain’s MultiPHP Manager version matches the server default: if it does, the web server uses the PHP Selector version, and if it does not, PHP Selector is not what decides. For a domain meant to run ALT-PHP through PHP Selector, cPanel recommends setting MultiPHP Manager to inherit. Confirm with your host which setup your domain should have.
  3. Something in the application writes .htaccess. When WordPress updates its own rewrite rules, it uses insert_with_markers() with the WordPress marker, which replaces only the lines between # BEGIN WordPress and # END WordPress and retains the rest of the file. So a handler line outside that block should not be removed by that normal update. I have not checked other WordPress code paths, and some security or caching plugins also edit the file; I have not checked what any particular plugin does. Check recent plugin or settings changes around the time the problem came back.
  4. A server-side setting may be applied again. I have no evidence that this happened, but if a host-level setting or an automated job re-applies a configuration, your host is the one who can check the relevant settings, automation and logs.

Why deleting .htaccess is a risky fix

The file can hold more than the PHP line. On a WordPress site it normally holds the rewrite rules that make permalinks work, and it may also hold redirects, security rules and cache rules. If you delete it, those stop working until something recreates them. Take a copy first. If a cPanel-generated handler block is involved (the one marked “do not edit”), change the version through the control panel or your host rather than editing the block by hand, and edit handler lines yourself only where your host documents that. If you do have to remove the file, keep the copy so you can put the other rules back.

How to find out what keeps changing it

  1. Keep a copy of the working .htaccess and note the time you fixed the problem.
  2. When the old version returns, open the file in cPanel’s File Manager and look at its last modified time. If it changed just before the problem returned, something rewrote it.
  3. Compare the handler line with the version shown in MultiPHP Manager for that domain.
  4. Look at what MultiPHP Manager and PHP Selector each show for the domain, and ask your host which of them is meant to control PHP for it. If they disagree, ask the host to set them up for the intended tool (for a domain run through PHP Selector, that means MultiPHP Manager on inherit).
  5. Check whether a plugin or security tool rewrote the file at that time.
  6. If you still cannot tell, send your host the file’s modified time, the handler line, and the versions shown in both tools, and ask what in WHM could re-apply an old version.

What to ask your hosting provider

  • Which handler is my domain set to use, and which tool controls the PHP version?
  • Is my domain set to “inherit” in MultiPHP Manager?
  • Is anything on the server, such as a scheduled task, a template, or a default, re-applying an older PHP version or rewriting the handler block in my .htaccess?
  • Is PHP-FPM enabled for my domain?

Checklist

  1. Back up the .htaccess before you edit or delete it.
  2. Note the file’s last modified time, so you can tell if it is rewritten.
  3. Ask your host which tool controls PHP for your domain, and have the other one set accordingly.
  4. Check plugins and settings that write .htaccess.
  5. Do not rely on deleting the file as a permanent fix.
  6. If it keeps returning, give your host the evidence above and ask them to check WHM.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *