Probleme beim Veröffentlichen eines Kirby CMS-Projekts mit Laravel Forge

Für das Hosting einiger Websites und Web-Anwendungen nutze ich Laravel Forge. Laravel Forge macht das Bereitstellen und Konfigurieren eines Webservers (oder alternativ Datenbankservers, Loadbalancers, etc.) relativ einfach und übernimmt viele wiederkehrende Aufgaben selbst.

Vor einigen Tagen hatte ich jedoch einige Probleme, als ich ein Kirby CMS-Projekt, das auf dem lokalen Entwicklungsserver problemlos funktioniert hat, auf den produktiven Server (bereitgestellt via Forge) veröffentlicht habe. Statt der gewünschten Website erschien nur eine 500er HTTP-Fehlermeldung.

Glücklicherweise kann man bei Forge relativ einfach die NGINX-Konfiguration einer gewünschten Website einsehen. In der Config ist ein Eintrag ähnlich dem folgenden Eintrag zu finden:

error_log  /var/log/nginx/beta.example.com-error.log error;

Aus diesem Grund habe ich mir per SSH das Log-File angesehen und dort folgende Fehlermeldung entdeckt:

2021/10/31 16:40:33 [error] 33603#33603: *624 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Cannot redeclare go() in /home/my-example-project/beta.example.com/kirby/config/helpers.php on line 228" while reading response header from upstream, client: 176.53.216.233, server: beta.example.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php8.0-fpm-my-example-project.sock:", host: "beta.example.com"

Relevant ist der Teil PHP Fatal error: Cannot redeclare go() in […]/kirby/config/helpers.php.

In der Dokumentation des Kirby CMS ist folgender Eintrag zu finden. Dort heißt es, dass es zu Problemen mit dem Swoole Framework kommen kann und das Framework daher entfernt werden soll.

Um herauszufinden, ob das Swoole Framework auf dem Server vorhanden war, habe ich im Projektverzeichnis eine Datei info.php mit folgendem Inhalt abgelegt:

<?php
phpinfo();

Ruft man anschließend die Datei über den Browser auf, dann erscheint die Auskunftsseite der aktuell konfigurierten PHP-Version. Dort war tatsächlich das Swoole Framework aufgeführt.

Auch der Befehl ls -l /etc/php/8.0/mods-available/ (ausgeführt als forge-User mit sudo-Rechten) listete Swoole auf:

-rw-r--r-- 1 root root  72 Jul  1 15:26 bcmath.ini
-rw-r--r-- 1 root root  74 Feb 23  2021 calendar.ini
-rw-r--r-- 1 root root  71 Feb 23  2021 ctype.ini
-rw-r--r-- 1 root root  68 Jul  1 15:26 curl.ini
-rw-r--r-- 1 root root  66 Jul  1 15:26 dom.ini
-rw-r--r-- 1 root root  70 Feb 23  2021 exif.ini
-rw-r--r-- 1 root root  69 Feb 23  2021 ffi.ini
-rw-r--r-- 1 root root  74 Feb 23  2021 fileinfo.ini
-rw-r--r-- 1 root root  69 Feb 23  2021 ftp.ini
-rw-r--r-- 1 root root  64 Jul  1 15:26 gd.ini
-rw-r--r-- 1 root root  73 Feb 23  2021 gettext.ini
-rw-r--r-- 1 root root  66 Jul  1 15:26 gmp.ini
-rw-r--r-- 1 root root  71 Feb 23  2021 iconv.ini
-rw-r--r-- 1 root root 364 Oct 12  2020 igbinary.ini
-rw-r--r-- 1 root root  21 Jul 27 11:14 imagick.ini
-rw-r--r-- 1 root root  68 Jul  1 15:26 imap.ini
-rw-r--r-- 1 root root  68 Jul  1 15:26 intl.ini
-rw-r--r-- 1 root root  76 Jul  1 15:26 mbstring.ini
-rw-r--r-- 1 root root 176 Feb 20  2021 memcached.ini
-rw-r--r-- 1 root root  74 Feb 20  2021 msgpack.ini
-rw-r--r-- 1 root root  71 Jul  1 15:26 mysqli.ini
-rw-r--r-- 1 root root  72 Jul  1 15:26 mysqlnd.ini
-rw-r--r-- 1 root root  79 Jul  1 15:26 opcache.ini
-rw-r--r-- 1 root root  69 Feb 23  2021 pdo.ini
-rw-r--r-- 1 root root  74 Jul  1 15:26 pdo_mysql.ini
-rw-r--r-- 1 root root  74 Jul  1 15:26 pdo_pgsql.ini
-rw-r--r-- 1 root root  77 Jul  1 15:26 pdo_sqlite.ini
-rw-r--r-- 1 root root  70 Jul  1 15:26 pgsql.ini
-rw-r--r-- 1 root root  70 Feb 23  2021 phar.ini
-rw-r--r-- 1 root root  71 Feb 23  2021 posix.ini
-rw-r--r-- 1 root root  76 Jul  1 15:26 readline.ini
-rw-r--r-- 1 root root  19 Jul 27 11:14 redis.ini
-rw-r--r-- 1 root root  71 Feb 23  2021 shmop.ini
-rw-r--r-- 1 root root  72 Jul  1 15:26 simplexml.ini
-rw-r--r-- 1 root root  68 Jul  1 15:26 soap.ini
-rw-r--r-- 1 root root  73 Feb 23  2021 sockets.ini
-rw-r--r-- 1 root root  74 Jul  1 15:26 sqlite3.ini
-rw-r--r-- 1 root root  34 Jun  4 21:27 swoole.ini # <----- HIER
-rw-r--r-- 1 root root  73 Feb 23  2021 sysvmsg.ini
-rw-r--r-- 1 root root  73 Feb 23  2021 sysvsem.ini
-rw-r--r-- 1 root root  73 Feb 23  2021 sysvshm.ini
-rw-r--r-- 1 root root  75 Feb 23  2021 tokenizer.ini
-rw-r--r-- 1 root root  66 Jul  1 15:26 xml.ini
-rw-r--r-- 1 root root  72 Jul  1 15:26 xmlreader.ini
-rw-r--r-- 1 root root  72 Jul  1 15:26 xmlwriter.ini
-rw-r--r-- 1 root root  66 Jul  1 15:26 xsl.ini
-rw-r--r-- 1 root root  66 Jul  1 15:26 zip.ini

Um das Swoole Framework zu deaktivieren reicht normalerweise der Befehl phpdismod swoole. Da ich auf dem Server jedoch mehrere PHP-Versionen nutze, muss in diesem Fall die konkrete PHP-Version angegeben werden. Das Statement muss daher – in meinem Fall für PHP 8.0 – angepasst werden:

phpdismod -v 8.0 swoole

Anschließend kann man über Laravel Forge PHP-FPM auf dem Server neu starten. Nach dem Neustart von PHP funktionierte die Kirby CMS-Seite wie gewünscht, das Problem war behoben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert