KeyHelp Community

Irgendwie verzweifele ich immer mehr an Keyhelp. Schade dass das Team 2023 immer noch auf die veraltete Version, wie sie es selber im Dashboard auch angeben, PHP 7.4 setzen. Da könnte ich langsam im Kreis brechen.

Es wird doch wohl möglich sein das ihr mal die Systemversion wenigstens auf PHP8.0 raufsetzt?

Okay zu meinem Problem:

Ich kann composer install nicht ordentlich ausführen, da gewisse Packages im Jahr 2023 verständlich nun mal eine Minimumanforderung von PHP8.0 haben.

Hat jemand eine Idee wie ich es hinbekomme, ohne den ganzen Kundenstamm auf Plesk umzuziehen, dass ich Composer wieder richtig nutzen kann?

Nur als Hinweis: die Systemversion ist die Standard-PHP-Version, die Deine Linux-Distribution als Standard mitbringt (deswegen ja auch Systemversion). Die nutzt Keyhelp für sich selber (was durchaus schlau ist, denn das Ändern einer solchen PHP-Version kann diverse Probleme mit sich bringen), irgendwas dran verändern tut Keyhelp aber nicht, weil das dann andere Dinge wieder durcheinander bringen könnte (die Distribution selber verlässt sich ja z.B. drauf, dass diese PHP-Version genutzt wird). Beschwerden darüber also eher an die entsprechende Distribution (oder falls ein Update der Distribution möglich ist ein Update der Distribution - wird aber nicht in jedem Fall möglich sein, Debian 11 z.B. ist die aktuellste Debian-Version, bringt aber PHP 7.4 als Systemversion mit. Gab es seinerzeit auch recht viel Diskussion bei den Debian-Entwicklern zu).

Wenn Du zusätzliche PHP-Versionen willst, lassen diese sich in Keyhelp unter Einstellungen -> Konfiguration -> PHP-Interpreter installieren (das geht rauf bis 8.3).

Auf der Shell lassen sich diese zusätzlichen Interpreter z.B. mit keyhelp-php81 (für Version 8.1) nutzen. Kann etwas tricky mit Scripten sein, aber generell lässt sich damit auch Composer aufrufen

Svenskanda wrote: ↑Mon 10. Apr 2023, 16:05 Irgendwie verzweifele ich immer mehr an Keyhelp. Schade dass das Team 2023 immer noch auf die veraltete Version, wie sie es selber im Dashboard auch angeben, PHP 7.4 setzen. Da könnte ich langsam im Kreis brechen.

Es wird doch wohl möglich sein das ihr mal die Systemversion wenigstens auf PHP8.0 raufsetzt?

Ja, das ist in der Tat sehr ärgerlich, vor allem, weil KH alle anderen PHP Versionen eh selber baut.

Svenskanda wrote: ↑Mon 10. Apr 2023, 16:05 Okay zu meinem Problem:

Ich kann composer install nicht ordentlich ausführen, da gewisse Packages im Jahr 2023 verständlich nun mal eine Minimumanforderung von PHP8.0 haben.

Hat jemand eine Idee wie ich es hinbekomme, ohne den ganzen Kundenstamm auf Plesk umzuziehen, dass ich Composer wieder richtig nutzen kann?

Code: Select all

echo "8.2.1" > .php-version

in dem Verzeichnis, in dem auch die composer.json ist.

Und ein Binary mit dem Namen "php" mit der passenden Version im Pfad haben.

Ich habe dafür einen symlink in ~/bin angelegt.

Edit: nicht wundern, ich habe versehentlich den Beitrag editiert und nicht zitiert. Ich bitte um Entschuldigung - mhagge

Den Punkt mit keyhelp-php80 oder keyhelp-81 den bin ich auch schon nachgegangen, allerdings komme ich da nicht weiter, egal ob ich mit root oder mit den Keyhelp User per shell draufgehe. Zumal das für mich ehr nach einer PHP CLI aussieht.

Da stimmt was mit den Pfaden nicht, die Meldung erscheint sehr wahrscheinlich, auch wenn man das ganze "nur" mit php vorweg aufruft

composer.phar in das Hauptverzeichnis der entsprechenden Applikation legen und das dann mit keyhelp-php80 aufrufen sollte gehen

Ansonsten: composer selber braucht "nur" ein PHP ab 7.2.5, die zu installierenden Komponenten brauchen häufig ein neueres PHP - und dann weigert composer sich, diese zu installieren, wenn es selber mit einer niedrigeren PHP-Version aufgerufen wurde.

