Wrong php path in shell

[k-webdesign]

I've got a Strato web hosting package without SSH and noticed a strange behaviour which I tried to solve with fritz.

The system check recognizes PHP8.1 and the correct cli path, as well:

Then I want to start a composer install (same for an update), but the shell just stopps at $ /opt/RZphp72/bin/php-cli -q -d max_execution_time=300 /mnt/web123/b1/64/590064/htdocs/contao/web/contao-manager.phar.php composer install --prefer-dist --no-dev --no-progress --no-suggest --no-ansi --no-interaction --optimize-autoloader

manager.json says: { "server": "strato", "latest_version": "1.6.1", "latest_requires": { "php": "^7.1.3 || ^8.0" }, "last_update": "2022-11-18T13:50:03+01:00" }

Then I tried to uncheck the composer cloud but for some reason the Manager reloads very fast after I click on the "change" button. But I made it somehow ...

After saving, the manager.json got extended with: { "server": "strato", "latest_version": "1.6.1", "latest_requires": { "php": "^7.1.3 || ^8.0" }, "last_update": "2022-11-18T14:53:06+01:00", "php_cli": "\/opt\/RZphp81\/bin\/php-cli", "disable_cloud": true }

So, the path is correct every where, but the shell still takes RZphp72 and the task won't start. I don't know if both problems are related or if the web hosting package has some misconfigurations, so the task can't start. But I'm very confused because of the cli path in the shell.

[mlwebworker]

Strato hat eigentlich in allen Paketen ssh-Zugang über ssh.strato.de und den SFTP/FTP-Hauptnutzer. Über weitere Nutzer funktioniert das nicht. Hast Du mal geschaut, ob es irgendwo im Pfad Deiner Installation eine .htaccess mit Einstellung auf php 7.2 gibt. Da man bei Strato für einzelne Domains die PHP-Version nur über die .htaccess einstellen kann bin ich da schon in etlichen übernommenen Installationen auf solche Dateien in den unterschiedlichsten Ebenen gestoßen.

[fritzmg]

Hast Du mal geschaut, ob es irgendwo im Pfad Deiner Installation eine .htaccess mit Einstellung auf php 7.2 gibt. Da man bei Strato für einzelne Domains die PHP-Version nur über die .htaccess einstellen kann bin ich da schon in etlichen übernommenen Installationen auf solche Dateien in den unterschiedlichsten Ebenen gestoßen.

That should not matter. The Contao Manager should always use the php_cli path defined in the manager.json (which seems to not be the case here).

[k-webdesign]

Strato hat eigentlich in allen Paketen ssh-Zugang

Not in this case. The package is an older one

[aschempp]

As far as I remember, the Contao Manager uses the path defined in the config file as the primary path to check for a CLI, but still falls back to any other found binary if the primary path does not exist (or is not the correct version).

This still does not explain to me why it would take PHP 7.2 though 🤷

[theDyingMountain]

I have a similar problem with hetzner. The Contao Manager didn't detect the path automatically, so I edit the manager.json to \/usr\/bin\/php81. The path exists, I can call it over SSH. But Contao Manager changes the path to /home/httpd/cgi-bin/php81.bin.fcgi which leads to a security error.

[theDyingMountain]

I think I've found the cause of the problem. On hetzner the warning _"Warning: JIT is incompatible with third party extensions that override zend_executeex(). JIT disabled. in Unknown on line 0" appears every time. So the output in https://github.com/contao/contao-manager/blob/cf11e5b915619d87305d9757037b4393ca8e6445/api/Process/PhpExecutableFinder.php#L94 isn't the expected and the RuntimeException will be thrown.

[ausi]

@theDyingMountain does the error go away if you execute it with this option: php -d display_startup_errors=0 ?

[theDyingMountain]

@ausi No, unfortunately not :/ I wrote Hetzner about the problem, maybe they can disable the warning.

[ausi]

How about php -d display_startup_errors=0 -d display_errors=0

[theDyingMountain]

@ausi Yes this works!

[theDyingMountain]

Hetzner fixed the problem, here is the answer. But maybe there is a better way to check the process output?

PHP8+ generiert diese Warnung, sobald opcache mit der Einstellung opcache.jit_buffer_size > 0 und eine weitere Zend Extension geladen ist, die zend_execute_ex() überschreibt - in Ihrem Falle XDebug. Normalerweise sollte eine Anwendung aufgrund einer PHP Warnung nicht komplett den Dienst versagen, wir haben aber trotzdem nun einen Workaround eingebaut, der automatisch opcache.jit_buffer_size auf 0 setzt (und den JIT Compiler ausschaltet), sobald XDebug aktiviert ist.