PHP

Symfony – Fehlermeldung (Prod Environment) 500 Internal Server Error

21. September 2016 Allgemein, Blog, Log, PHP, Symfony No comments , ,

Symfony Internal Server Error 500 Titelbild

Man freut sich vielleicht gerade eine Anwendung fertig gestellt zu haben, will diese nun Online bringen und plötzlich meldet sich ein 500 Internal Server Error.
Häufig kommt es vor, das sich die Bildschirmausgabe des Webprojektes in der Entwicklungsumgebung ( Dev Environment ) von der Produktiv-Umgebung (Prod Environment) unterscheidet.

Beim Entwickeln überprüft man die Anwendung z.B. via Webbrowser
http://localhost:8000/unterseite/artikel

wenn o.g. URL nun wie folgt erweitert wird:

http://localhost:8000/app.php/unterseite/artikel (entscheidend ist hierbei app.php)
kann getestet werden, wie sich die Anwendung mit Prod-Environment (Produktiveinsatz) verhalten würde. Ist optisch und funktional alles wie beim 1. Link, so ist dies ein gutes Zeichen und die Anwendung ist bereit Online zu gehen.

Warum verhalten sich beide Aufrufe unterschiedlich?

Dies kann zum einen auf die Anwendungskonfoguration zurückzuführen sein, welche ggf. für das Dev-Environment ausgelegt ist oder man nutzt innerhalb der Entwicklung Module von Symfony, die lediglich für den Entwicklungsprozess gedacht sind und live bzw. im Prod-Environment nicht zur Verfügung stehen.

Triviales Beispiel für die Erzeugung eines 500 Internal Server Error – kein dump im Prod

Beim Entwicklungsprozess wird ggf. des Öfteren auf die dump-Funktion von Symfony zurückgegriffen um sich Inhalte während der Datenverarbeitung anzeigen zu lassen.
Der Dump von Inhalten funktioniert hierbei sowohl aus einem Twig-Template oder auch über einen der Controller.
Dies ist für die Entwicklung sehr nützlich, jedoch für die online geschaltete Webanwendung sehr gefährlich. Angenommen die Dumps werden nicht entfernt (Vergesslichkeit), dann würden die Ausgaben einem zukünftigen Betrachter der Webanwendung interne Strukturen offen legen, also ein gefundenes Fressen für potentielle Angreifer. Daher steht die dump-Funktion nur im dev-Environment und nicht im prod-Environment zur Verfügung.

Symfony Prod Error Log – Informationen zum Fehlverhalten der Website auslesen

Angenommen die Live geschaltete Anwendung wirft nun ein 500 Internal Server Error oder andere Fehlermeldungen, so quittiert Symfony diese innerhalb eines Logfiles ( dieses findet man unter app/logs/ ).

Eine Eintrag aus dem Logfile könnte wiefolgt aussehen:
[2016-07-20 14:28:16] request.CRITICAL: Uncaught PHP Exception Symfony\Component\Debug\Exception\UndefinedFunctionException: „Attempted to call function „dump“ from namespace „AppBundle\EventListener“.“ at /home/micha/git/Simplicando/src/AppBundle/EventListener/ContentUpdateListener.php line 27 {„exception“:“[object] (Symfony\\Component\\Debug\\Exception\\UndefinedFunctionException(code: 0): Attempted to call function \“dump\“ from namespace \“AppBundle\\EventListener\“. at /home/micha/git/Simplicando/src/AppBundle/EventListener/ContentUpdateListener.php:27)“} []

Beim betrachten der Log-Line stößt man nun auf UndefinedFunctionException(code: 0): Attempted to call function \“dump\“. Dies bedeutet das ein Ausnahmefehler (Exception) geworfen wird weil die dump-Funktion nicht exisitert.

Was kann man gegen den Error machen?

Das zuvor gennante Beispiel zeigt, das Dumps in im Prod-Environment nicht funktionieren. Die Anwendung muss daher auf den Einsatz dieser Ausgaben geprüft werden. Entfernen / auskommentieren und erneut testen, ob der Internal Server Error bestehen bleibt.

Handelt es sich nicht um o.g. Szenario, so ist die Ursache so pauschal nicht zu ermitteln und benötigt ggf. Untersuchungen des Quellcodes oder der Konfiguration.
Zunächst ist es jedoch Sinnvoll sich einen Überblick über die Fehlermeldungen (HTTP-Status Codes) zu verschaffen. Eine Liste mit allen Status-Codes ist hier zu finden.

So kann das Problem zumindest schon mal grob eingegrenzt werden (z.B. Inhalt nicht gefunden Error 404 oder einer 500er Meldung). Weiterhin sollten die Error-Logs unter /app/logs (Symfony Nutzer) oder Log-Files Ihres Webservers betrachtet werden. Es ist erstaunlich, wie schnell man dem Fehler durch die Log-Files auf die Schliche kommt.

Literaturempfehlung für den Umgang und Erweiterung von Symfony

Werbeanzeige:
extending_symfony2
Extending Symfony 2 Web Application Framework
[Author: Sebastien Armand]

Symfony und Angular JS

12. September 2016 HTML, Javascript, Log, PHP, Symfony No comments , , , ,

Wer Symfony und AngularJS in einem Projekt nutzen will stößt schnell auf Probleme.
In diesem Beitrag möchten wir vor allem auf die grundlegenden Probleme eingehen welche aber relative schnell gelöst werden können.

Angular Expressions kollidieren mit Twig Template

AngularJS nutzt für den Zugriff auf Daten im Zwei-Wege-Databinding Ausdrücke in geschweiften Klammern.

1
2
<input type="text" ng-model="user.name" />
Hallo {{user.name}}!

Möchten wir nun dieses Beispiel innerhalb eines Symfony Projektes nutzen wird dieses Versuchen {{user.name}} mittels TWIG zu verarbeiten und einen Fehler ausgeben.
Um dieses Problem zu Umgehen verschachteln wir unseren für Angular zu verarbeitenden Ausdruck in ein weiteres paar doppelter geschweifter Klammern und in Anführungsstriche.
Damit gibt TWIG den Ausdruck aus, als wäre dieser ein einfacher String:

1
2
<input type="text" ng-model="user.name" />
Hallo {{'{{user.name}}'}}!

Nun wird unser kleines AngularJS Beispiel wie gewohnt verarbeitet ohne mit vorhandenem TWIG zu kollidieren

Inhalte beim Laden der Seite Ausblenden

Während die Seite lädt können möglicherweise Inhalte zu sehen sein welche per Controller in Angular ausgeblendet wurden. An diesem Punkt verarbeitet Angular den DOM erst nachdem alle Inhalte sichtbar sind und der Nutzer bekommt möglicherweise Formulare oder Modals zu sehen welche eigentlich später erscheinen sollen.
Zwar verschwindet dieser Inhalt nach dem Bruchteil einer Sekunde, wenn Angular geladen wurde, doch wir können mit einem kleinen Trick alles noch beim Laden der Seite Ausblenden.

Mit der Direktive ngCloak werden Angular Templates daran gehindert sichtbar zu sein bevor die Seite komplett geladen wurde. Damit lässt sich der eben beschriebene Flakkereffekt entfernen. In diesem Beispiel wird die Verwendung als Klasse oder Attribut gezeigt:

1
2
<div id="Meldung1" ng-cloak>Meldung 1: Als Attribut</div>
<div id="Meldung2" class="ng-cloak">Meldung 2: Als Klasse</div>

Werbeanzeigen: