So ging es mir auch, bis ich vor längerer Zeit mal zu einem Probearbeiten für einen neuen Job eingeladen war und es plötzlich hieß: “So machen wir das aber nicht mehr, das PHP-Tag wird nicht mehr geschlossen.”

Die Frage beschäftigte mich zu dem Zeitpunkt schon, warum das PHP-Tag am Dateiende nicht mehr geschlossen werden sollte. Ich habe es seit Jahren verwendet und es sind mir nie Nachteile durch die Verwendung aufgefallen. Warum nun also?

Es ist ja auch kein Fehler es zu Verwenden (maximal ein Verstoß gegen die Coding Standards), hilft aber, Fehler zu vermeiden, wenn man es weglässt.

Viele Projekte bestehen heute aus einer Vielzahl von PHP-Dateien und dank MVC über eine kontrollierte Ausgabe der Response.

Das bedeutet, dass wir in unserem Programm zu jeder Zeit die Header setzen können und diese dann erst mit dem kompletten Response gesendet werden.

Das funktioniert aber nur solange, wie noch nichts gesendet wurde und genau da liegt das Risiko des schließenden PHP-Tags.

Während ungewollte Zeichen zu Beginn der Datei relativ offensichlich sind, sind sie nach dem schließenden PHP-Tag unter Umständen quasi unsichtbar.

<?php
// irgendwelcher Code
?>

Denn sobald in irgendeiner Datei ein quasi unsichtbares Leerzeichen oder ein Zeilenumbruch dahinter folgt, werden, sofern die Ausgabe nicht gebuffert wird, auch schon die entsprechende Headerinformationen gesendet und wir würden im weiteren Verlauf unseres Programms wahrscheinlich eine Fehlermeldung zu sehen bekommen (“header already sent”).

Die entsprechende Stelle dann in mehreren hunderten oder oft sogar tausenden Dateien zu suchen wäre relativ zeitaufwendig und vor allem vermeidbar. Daher sollte auf die Verwendung verzichtet werden.

<?php
// irgendwelcher Code

Ein weiterer, noch gemeinerer, Fehler kann auftreten, wenn die Datei im Unicode gespeichert wurde. In dem Fall wird vor dem eigentlichen Dateiinhalt die Bytefolge “FE FF” (Byte Order Mark/BOM) gespeichert, die von PHP bereits auch schon als Ausgabe interpretiert wird.

Das tückische daran ist jedoch, dass man diesen Fehler nicht im normalen Editor zu sehen bekommt und ggf. mit einem Hex-Editor ran müsste.

Siehe auch:

• Abgrenzung von Anweisungen
• Zend Framework Coding Style