Generierung von Seiten

Das calladium® CMS beherrscht seit jeher das Generieren von Webseiten. So wurden in den Anfangstagen zB. HTML-Seiten für fremde Server generiert, die keine dynamischen Webseiten unterstützten. Diese wurden dann per FTP synchronisiert (Cross-System). Auch Offline-Dokumentation und Handbücher wurden so erzeugt.

Aber auch heute, wo man für wenig Geld Server mit PHP-Unterstützung mieten kann, bietet die Generierung Vorteile:

Das hat allerdings seinen Preis: Die Seiten verlieren jede Dynamik und zeigen immer dasselbe an. So wird eine Seite, die bei der immer dynamischen Vorschau die aktuelle Uhrzeit präsentiert, als generiertes Pendant immer die Uhrzeit zum Zeitpunkt der Generierung anzeigen (wenn man mal von browserseitiger Dynamik wie JavaScript absieht).

Generierte Seiten haben noch einen weiteren Vorteil: Sie bieten eine primitive Form des Stagings, womit gemeint ist, dass Dinge in aller Ruhe im Verborgenen vorbereitet werden können, bis sie getestet und abgenommen sind. Erst dann wird per Generierung veröffentlicht.

Generierung per Prozess

Ein großer Nachteil bei generierten Seiten ist der Zeitaufwand, wenn alle Seiten neu generiert werden müssen. Dies ist zB. nötig, wenn sich ein Element ändert, dass auf nahezu allen Seiten ändert, wie zB. die Umbenennung eines Menüpunktes auf oberster Ebene.

Bei Umfangreichen Projekten kann hier die Scriptlaufzeit des Servers nicht mehr ausreichen. Auf fast allen Servern ist die Laufzeit von PHP beschränkt, um den Server nicht durch fehlerhafte Scripte auf Dauer unerreichbar zu machen.

Damit aber dennoch Aufgaben bewältigt werden können, die mehr als diese Scriptlaufzeit benötigen, sieht das CMS Prozesse vor, die die Aufgabe, wenn sie zerlegbar ist, in kleineren Portionen abarbeiten. Nach Beendigung eines Schrittes wird der Browser angewiesen, den nächsten Schritt anzufordern. Das Generieren großer Projekte ist ein solcher Anwendungsfall und kann gut mehrere Minuten benötigen.

Generierung bei Bedarf und Clean URLs

Generierungs-Prozesse sind definitiv ein Störfaktor, denn wer wartet schon gerne. Dabei gibt es eine klügere Vorgehensweise: Statt alle Seiten im Vorhinein zu generieren, kann man auch einfach warten, bis der erste Nutzer eine Seite sehen will, und generiert sie erst dann. Das dauert dann unwesentlich länger als eine volldynamische Seite. Aber schon beim nächsten Besucher der gleichen Seite hat sie die Mühe gelohnt. Wir nennen das Generierung bei Bedarf (on demand generation).

Dies hätte man erreichen können, indem immer, wenn eine Seite noch nicht da ist und normalerweise ein Fehler erscheinen würde (404 P: age not Found) das CMS gefragt wird, ob es diese Seite nicht erzeugen kann.

Aber es geht besser. Das CMS unterstützt sogenannte Clean URLs. Diese sehen nicht nur besser aus als meist kryptische Dateinamen, sondern werden von Suchmaschinen hoch bewertet (also eine Möglichkeit für SEO) und schützen, die Technik des Server zu verbergen oder unabhängig von einem Austausch zu machen. Fast alle modernen Server, auf denen PHP und MySQL/MariaDB läuft, erfüllen mittlerweile auch die weiteren Bedingungen, die zur Nutzung dieser Technik nötig sind.

Clean URLs werden im CMS auf Ziele abgebildet. Da die Clean URLs nun die Verlinkung der Seiten übernehmen, können wir mit der Organisation der Ziele frei schalten und walten. Das ist ein immenser Vorteil. Ein Link kann so bestehen bleiben, auch wenn sich das Ziel in einer anderen Verzeichnisebene oder sogar Seitenkategorie befindet.

Dazu hat aber auch der Mechanismus der Clean URLs im CMS die Fähigkeit, statische Ziele bei Bedarf zu generieren. Statt hunderte Seiten minutenlang zu generieren, um diesen Prozess möglicherweise wegen eines übersehenen Fehlers gerade nochmal anzustoßen, reicht es, in einer Sekunde einfach alle generierte Seiten zu löschen. Sie haben richtig gelesen! Da bei Bedarf jederzeit das Ziel neu aufgebaut wird, bewirkt das Löschen aller generierten Seiten die vollständige Veröffentlichung der neusten Version.

Dieses Vorgehen ist eine Abwandlung der lazy evaluation , also der faulten Auswertung. Unterm Strich spart dies viel Serverkraft und beim Benutzer Wartezeit, denn oft werden viele Seiten zwischen zwei vollständigen Generierungsläufen überhaupt nicht abgefragt. Bei der Generierung bei Bedarf wird immer nur das gemacht, was gebraucht wird, und eine Kopie für die nächste Anfrage parat gehalten.

Generierung bei Bedarf und Teildynamisierung

Wie gesagt ist es schon ein Verlust, die Dynamik der Seiten zu verlieren. So wird zB. auch die zeitliche Einblednung von Artikeln nicht mehr funktionieren. Aber es gibt Möglichkeiten, einen Teil der Dynamik trotz Generierung wieder zurückzuholen.

Schon allein mit Clean URLs ist im CMS ja das Mischen von generierten und volldynamischen Seiten möglich. Aber Das Clean-URL-Modul ist nicht nur in der Lage

Der letzte Fall, also das zeitlich gesteuerte, erneute Generieren, bringt einen Teil der ursprünglichen Dynamik wieder zurück. Die Einschränkung besteht darin, dass man dafür sorgen muss, die Notwendigkeit der erneuten Generierung mitzuteilen.

Eine einfache und für viele Fälle ausreichende Möglichkeit ist, wenn einfach jede ausgelieferte Seite am gleichen Tag generiert sein worden muss. Damit funktionieren Zeitschaltungen mit Tagesgrenzen exakt. Aber auch wenn man den Turnus auf 1h verringert, so vermag die Generierung dennoch bei einem Massenansturm die Serverlast abtzufedern, und dennoch sind Zeitschsaltungen an Stundengrenzen möglich.

So veranlassen Sie eine zeitliche Neugenerierung

Gesetz den Fall, dass Ihr System bereits mit Generierung bei Bedarf arbeitet, so finden Sie ab der CMS-Version 6.230104.0 folgenden Reiter in der jeweiligen Seitenkategorie:

Eine generierte Seite hält hier höchstens bis Mitternacht. Dann wird sie bei Bedarf neu generiert.
Eine generierte Seite hält hier höchstens bis Mitternacht. Dann wird sie bei Bedarf neu generiert.