KeyHelp Community

Salute

Es wäre super - gerade aus zwei Applikationsfällen heraus - wenn die CLI Version ebenfalls einzeln zu definieren wäre. Was ja schon funktioniert ist, dass die PHP Version pro Domain auf Webserver definiert werden kann (Domain > Bearbeiten > PHP-Interpreter).

Zudem wäre es noch sehr gut, wenn die PHP CLI Version für den Benutzer / Domain definierbar ist.

Dies läuft gerade aus zwei Applikationen heraus, mit denen ich das Problem habe, dass sie halt auch auf der CLI PHP8.1 brauchen (Laravel). Ich kann 8.1 aber nicht einfach systemwide setzen (wobei ich es dann auch nur als Webserver systemwide setzen würde), da auf dem Keyhelp Server natürlich auch noch andere Applikationen / Web-Instanzen laufen.

Cherrs
Toorms

Da man das nirgends einstellen kann, jedenfalls kenne ich keinen Server oder Webhosting mit mehr als einer PHP-Version wo man das kann, und da weiterhin Laravel relativ weit verbreitet ist, gehe ich eigentlich davon aus, dass es da keine unlösbaren Probleme geben wird. Z.B. weiss ich, dass bei netcup im Webhosting Laravel Anwendungen laufen, obwohl man dort mehrere PHP-Versionen zur Auswahl hat und die PHP-CLI Version NICHT pro User/Domain einstellen kann. PHP 8.1 ist ja auch der CLI vefügbar, nur halt nicht einfach als "php" aufrufbar. Um welche Anwendungen handelt es sich denn? Ich kenne Hostingumgebungen, da rufst du mit php die Version 4.schlagmichtot auf. Trotzdem laufen da Laravel und Symfony-Anwendungen.

In meinem expliziten Fall handelt es sich um InvoiceNinja und Akaunting.

Hallo,

wie im anderen Thread schon von dem ein oder anderen Benutzer erwähnt: Es gibt ja die folgenden Binaries, sofern diese installiert wurden.
Wenn damit die Anwendung gestartet wird läuft sie auch unter der angegebenen Versionsnummer.

Wenn diese Anwendungen die PHP-Version aber nicht in der Lage ist, die Version korrekt zu ermitteln, da sie statt der Konstanten PHP_VERSION, PHP_MAJOR_VERSION, usw. oder phpversion(), dann lieber exec("php -v") benutzen, liegt die Ursache in der Anwendung und nicht im KeyHelp.

Bei den Herstellern der Anwendung sollte dann eher nachgefragt werden, warum die Version nicht korrekt ermittelt werden kann.

Ich sehe hier kein Problem oder Handlungsbedarf beim KeyHelp.

Also ich wäre mir gar nicht mal so sicher, ob das überhaupt technisch machbar ist. Per Domain sicher nicht, denn von der Domain weiß die CLI nichts, die spielt da keine Rolle (hatte doch jemand schon im Schwesterthread ausgeführt).

Per User: mag sein, aber doch eher auch nur über die Symlink-Geschichte, per CLI wird ja immer ein Binary aufgerufen und wenn das System-PHP vorne im Pfad ist, wird es immer das sein. Es muss als ein Symlink sein und der Pfad zu diesem Symlink muss ganz vorne im $PATH stehen. Das wiederum müsste dann doch auch manuell gehen.

Ich habe ähnlich wie tab-kh auch noch nie einen Provider gesehen, wo man mehr als eine PHP-Version für CLI haben kann (allerdings viele, wo es - wie bei Keyhelp - entweder über andere Namen oder über einen anderen Pfad andere PHP-Versionen aufrufen lassen).

Ich würde die Verantwortung da in der Tat eher auch bei den Entwicklern der entsprechenden Anwendung sehen - ruft man PHP per "exec" oder was auch immer auf, ist es ja kein Hexenwerk, davor noch einen entsprechenden Pfad zu setzen, um das passende Binary zu nehmen. Und diesen Pfad konfigurierbar zu machen ist dann sehr leicht

Es wäre es für die Anwendung ein leichtes, statt:
Das hier aufzurufen - Und zack, fertig!

Ob es nun um den "-v" Parameter oder Sonstiges geht, spielt ja keine Rolle.

Alexander wrote: ↑Wed 10. Aug 2022, 09:22 Es wäre es für die Anwendung ein leichtes, statt:

