Typische Fehler + 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.

Naja, oder man schaut einfach in diesen Beitrag und findet hoffentlich schneller 😉

Der Beitrag wird immer mal wieder erweitert werden, je nachdem, was mir so auffällt.
Letzte Aktualisierung: 3. September 2018.

Installation eines Symfony Projekts

Nach der Installation auf die Produktivumgebung mit php composer install --no-dev -o kommt ein

Lösungs-Möglichkeiten:

  • Existiert in Quellcode oder den Templates noch irgendwo ein dump() ?

Oder es kommt ein

Lösungs-Möglichkeiten:

  • Wir haben für das Handling der Umgebungsvariablen das Paket symfony/dotenv vom require-dev der composer.json in den require Teil verschoben, um die .env auch produktiv nutzen zu können. Hat man jetzt aber vergessen, die Variable APP_ENV=prod einzustellen, kommt dieser Fehler.

Vielleicht kommt auch ein

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.

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:

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.

Kommentar hinterlassen

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