Webseite mit div container wird im IE nicht richtig dargestellt

[marctrix]

Hej Der Martin,

Wirft aber Sicherheitsfragen auf, die beantwortet werden möchten

Hatte ich auch schon dran gedacht. Aber solange man nur eine Handvoll includes verwendet, sehe ich da noch kein Risiko. Wenn man allerdings tiefer einsteigen möchte ...

Es reicht schon eine nicht aktuelle Version laufen zu haben.

das hat man als Hosting-Kunde aber nicht in der Hand - höchstens insofern, als man sich dann von einem Hoster verabschiedet.

Sag ich doch: Sicherheitsfragen um die man sich kümmern muss: Hosterwechsel (mit nachfolgendem DNS-bedingter Unerreichbarkeit der Seite für gefühlte 24 Stunden, vorher Unterschrift des Kunden einholen usw) oder eigenen Server betreiben mit nem Haufen Software, die aktuell gehalten werden muss usw

Dann ist man bald Frontender und Backender uns Sysadmin und Projektleiter - geht nicht gut!

Und alls nur, weil man den header und vielleicht noch die Navi nicht in jeder Seite drin haben will?

Mir wäre das zu viel Aufwand. Ich biete ja auch WP-Seiten an. Da hat man dann einen echten Mehrwert durch die Verwendung von php (dessen Vorteile ich schätze!), Hier aber scheint mir der Overhead in keinem Verhältnis zum "Gewinn".

Ich mache noch regelmäßig Seiten von der Hand für Kunden, von denen ich weiß, dass die selten oder nie neue Inhalte liefern.

und erzeugt eine langsamere Webseite. Nichts ist schneller als statisches HTML.

Ja. Aber im Verhältnis zur üblichen Latenz eines HTTP-Servers von zwei, drei Zehntelsekunden und mehr fällt das normalerweise nicht ins Gewicht.

Das ist mehr, als die meisten HTML-Seiten benötigen, um geladen zu werden.

Nein, das ist die Ladezeit einer x-beliebigen HTTP-Ressource. An meinem heimischen DSL-Anschluss liegen die ping-Antwortzeiten je nach Host so bei 30..50ms, aber die Wartezeit auf eine HTTP-Antwort liegt typischerweise bei 300..500ms, was sowohl Wireshark, als auch die Entwicklertools der Browser zeigen. Unabhängig vom Rechner, vom verwendeten Browser, sogar unabhängig vom Betriebssystem.
Schlussfolgerung: Die Ursache für die Verzögerung liegt "da draußen". Die Netzwerk-Infrastruktur kann's nicht sein, dann würden Pings auch länger brauchen, bleibt also nur der Server da draußen, denn wenn ich mit meinem Apachen im LAN rede, liegen die Antwortzeiten unter 100ms.

Mir ging es um die Skript-Laufzeit, die hinzu kommt. Hatte mich schon gewundert, dass die so lange sein soll bei einfachen include. - Hast du dazu interesshalber eine Zahl? Eine WP-Seite kommt deutlich spürbar langsamer als eine statische Seite. Belastbareres kann ich jetzt aus dem Kopf nicht liefern. Nur zur Info vorab: Mir ist klar, dass hinter einer WP-Seite deutlich mehr als ein include abzuarbeiten ist... ;-)

Also verändert sich die Ladezeit um 200 bis 300 Prozent - zum schlechten!

Nein, der zusätzliche Zeitbedarf durch PHP geht in der HTTP-Verzögerung komplett unter.

OK, muss ich so glauben. - Klingt auch plausibel.

Ich habe nur ein PHP-Script als Hauptdokument, das das gesamte Seitengerüst erzeugt, variable Stellen (Seitentitel) dynamisch ersetzt und den eigentlichen Inhalt per include einfügt.

Macht für komplexe Sites ja auch Sinn, wenn man sich um die Navigation z. B. gar nicht mehr kümmern möchte, sondern das Dateisystem ausliest und die Ordnerstruktur automatisch in die Navigation übertragen lässt.

Nicht das Dateisystem, sondern eine Konfigurationsdatei. Aber das läuft auf dasselbe raus.

Iiieh - Handarbeit! ;-)

Aber im Ernst: wenn man eine solche auch noch pflegen muss, wäre es dann nicht einfacher gewesen, man hätte header und navi im HTML gelassen?

Marc