Code: Select all

exec('php -v');

Das hier aufzurufen - Und zack, fertig!

Code: Select all

exec(escapeshellarg(PHP_BINARY).' -v');

Ob es nun um den "-v" Parameter oder Sonstiges geht, spielt ja keine Rolle.

Akaunting: https://github.com/akaunting/akaunting/ ... r.php#L114 - macht es scheinbar schon so.
InvoiceNinja: habe ich soweit nichts gefunden.

Aber wie weit ändern sich das für mich? Also muss von meiner Seite denn noch was gemacht werden? Beide Anwendungen merken an, dass CLI 8.1 nicht installiert / vorhanden sei.

Merkt es nur an, oder hat es praktische Auswirkungen? Wünschen kann sich eine Software ja viel, aber ob es das wirklich braucht ist noch einmal eine andere Frage (und PHP 8.1 auf der CLI als Standard dürfte egal bei welchem Provider sehr, sehr exotisch sein - dazu ist das zu neu).

An Laravel kann es dann übrigens nicht liegen, das hat als Mindestvoraussetzung in der aktuellen 9.x-Version PHP 8.0

@Toorms

Schau dir mal die verlinkte Funktion an.
Er kommt garnicht erst zu der Stelle springt vorher zu einer anderen Funktion.
Deswegen kann es somit auch nicht korrekt ermitteln werden.

mhagge wrote: ↑Wed 10. Aug 2022, 10:37 Merkt es nur an, oder hat es praktische Auswirkungen? Wünschen kann sich eine Software ja viel, aber ob es das wirklich braucht ist noch einmal eine andere Frage (und PHP 8.1 auf der CLI als Standard dürfte egal bei welchem Provider sehr, sehr exotisch sein - dazu ist das zu neu).

An Laravel kann es dann übrigens nicht liegen, das hat als Mindestvoraussetzung in der aktuellen 9.x-Version PHP 8.0

Nein, sie brauchen es beide wirklich. Akaunting lässt sich gar nicht erst installieren ohne und Invoiceninja besteht bislang auch drauf lt. Entwicklern. Invoiceninja funktioniert aktuell zum Glück noch, aber ich will es auch nicht herausfordern.

Alexander wrote: ↑Wed 10. Aug 2022, 10:57 @Toorms

Schau dir mal die verlinkte Funktion an.
Er kommt garnicht erst zu der Stelle springt vorher zu einer anderen Funktion.
Deswegen kann es somit auch nicht korrekt ermitteln werden.

Also Fehler / Unlogik im Programmcode?

Naja, in der Funktion find() ist alles nach
überflüssig und wird niemals zur Ausführung kommen (also so ziemlich alles in der Funktion).

In getPHPPath() wird der Wert der Umgebungsvariablen APP_PHP_PATH abgefragt und zurückgegeben, nur wenn diese leer sein sollte erfolgt noch eine weitere Prüfung - und siehe da für cpanel ist da auch noch eine Unterscheidung zwischen verschiedenen PHP-Versionen.

An der Stelle sollte man aber ansetzen können - ergänze mal die .env-Datei im Root der Anwendung um APP_PHP_PATH=/usr/bin/keyhelp-php81 (ggf. APP_PHP_PATH="/usr/bin/keyhelp-php81", da bin ich gerade überfragt)

mhagge wrote: ↑Wed 10. Aug 2022, 11:41 An der Stelle sollte man aber ansetzen können - ergänze mal die .env-Datei im Root der Anwendung um APP_PHP_PATH=/usr/bin/keyhelp-php81 (ggf. APP_PHP_PATH="/usr/bin/keyhelp-php81", da bin ich gerade überfragt)

Die Idee ist ziemlich cool und hat auch mit nem kleinen Umweg geklappt.

1. Akaunting Installationsdateien entpacken
2. .env händisch anlegen, da aktuell nur .env.example vorhanden ist
3. In die .env "APP_PHP_PATH=/usr/bin/keyhelp-php81" packen + speichern
4. Installer F5, siehe da, es geht weiter

Großes Dankeschön!

Gerne!

Mit der .env-Datei können Umgebungsvariablen gesetzt werden, das ist der Hintergrund. Sie dienen in Symfony oder Laravel-Apps (und sicher in dem einen oder anderen Framework auch noch) quasi als Konfigurationsdatei - das vielleicht als Hintergrund