Kann man entweder mit dem Parameter

Code: Select all

--ignore-platform-reqs

oder aber durch ergänzen der composer.json der jeweiligen App mit (z.B.)

Code: Select all

"config": {
    "preferred-install": "dist",
    "platform": {
        "php": "8.0.0"
    }
}

umgehen, dann klappt es auch nur mit PHP, trotz der älteren PHP-Version auf der Shell

24unix wrote: ↑Mon 10. Apr 2023, 16:19 Ja, das ist in der Tat sehr ärgerlich, vor allem, weil KH alle anderen PHP Versionen eh selber baut.

haha genau ... jetz ist der Tag wieder gelaufen

Du könntest auch auf Ubuntu 22.04 upgraden. Dann hast Du PHP 8.1 als Systemversion.

Wenn Du Debian nutzt dann, musst Du noch auf Debian 12 warten. Bis dahin hat Unix24 ja schon eine Lösung gepostet.

Gruß Arne

Hej ich will mich erstmal über eure großzügige Unterstützung bedanken und habe es mal mit den binaries probiert- hat so weit geklappt, außer das ich hätte aufpassen müssen, das ich ./configure den Pfad mitgebe. Habe nach make install dann doch noch kurz viel geschwitzt, als ich php -v PHP8.0.28 gelesen habe

- schnell composer ausgeführt und php aus /usr/local/bin wieder gelöscht. Neustart. I.O. Das nächste Mal dann richtig.

Aber vorher will ich dann mal noch @mhagge seinen Vorschlag ausprobieren.

Danke

Warum der Umstand?

Hat das mit der .php-version nicht geklappt?

Svenskanda wrote: ↑Mon 10. Apr 2023, 16:05 Schade dass das Team 2023 immer noch auf die veraltete Version, wie sie es selber im Dashboard auch angeben, PHP 7.4 setzen. Da könnte ich langsam im Kreis brechen.

Da könnte ich im Kreis brechen, wenn Leute, die nicht einmal das absolute Basiswissen (PHP 7.4 ist nun mal die Standardversion von Debian 11...Das ist ein Fakt!) beherrschen, sich dann hier großfressig hinstellen und das Entwicklerteam verbal angreifen und den Entwicklern mehr oder weniger Unfähigkeit unterstellen!
Und nachdem man diesem oberschlauen Dunning Spezi die Fakten erklärt hat, hat er es nicht einmal nötig, sich für seine verbale Entgleisung gegenüber den Entwicklern zu entschuldigen!
Ja, da könnte ich im Kreis brechen!

Jolinar wrote: ↑Mon 10. Apr 2023, 19:24 (PHP 7.4 ist nun mal die Standardversion von Debian 11...Das ist ein Fakt!)

Und dann ist es in Stein gemeisselt, dass man die verwenden muss?
Sury, der die Pakete für Debian baut, macht auch alle anderen Versionen. Auch die 8er für Ubuntu.

P.S. PhpMyAdmin war in Debian 11 bei Erstveröffentlichung offiziell nicht enthalten, nur Adminer. Trotzdem bietet KeyHelp PhpMyAdmin an.

Gerade bei einem Hosting-Panel sollte man in Sachen PHP schon mit der Zeit gehen.
Wir haben nicht mehr die 90er wo die Leute ZIP-Files auf ihrem Windows entpacken, und dann per FTP-Client in den "Webspace" laden.

Heute deployed man mit Composer und git.
Composer (und auch das Symfony CLI-binary) sind ein PITA, wenn man aktuelle Software mit PHP 7.x einsetzen willmuss.

Es sind regelmäßig Workarounds nötig, um aktuelle Workflows unter Keyhelp abbilden zu können.

Kann man (leicht umzusetzende) Verbesserungsvorschläge nicht einfach als das nehmen, was sie sind?

KeyHelp läuft unter PHP 8. Auf Ubuntu.
Also sollt es nicht super schwer sein, dass auch unter Debian hinzubekommen.

Gerade weil KeyHelp schon jetzt selber die Möglichkeit hat, alle PHP-Versionen zu bauen.

24unix wrote: ↑Mon 10. Apr 2023, 19:50 KeyHelp läuft unter PHP 8. Auf Ubuntu.
Also sollt es nicht super schwer sein, dass auch unter Debian hinzubekommen.

