HTML-Inhalte auslagern: PHP vs. SSI

Hat man als Webdesigner eines Internetauftritts konstante Parts, wie beispielsweise Navigationsleisten, Header oder Footer, so bleibt dem Gestalter zunächst die Qual der Wahl zwischen verschiedenen Methoden, um dies zu realisieren. Prinzipiell könnte man mit drei Techniken ein äquivalentes Resultat erzielen, das seinen Zweck als Homepage erfüllt:

  • Verwendung der Frametechnik (normale Frames oder Inlineframes)
  • Gestaltung jeder Seite mit Tabellen, konstante Inhalte müssten hier eigentlich auf jeder Seite extra eingefügt werden
  • DIV-Tags zur Positionierung von Inhalten: hier empfiehlt sich die Erstellung des Layouts (v.a. der DIV-Positionen) mit einer externen CSS-Datei, wobei die konstanten Inhalte hier ebenfalls manuell eingefügt werden müssten.

Entscheidet man sich (zumeist aus Gründen der Optik) gegen Frames und für eine der beiden Alternativen, so kann man die konstanten Inhalte auch auslagern und muss somit z.B. beim Hinzufügen eines Menüpunkts bei der Navigation nicht alle Seiten bearbeiten, sondern kann eine Datei erstellen, welche den HTML-Inhalt für die Navigationsleiste inne hat und bearbeitet fortan nur noch diese. Vom Prinzip her ist dies der Inlineframe-Technik ähnlich, nur dass mit den beiden gleich vorgestellten Methoden die ausgelagerten Inhalte beim Aufruf der Seite auf dem Server tatsächlich wieder fester Bestandteil der HTML-Datei werden, also nicht wie bei einem Inlineframe extern verknüpft sind. Ruft man also den Quelltext der Page auf, wenn man diese auf dem Server geöffnet hat, so wird man kein Anzeichen dafür finden, dass die Seite gerade erst „zusammengebastelt“ wurde und eigentlich aus Stücken besteht. Will man dies nun erreichen gibt es zwei relativ sichere Methoden, die – und das sei betont – jedoch nicht in Verbindung miteinander funktionieren, man sollte sich also für eine von beiden entscheiden.

SSI (Server Side Include) ist (wie PHP) eine serverbasierte Technik. Dies bedeutet, dass der Server, auf welchem die HTML-Datei ausgeführt wird, die HTML-Datei nach dem entsprechenden Befehl durchsucht und falls erforderlich Inhalte in die Datei includiert. Viele Server durchforsten Dateien allerdings nur, wenn diese die Endung *.shtm, *.shtml o.ä. haben. Voraussetzung ist generell auch, dass der Server SSI unterstützt und die Datei vom Browser über einen installierten Webserver vom Typ „http://“ aufruft – dies ist nicht selbstverständlich.

Beispiel: In die Datei index.shtml möchte ich ein Navigationsmenü eingliedern, welches ich via normalem HTML-Code (ohne head oder body, lediglich der Code des Menüs) in der Datei navi.html gespeichert habe. In die index.shtml setze ich nun an die Stelle, an welcher das Navigationsmenü erscheinen soll, folgendes Tag ein: < !-- #include virtual="navi.html" --> (vorausgesetzt, die Dateien befinden sich im selben Verzeichnis).

Genau dasselbe Ergebnis erzielt man mit dem PHP-Befehl readfile. Hier geht die Umsetzung mit Hilfe von PHP von statten, also muss die entsprechende HTML-Datei als PHP-Datei erkenntlich gemacht werden. In der Regel erkennt ein Webserver eine *.php-Datei als PHP-Datei an.

Beispiel: In die Datei index.php möchte ich wieder das Navigationsmenü einsetzen. An die entsprechende Stelle kommt nun folgendes Tag: < ?php readfile($_SERVER['DOCUMENT_ROOT'].'/navi.html'); ?>

Die PHP-Methode ist zwar (normal jedoch nicht merklich) langsamer als SSI, allerdings ratsam, sobald weitere PHP-Funktionen zum Einsatz kommen, da der Server nicht SSI und PHP gleichzeitig übersetzen kann. Eine einfache Faustregel also: sofern PHP vom Server unterstützt wird, empfiehlt sich fast PHP. Oft wird jedoch schon SSI und noch kein PHP unterstützt, insofern ist man über SSI sehr dankbar.

2 Gedanken zu „HTML-Inhalte auslagern: PHP vs. SSI“

  1. Pingback: meissnerc1
  2. weil du gefragt hast – sowas haben wir übrigens in e-business gelernt. allerdings kann ich mich an ssi nimmer erinnern – behandelt wurde insbesondere cgi,php und asp/jsp

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.