Composer liefert Fehlermeldung wegen falscher PHP-Version

Composer liefert Fehlermeldung wegen falscher PHP-Version

Beim Installieren eines Drupal-Paketes via git-Repository und Composer auf einem neu aufgesetzten Server kam beim Aufruf von "composer install" diese Fehlermeldung:

composer install error this package requires php 7.0 but your PHP version does not satisfy that requirement

Die Ursache war ganz einfach: Das Drupal-Paket lief bisher auf einem Server, der mit PHP 7.0.33 arbeitete. Auf dem neuen Server war zwar für den Apache-Webserver ebenfalls 7.0.33 eingestellt, aber wenn man PHP über die Kommandozeile (CLI) nutzte (was beim Aufruf des Composers ja der Fall ist), war die Version 7.3 voreingestellt.

In der composer.json Datei gibt es einen Eintrag, der angibt bis zu welcher PHP-Version das Paket sicher läuft. Der Eintrag sieht z.B. so aus:

  "require": {
    "php": "7.0.x",
    "composer/installers": "^1.2",
    "cweagans/composer-patches": "^1.6",

Der Eintrag in der zweiten Zeile gibt die PHP-Version an. Ruft man Composer mit einer höheren Version auf, kommt die oben erwähnte Fehlermeldung. Dieses Problem lässt sich auf verschiedene Arten lösen.

  1. Man stellt die PHP-Version auf der Kommandozeile auf die vom Composer erwartete Version 7.0 um. Dazu muss man nur wissen, wo die PHP-Pakete im Dateisystem zu finden sind. Im Zweifel hilft hier der Support des Hosting-Providers weiter. In unserem Beispiel liegen die verschiedenen PHP-Versionen unter /usr/bin/. Praktischerweise sind sie bei unseren Servern mit symbolischen Links erreichbar, was den Alias verkürzt. Um nun eine bestimmte PHP-Version zu nutzen, wenn man Composer über die Kommandozeile aufruft, legt man in der .bashrc-Datei einen neuen Aliaseintrag an. Das sieht dann beispielsweise so aus:

    alias php="/usr/bin/php70"
    alias composer="php /usr/home/[useraccount]/composer"

    Dabei ersetzt man "[useraccount]" durch den gültigen Pfad, der zum Account gehört, mit dem man eingeloggt ist und wo der Composer installiert ist. Die genaue Verzeichnisstruktur kann von Server zu Server unterschiedlich sein. Auch hier sollte der Support weiterhelfen können. Nach dem Speichern von .bashrc muss man sich entweder einmal aus der SSH-Konsole ausloggen und neu anmelden oder die Datei neu einlesen. Das geht ganz einfach mit

    source ~/.bashrc

    Ab jetzt wird bei Aufruf von php die Version 7.0.33 genommen und "composer install" läuft ohne Fehlermeldung durch.

  2. Möglichkeit: Man weißt Composer an, die Angaben zur PHP-Version zu ignorieren. Das ist z.B. sinnvoll, wenn man die CLI-Version von PHP nicht umstellen möcht, weil man plant, die Drupal-Installation künftig mit einer neueren PHP-Version laufen zu lassen und dies jetzt testen möchte. Dazu ruft man den composer mit dem Parameter "--ignore-platform-reqs" auf. Also so:

    composer install --ignore-platform-reqs'

    Dann sollte natürlich die Einstellung der PHP-Version, die vom Webserver verwendet wird, mit der Version auf der Kommandozeile identisch sein. Ist die Installation erfolgreich durchgelaufen, kann man die Seite testen. Läuft alles fehlerfrei, sollte man jetzt noch den Schritt 3 durchführen, damit die geänderte Einstellung der PHP-Version auf im git-Repository landet.
     

  3. Möglichkeit: Man ändert die zulässige PHP-Version in der composer.json Datei. Anschließend kann "composer install" (aber auch "composer update") problemlos ausgeführt werden. Die geänderte composer.json Datei committed man zum Schluss noch in das git-Repository. Ein "composer update" ändert übrigens nichts an den installierten PHP-Versionen.

    "require": {
    "php": "7.3.x",
    "composer/installers": "^1.2",
    "cweagans/composer-patches": "^1.6",

Wichtig: Generell sollten die PHP-Versionen der Kommandozeile und die des Webservers identisch sein. Der Eintrag in der composer.json dient nur der Information, bis zu welcher PHP-Version das Paket getestet ist. Setzt man die Version hoch - hier z.B. von 7.0 auf 7.3 - so sollte man das ganze auch getestet haben. Läuft irgendein Drupal-Teil nicht mit PHP7.3 führt das sonst über kurz oder lang zu Problemen und der nächste, der das git-Repository verwendet fängt sich die Probleme ebenfalls ein.