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

Angenommen, über ein Formular sollen die Stammdaten von Kunden bearbeitet werden und wir wollen dem Bearbeiter das Leben etwas leichter machen, indem er nach dem Speichern der Daten direkt die nächste Aktion ausführen kann ohne sie in der Navigation zu suchen.

In unserem Fall könnten die Aktionen z.B. ‘speichern’, ‘speichern und zur Liste’ und ‘speichern und neu anlegen’ sein.

Erstmal brauchen wir ein gewöhnliches Affenformular mit den gewünschten Eingabefeldern:

<form action="machwas" method="post">
  // ein paar Felder
  <input type="submit" value="speichern">
</form>

Soweit, so gut. Bislang ein ganz gewöhnliches Formular. Doch wie steuern wir denn nun was nach dem Absenden passieren soll? Ganz einfach, wir geben dem Formular noch ein paar Buttons und benennen diese.

<form action="machwas" method="post">
  // ein paar Felder
  <input type="submit" value="speichern" name="btnSave">
  <input type="submit" value="speichern und zur Liste" name="btnSaveList">
  <input type="submit" value="speichern und neu anlegen" name="btnSaveNew">
</form>

Für diesen Zweck habe ich mir angewöhnt, den Namen das Prefix ‘btn’ zu geben, damit sie besser zuordenbar sind.

Was passiert nun? Durch die Benennung der Buttons wird deren Wert (value) mit den andere Werten übertragen und wir können serverseitig damit arbeiten.

Theoretisch hätte ich auch alle Buttons gleich benennen können und hätte dann mit dem jeweiligen Wert weiter arbeiten können, aber dieser wäre nicht zuverlässig nutzbar. Dazu etwas später mehr.

Natürlich brauchen wir auch noch eine Auswertung für unser Formular:

<?php
// Daten prüfen, speichern und weiterleiten, wenn alles geklappt hat...

if(isset($_REQUEST['btnSave'])) {
  // ...und wieder auf das Formular weiterleiten (mit Daten anzeigen)
} else if(isset($_REQUEST['btnSaveList'])) {
  // ...und zur Liste weiterleiten
} else if(isset($_REQUEST['btnSaveNew'])) {
  // ...und wieder auf das Formular weiterleiten (ohne Daten anzeigen)
}

Das Beispiel funktioniert auch mit anderen Sprachen, müsste dann aber natürlich an die Syntax angepasst werden. Persönlich finde ich nach einem POST-Request einen HTTP-Redirect ganz nützlich.

Nun noch kurz die Aufklärung, warum ich die Namen der Buttons auswerte. Es ist einfacher, da der Name sich in der Regel nicht verändert, jedoch evtl. die Beschriftung und somit der Wert, wenn die Anwendung mehrsprachig programmiert ist.

Ich hoffe, dass es vielleicht dem Einen oder Anderen hilft, auch wenn es eigentlich zu den Basics gehört. Viel Spaß beim Ausprobieren!