Typische Fehler und Lösungen
Viele Entwickler kennen das Problem: Erst fliegt eine Exception und man denkt sich „Man, das kenne ich doch schon. Wie hatte ich das noch gleich gelöst?“, dann überlegt man meistens ewig und kommt eher durch einen Zufall wieder auf die Lösung. Hier mein Versuch einer Liste für typische Fehler und Lösungen.
Der Beitrag wird immer mal wieder erweitert werden, je nachdem, was mir so auffällt.
Letzte Aktualisierung: November 2019.
Installation eines Symfony Projekts
Nach der Installation auf die Produktivumgebung mit einem Symfony 3 Projekt mit php composer install --no-dev -o
kommt ein
Script cache:clear returned with error code 255 !! PHP Fatal error: Uncaught Symfony\Component\Debug\Exception\ClassNotFoundException: Attempted to load class "WebProfilerBundle" from namespace "Symfony\Bundle\WebProfilerBundle". !! Did you forget a "use" statement for another namespace? in /home/mobs.staging.ext02.srvpool.vcat.de/public_html/src/Kernel.php:47 !! Stack trace: !! ...
Lösungs-Möglichkeiten:
- Existiert in Quellcode oder den Templates noch irgendwo ein
dump()
?
Oder es kommt ein
Script cache:clear returned with error code 255 !! PHP Fatal error: Uncaught Symfony\Component\Debug\Exception\ClassNotFoundException: Attempted to load class "MakerBundle" from namespace "Symfony\Bundle\MakerBundle". !! Did you forget a "use" statement for another namespace? in /home/lima.ext02.srvpool.vcat.de/public_html/src/Kernel.php:47 !! Stack trace: !! ...
Lösungs-Möglichkeiten:
- Wir haben für das Handling der Umgebungsvariablen das Paket
symfony/dotenv
vomrequire-dev
dercomposer.json
in denrequire
Teil verschoben, um die.env
auch produktiv nutzen zu können. Hat man jetzt aber vergessen, die VariableAPP_ENV=prod
einzustellen, kommt dieser Fehler.
Vielleicht kommt auch ein
[RuntimeException] An error occurred when executing the "'cache:clear --no-warmup'" command: Fatal error: Uncaught Symfony\Component\Debug\Exception\ClassNotFoundException: Attempted to load class "SensioGeneratorBundle" from namespace "Sensio\Bundle\GeneratorBundle". Did you forget a "use" statement for another namespace? in /var/www/html/app/AppKernel.php:33 Stack trace: #0 /vendor/.../Symfony/Component/HttpKernel/Kernel.php(448): AppKernel->registerBundles() #1 /vendor/.../Symfony/Component/HttpKernel/Kernel.php(114): Symfony\Component\HttpKernel\Kernel->initializeBundles() #2 /vendor/.../Symfony/Bundle/FrameworkBundle/Console/Application.php(59): Symfony\Component\HttpKernel\Kernel->boot() #3 /vendor/.../Symfony/Component/Console/Application.php(122): Symfony\Bundle\FrameworkBundle\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #4 /bin/console(27): Symfony\Component\Console\Application->run(Object in /var/www/html/app/AppKernel.php on line 33
Lösungs-Möglichkeiten:
- Dieser Fehler kommt dann vor, wenn ein Paket von
Composer
deinstalliert wird, das eigentlich für die Ausführung der Seite notwendig ist. Ursache dafür ist vermutlich die Installation ohne das"require-dev": { ... }
, wobei in Symfony 3.* gerne mal vergessen wird, das Environment anzugeben:SYMFONY_ENV=prod composer install --no-dev -o
. - Manchmal ist auch einfach nur de Cache Ordner hinüber. Ein einfaches
rm -r var/cache/*
tut das nötigste.
Symfony unter PHP-FPM: Session-Handling
Nach einem Wechsel von PHP mit FCGI Unterstützung unter Virtualmin auf meinem Server zu PHP-FPM verlor meine Webseite nach ca. 30 Minuten die Nutzer-Session. Das Verhalten war schon sehr seltsam:
- Die Cookies waren weiterhin gültig,
- in sämtlichen Logs konnten kein Hinweise auf unnormales Verhalten gefunden werden,
- die Konfiguration von PHP-FPM oder der
php.ini
enthielt auch keine Unterschiede zu den vorhergehen Konfigurationen, - eine zusätzliche Implementierung eines „Remember-Me“ Token brachte keine Verbesserung und
- alle anderen Domains (mit WordPress oder KanBoard) liefen ohne Probleme und hielten ihre Session wie versprochen.
Nach langem Suche habe ich dann den Fehler in der Konfiguration von Symfony gefunden:
# config/packages/framework.yaml framework: session: handler_id: ~ cookie_lifetime: 0 cookie_secure: true
Die handler_id
auf Null zu setzen hat nur einen Vorteil während des Developments, um ggf. das Session-Handling zu testen, führt aber im produktiven Betrieb dazu, dass die Session unnötig früh verloren geht. Vermutlich wird sie vom „Garbage-Collector“ einfach irgendwann zufällig eingesammelt.
Entfernt man die Zeile einfach, nimmt Symfony wieder den Standard-Handler für das Speichern der Sessions im Dateisystem.
Das Verhalten scheint aber auch nur unter PHP-FPM aufzutreten, da ich von anderen Projekten weiß, die mit dem Test-Handler auf Virtualmin die Session halten.