Eine Philosophie hinter KeyHelp ist die, das System möglichst nicht zu verändern, auf dem das Panel aufsetzt und alle spezifischen Anpassungen oberhalb der Systemebene vorzunehmen.
Sicher kann man da denken drüber, wie man will...ich persönlich halte die Entscheidung für richtig, denn so stellen die Entwickler auch sicher, daß das Panel in möglichst vielen Umgebungen fehlerfrei läuft.
Wer unbedingt PHP 8 als Systemstandard braucht, muß halt in den sudoer-Sumpf hinabsteigen.

Aber unabhängig davon gibt die Verwendung von Systemstandards niemandem das Recht, die Entwickler so anzugreifen...

Jolinar wrote: ↑Mon 10. Apr 2023, 19:57
24unix wrote: ↑Mon 10. Apr 2023, 19:50 KeyHelp läuft unter PHP 8. Auf Ubuntu.
Also sollt es nicht super schwer sein, dass auch unter Debian hinzubekommen.
Eine Philosophie hinter KeyHelp ist die, das System möglichst nicht zu verändern, auf dem das Panel aufsetzt und alle spezifischen Anpassungen oberhalb der Systemebene vorzunehmen.
Sicher kann man da denken drüber, wie man will...

Ja, das ist doch eine vernünftige Einstellung.
Probleme ansprechen, schauen, ob es Lösungswege gibt.

Der Ansatz, mit den Default des Systems zu arbeiten war ursprünglich sicher mal richtig.
PHP hat jahrelang nur minimale Updates erfahren, noch heute gibt es Frickeleien, die nur mit 5.4 laufen.

Seit es Composer gibt und durch Packagist.org dreht die PHP-Welt sich aber schneller, PHP 8.x brachte massive Verbesserungen, nicht nur syntax-candy.

Lange war es völlig OK, die gut abgehangen Versionen in Debian-Default zu nutzen, weil neue Versionen noch nicht wirklich weite Unterstützung erhielten.

Aber Zeiten ändern sich. Natürlich kenne ich den Code von KeyHelp (leider) nicht, aber wenn es unter Ubuntu mit 8.x läuft wird es keine Raketentechnik sein, dass auch unter Debian zu ermöglichen.

Es wäre schlicht eine qualitative Aufwertung des Panels, wenn man auch die systemweite default PHP-Version (in Grenzen, nicht 5.4 …) selber wählen könnte.

Jolinar wrote: ↑Mon 10. Apr 2023, 19:57
ich persönlich halte die Entscheidung für richtig.
Wer unbedingt PHP 8 als Systemstandard braucht, muß halt in den sudoer-Sumpf hinabsteigen.

Du hast snapd-Hölle vergessen

Ersten letztens eine Stunde im Slack mit einem unserer Juniors gehangen.
Klar, wenn man als normaler user pdftk "installiert" hat der dank Sandbox keine Rechte unter /var/www.
Aber auf die doofe Idee muss man erst mal kommen, dass die sogar ein Shell-tool als Snap verpacken.
Mit Debian wär das nicht passiert …

Jolinar wrote: ↑Mon 10. Apr 2023, 19:57 Aber unabhängig davon gibt die Verwendung von Systemstandards niemandem das Recht, die Entwickler so anzugreifen...

Ich sah das jetzt nicht wirklich als Angriff.

Und ganz ehrlich, ich hatte auch schon "unhappy"-Feelings in Bezug auf KeyHelp und der PHP-Version, gerade weil ich fürs private Entwickeln KeyHelp nutze, um dann in ein identisches System zu deployen.

Ich lese hier immer diverse Featurewünsche, einige sind mir egal, andere finde ich gut, wieder andere nicht so gut.
Aber für mich persönlich als Softwareentwickler wäre Wahlfreiheit des CLI-Interpreters ein absoluter Traum.

mir fällt zu manchen Antworten hier nur eines ein:

LTS und der Sinn dahinter wurden offenbar nicht verstanden. Mehr gibt es dazu nichts zu sagen

KeyHelp Community

composer install mit packages ^8.0

composer install mit packages ^8.0

Re: composer install mit packages ^8.0

Re: composer install mit packages ^8.0 [GELÖST]

Re: composer install mit packages ^8.0

Re: composer install mit packages ^8.0

Re: composer install mit packages ^8.0

Re: composer install mit packages ^8.0

Re: composer install mit packages ^8.0

Re: composer install mit packages ^8.0

Re: composer install mit packages ^8.0

Re: composer install mit packages ^8.0

Re: composer install mit packages ^8.0

Re: composer install mit packages ^8.0