PHP 8.5/5.4 inconsistency between files on the same shared hosting (ticket CS16643535 unanswered for 6 days)

Hello,

Shared hosting kotdor.com, historical account (created in 2013). PHP version configured to 8.5 (SetEnv PHP_VERSION in the .htaccess).

Problem: in the same folder (/home/kotdor/www/), with an exactly identical configuration for all files, some PHP scripts run on 8.5 (confirmed by the x-powered-by header) and others remain stuck on PHP 5.4. Same folder, same config, different behaviour depending on the file.

I also tested the official solution via .ovhconfig (app.engine=php, app.engine.version=8.5, container.image=stable64, http.firewall=none, environment=production), recommended by support in a previous ticket: tested in isolation, it produces a 501 "Not Implemented" error across the whole site.

Ticket opened for 6 days (CS16643535), still no human response despite two follow‑ups – only an off‑topic automatic reply.

Has anyone encountered this kind of PHP inconsistency between files on an old hosting account (execution confirmed in CGI/1.1)? A configuration cache on the infrastructure side, not synchronized between server nodes?

Thanks in advance for any leads.

Hi @JeromeA26

Connect to your FTP and check if you have .htaccess files in the root of your site or in subfolders. Look for lines like SetEnv PHP_VER 5.4 or similar... Those lines force an old PHP version, and even if the .ovhconfig shows 8.5, those local rules can «win» :smirking_face:

Make sure your .ovhconfig file is in the root of your FTP and that its content is correct for PHP 8.5 and the stable environment.

Let us know, cheers.
Sergio Turpín

Anything that is a SetEnv variable will not work on Webhosting offers.
This Apache module is not loaded.

The PHP version is set via the .ovhconfig file:

app.engine=php
app.engine.version=8.5

http.firewall=none
environment=production

container.image=stable64

Thank you for your response, but this is not a new lead; it is exactly the solution already described as tested and failing in my initial message: .ovhconfig with app.engine.version=8.5, container.image=stable64, etc. — tested in isolation, it produces a 501 "Not Implemented" error across the whole site. I am not looking for the standard procedure; I am looking for why it fails on this specific account.

And your comment about SetEnv actually raises a contradiction that I would like you to help me resolve: if this Apache module is not loaded on Webhosting offers and therefore SetEnv PHP_VERSION 8.5 in my .htaccess has no real effect, how can we explain that creneaux.php is running fine on PHP 8.5 today (as confirmed by the X-Powered-By header), in the same directory, with the same .htaccess? There must be another active configuration source on this account — and that is precisely what needs to be identified and harmonized across all files, not another attempt at .ovhconfig that fails with a 501.

Ticket CS16643535, open for 6 days, still without a direct human response. What I need is for an infrastructure technician to look at this specific account — not a rephrasing of the general documentation.

Thank you in advance.

Jérôme

I’ll take your ticket and look into it.

Hello @JeromeA26

I've already helped people who had issues with different PHP versions on their site.

The solution used:

  • Delete all .ovhconfig files in /www and all folders,
  • Via the OVH manager, change the PHP version several times: 8.0, then 8.1, 8.2, 8.3, 8.4 and finally 8.5

Indeed it was a problem with the location of the .ovhconfig file

This configuration file can be placed in subdirectories to change the PHP version (not the image), but a file must be present in the ./

If needed, documentation is available here: https://docs.ovh.com/fr/hosting/configurer-fichier-ovhconfig/

Have a nice rest of the day :slight_smile:

Hello @victor_webhosting_in,

Confirmation that the fix works: after moving the .ovhconfig to the root and switching through several PHP versions via the Manager (thanks @Gaston for the tip), the 5 scripts in the folder now all run on 8.5, consistently. The erratic behavior has disappeared.

Thanks for checking the account directly, that's exactly what was missing from the ticket for 6 days. I'm closing CS16643535 on my side.

Have a great rest of your day,

Jérôme