Static HTML Export
Static HTML Export
Hallo.
Ich habe vor einer Weile mal im Core von CMSms rumgefummelt. Mit dem Ergebnis, dass die Inhalte der Seiten nicht nur in der Datenbank, sondern auch als Textdateien auf dem Server gespeichert wurden. Die Textdateien hatten als Namen die jeweilige ID des Inhalts.
Als Frontend habe ich dann ein eigenes Script verwendet, dass sich nur mit der Datenbank verbindet um die Menüstruktur auszulesen.
Dabei kam ich dann unter anderem auch an die ID der einzelnen Inhalte. Somit konnte ich mir ein Menü aufbauen, dass die ID im Link an das Script übergibt. Somit konnte das Script die Textdatei einfach ausgeben, was am Ende natürlich etwas schneller war.
Allerdings funktionierten einige Module dann natürlich nicht.
Soviel zur Vorgeschichte.
Ich arbeite seit kurzem an einem Modul, das die komplette Seite in Form von HTML Dokumenten ausgeben soll.
Die index.php prüft dann zuerst, ob die angeforderte Seite bereits als HTML-Dokument existiert. Wenn ja, dann gibt es diese HTML-Datei einfach aus. Wenn nicht, dann wird der reguläre CMSms-Code ausgeführt.
Außerdem soll eine Option eingebaut werden, die es ermöglicht, dass jede Seite deren Inhalt im Backend geändert wurde, beim Speichern automatisch auch als HTML-Dokument exportiert wird.
(Dazu müssen allerdings ein paar core-dateien geändert werden. Dazu komme ich ein andermal. )
Mit Hilfe des Skeleton Moduls (<- geniale Idee!) ist das Erstellen des Moduls soweit auch kein Problem.
Die größte Schwierigkeit ist der Parser, der die CMSms-Tags (die geschweiften Klammern) mit dem jeweiligen HTML-Code ersetzt.
Mein Script funktioniert soweit ganz gut. Nur das Problem ist, dass es viel zu langsam ist, was dazu führt, dass der Server das Script bei größeren Seiten aufgrund eines timeouts einfach abbricht.
Da ich außer auf meinem Testserver keinen Zugriff auf die php.ini habe, in der man dieses Timeout einstellen könnte, würde ich mein script ein wenig optimieren wollen.
Weiterhin funktioniert das Modul, da es ja vom Backend aus operiert, nicht bei allen Plugins/Modulen. Speziell bei solchen, die Informationen aus POST- oder GET-Daten entnehmen, die ja nur zu Laufzeit des Frontends existieren.
Hat jemand Erfahrung im Umgang mit Algorithmen. Speziell im Bereich Reguläre Ausdrücke?
(Und ist das hier überhaupt die richtige Ecke im Forum?)
cheers
Ich habe vor einer Weile mal im Core von CMSms rumgefummelt. Mit dem Ergebnis, dass die Inhalte der Seiten nicht nur in der Datenbank, sondern auch als Textdateien auf dem Server gespeichert wurden. Die Textdateien hatten als Namen die jeweilige ID des Inhalts.
Als Frontend habe ich dann ein eigenes Script verwendet, dass sich nur mit der Datenbank verbindet um die Menüstruktur auszulesen.
Dabei kam ich dann unter anderem auch an die ID der einzelnen Inhalte. Somit konnte ich mir ein Menü aufbauen, dass die ID im Link an das Script übergibt. Somit konnte das Script die Textdatei einfach ausgeben, was am Ende natürlich etwas schneller war.
Allerdings funktionierten einige Module dann natürlich nicht.
Soviel zur Vorgeschichte.
Ich arbeite seit kurzem an einem Modul, das die komplette Seite in Form von HTML Dokumenten ausgeben soll.
Die index.php prüft dann zuerst, ob die angeforderte Seite bereits als HTML-Dokument existiert. Wenn ja, dann gibt es diese HTML-Datei einfach aus. Wenn nicht, dann wird der reguläre CMSms-Code ausgeführt.
Außerdem soll eine Option eingebaut werden, die es ermöglicht, dass jede Seite deren Inhalt im Backend geändert wurde, beim Speichern automatisch auch als HTML-Dokument exportiert wird.
(Dazu müssen allerdings ein paar core-dateien geändert werden. Dazu komme ich ein andermal. )
Mit Hilfe des Skeleton Moduls (<- geniale Idee!) ist das Erstellen des Moduls soweit auch kein Problem.
Die größte Schwierigkeit ist der Parser, der die CMSms-Tags (die geschweiften Klammern) mit dem jeweiligen HTML-Code ersetzt.
Mein Script funktioniert soweit ganz gut. Nur das Problem ist, dass es viel zu langsam ist, was dazu führt, dass der Server das Script bei größeren Seiten aufgrund eines timeouts einfach abbricht.
Da ich außer auf meinem Testserver keinen Zugriff auf die php.ini habe, in der man dieses Timeout einstellen könnte, würde ich mein script ein wenig optimieren wollen.
Weiterhin funktioniert das Modul, da es ja vom Backend aus operiert, nicht bei allen Plugins/Modulen. Speziell bei solchen, die Informationen aus POST- oder GET-Daten entnehmen, die ja nur zu Laufzeit des Frontends existieren.
Hat jemand Erfahrung im Umgang mit Algorithmen. Speziell im Bereich Reguläre Ausdrücke?
(Und ist das hier überhaupt die richtige Ecke im Forum?)
cheers
Last edited by NaN on Thu Aug 09, 2007 5:00 pm, edited 1 time in total.
Re: Static HTML Export
Die Programmierer-Fraktion ist hier leider noch etwas unterbesetzt ... und meine Erfahrungen reichen allenfalls für ein paar kreative CodeveränderungenNaN wrote: Hat jemand Erfahrung im Umgang mit Algorithmen. Speziell im Bereich Reguläre Ausdrücke?

Re: Static HTML Export
Ich komme offenbar leider nicht drumherum, bei der Installation des Moduls einige Coredateien austauschen zu müssen.
Was blöd ist, weil bei der nächsten CMSms Version könnte das natürlich zu Problemen führen.
Warum ich dieses Modul schreiben möchte ist einfach: Performance.
Es gibt viele Seiten, die nicht die volle Funktionalität von CMSms nutzen.
Bei kleinen Seiten, deren Inhalte sich eher selten ändern muss nicht jedesmal der komplette CMS-code ausgeführt werden.
Godfather hatte das Thema Performance schonmal angesprochen: (http://forum.cmsmadesimple.org/index.php/topic,14086.0.html)
Allerdings aus dem Blickwinkel für enorm große Seiten.
@cyberman:
Du hattest in diesem Thema etwas von einer modifizierten index.php und semi-dynamisch bzw. semi-statisch geschrieben.
Könntest Du mir das etwas näher erläutern?
Ich bin kein Progrmmierer und beschäftige mich erst seit ca. einem Jahr mit PHP. Möglicherweise ist meine Herangehensweise viel zu kompliziert.
Mein Script funktioniert folgendermaßen:
Zuerst wird die Template ID aus der Datenbank ermittelt.
Danach der Inhalt des Templates.
Anschließend wird im Verzeichnis Plugins nach allen im Frontend verwendbaren CMS-Tags gesucht.
Danach wird systematisch das Template nach diesen Tags und deren Parametern durchsucht und durch das Ergebnis der jeweiligen Funktion die vom tag ausgeführt werden soll ersetzt.
Aus dem Template wird Stück für Stück eine vollständige HTML-Seite, die dann in einem seperaten Ordner unter $content_alias.htm gespeichert wird.
Bei großen Seiten kann das natürlich sehr lange dauern, weshalb die Idee eher für Seiten mit kleinerem Umfang gedacht ist.
Mein größtes Problem ist folgendes:
Komischerweise funktionieren manche Funktionen nur teilweise.
Z.B. die Funktion zur Ausgabe des Inhalts ({content}) ersetzt manchmal auch tags, die durch {ldelim} maskiert wurden.
Ich kann mir darauf keinen Reim machen.
Außerdem frage ich mich, ob das die Mühe eigentlich wert ist. Denn irgendwo muss doch im core eine Funktion existieren, die exakt das selbe macht. Denn schließlich bekommt der Browser ja am Ende ein HTML-Dokument. Alles was ich will ist, dieses nicht an den Browser zu senden, sondern zu speichern.
Hat da jemand einen konstruktiven Vorschlag? Oder sollte ich lieber die Finger von PHP lassen und besser bei HTML/CSS bleiben?
cheers
Was blöd ist, weil bei der nächsten CMSms Version könnte das natürlich zu Problemen führen.
Warum ich dieses Modul schreiben möchte ist einfach: Performance.
Es gibt viele Seiten, die nicht die volle Funktionalität von CMSms nutzen.
Bei kleinen Seiten, deren Inhalte sich eher selten ändern muss nicht jedesmal der komplette CMS-code ausgeführt werden.
Godfather hatte das Thema Performance schonmal angesprochen: (http://forum.cmsmadesimple.org/index.php/topic,14086.0.html)
Allerdings aus dem Blickwinkel für enorm große Seiten.
@cyberman:
Du hattest in diesem Thema etwas von einer modifizierten index.php und semi-dynamisch bzw. semi-statisch geschrieben.
Könntest Du mir das etwas näher erläutern?
Ich bin kein Progrmmierer und beschäftige mich erst seit ca. einem Jahr mit PHP. Möglicherweise ist meine Herangehensweise viel zu kompliziert.
Mein Script funktioniert folgendermaßen:
Zuerst wird die Template ID aus der Datenbank ermittelt.
Danach der Inhalt des Templates.
Anschließend wird im Verzeichnis Plugins nach allen im Frontend verwendbaren CMS-Tags gesucht.
Danach wird systematisch das Template nach diesen Tags und deren Parametern durchsucht und durch das Ergebnis der jeweiligen Funktion die vom tag ausgeführt werden soll ersetzt.
Aus dem Template wird Stück für Stück eine vollständige HTML-Seite, die dann in einem seperaten Ordner unter $content_alias.htm gespeichert wird.
Bei großen Seiten kann das natürlich sehr lange dauern, weshalb die Idee eher für Seiten mit kleinerem Umfang gedacht ist.
Mein größtes Problem ist folgendes:
Komischerweise funktionieren manche Funktionen nur teilweise.
Z.B. die Funktion zur Ausgabe des Inhalts ({content}) ersetzt manchmal auch tags, die durch {ldelim} maskiert wurden.
Ich kann mir darauf keinen Reim machen.
Außerdem frage ich mich, ob das die Mühe eigentlich wert ist. Denn irgendwo muss doch im core eine Funktion existieren, die exakt das selbe macht. Denn schließlich bekommt der Browser ja am Ende ein HTML-Dokument. Alles was ich will ist, dieses nicht an den Browser zu senden, sondern zu speichern.
Hat da jemand einen konstruktiven Vorschlag? Oder sollte ich lieber die Finger von PHP lassen und besser bei HTML/CSS bleiben?
cheers
Re: Static HTML Export
Da auch ich kein Programmierer bin, hab ich mich für eine light-Variante der Änderungen entschieden. Im Prinzip funktioniert es wie mein Cache-ProjektNaN wrote: Du hattest in diesem Thema etwas von einer modifizierten index.php und semi-dynamisch bzw. semi-statisch geschrieben.
Könntest Du mir das etwas näher erläutern?
http://dev.cmsmadesimple.org/projects/cache/
mit dem Unterschied, dass nicht nur der Content und das Stylesheet als zip-komprimierte Datei gespeichert wird, sondern die komplette html-Seite.
Ich modifiziere dabei lediglich die index.php, was die Wartung gegenüber deiner Version etwas vereinfacht. Möglicherweise ist deine Variante etwas funktioneller

Es wird geprüft, ob die Datei mit der jeweiligen content_id bereits gespeichert ist. Parallel dazu hab ich in der config.php einen Parameter namens $config['lifetime'] = ''; hinzugefügt. Er enthält die Zeit in Sekunden, für die die gespeicherten Dateien aktuell sein sollen.
Ist eine Seite/Datei mit der content_id nicht vorhanden, wird die Seite normal via Smarty aufgebaut und das Ergebnis anschließend zusätzlich in eine Datei geschrieben. Ist die Datei jedoch vorhanden, wird der Timestamp dieser Datei mit der aktuellen Zeit verglichen. Erst nach Ablauf von $config['lifetime'] wird die Datei neu geschrieben. Gespeichert wird das ganze in temp/cache - das hat den Vorteil, dass du mit dem Löschen des Zwischenspeichers in der Administration (Administrator > Globale Einstellungen) auch die Dateien löschen kannst.
Wenn du z. Bsp. eine Webseite hast, bei der sich häufiger etwas ändert (mit Gästebuch, News etc.), könntest du den Wert auf 180 (= 3 Minuten -> deswegen semidynamisch

Trotzdem geht dir der Luxus voll dynamische Seiten nicht verloren - du musst nur die Box "Zwischenspeichern" im Reiter "Optionen" bei der Seitenerstellung deaktivieren.
Ist sicherlich nicht das Optimum, aber durchaus geeignet, eine größere Anzahl an Besuchern zu verkraften. Ich werd dies nächste Woche im Cache-Projekt veröffentlichen. Will es nur nicht ohne Doku rausgeben.
Last edited by cyberman on Thu Aug 09, 2007 4:42 pm, edited 1 time in total.
Re: Static HTML Export
Da hatten wir wohl beide fast die gleiche Idee.
Das Adminpanel in meinem Modul ist ähnlich aufgebaut.
Es gibt einen Tab mit einer Liste aller Seiten von denen man einzelne, mehrere oder alle aktiven Seiten exportieren kann. (ähnlich wie die Liste bei Inhalt->Seiten; ich überlege, ob ich das nicht gleich dort integriere)
Und einen zweiten Tab in dem man Optionen festlegen kann. Z.B. ob geänderter Inhalt beim Speichern automatisch exportiert werden soll oder nicht. Und ob die exportierten Seiten überhaupt im Frontend verwendet werden sollen.
Werd mir mal Deine Cache-Funktion anschauen. Vielleicht ist das ja schon das was ich brauche.
Falls nicht,
Bin mal gespannt wer schneller fertig ist
Das Adminpanel in meinem Modul ist ähnlich aufgebaut.
Es gibt einen Tab mit einer Liste aller Seiten von denen man einzelne, mehrere oder alle aktiven Seiten exportieren kann. (ähnlich wie die Liste bei Inhalt->Seiten; ich überlege, ob ich das nicht gleich dort integriere)
Und einen zweiten Tab in dem man Optionen festlegen kann. Z.B. ob geänderter Inhalt beim Speichern automatisch exportiert werden soll oder nicht. Und ob die exportierten Seiten überhaupt im Frontend verwendet werden sollen.
Werd mir mal Deine Cache-Funktion anschauen. Vielleicht ist das ja schon das was ich brauche.
Falls nicht,
Bin mal gespannt wer schneller fertig ist

Re: Static HTML Export
ich wollte nur mal kurz anmerken, dass statische html seiten (wenn ich mich nicht irre) in der CMSMS 2 schon umgesetzt werden
Re: Static HTML Export
Noch einfacher Powercms holen und abschreiben bzw. in CMSMS einsetzen, dauert 10 Minuten.
Re: Static HTML Export
Ja wuschel, wir wissen, dass du sehr von Powercms überzeugt bist, aber ich z.B nicht, denn der Modulmanager fehlt und ein paar andere Sachen fehlen einfach, sonst hätte ich auch schon längst Powercms eingesetzt! Ich glaube es gibt bestimmt auch noch einige andere Leute, die das CMS nicht so gut finden. Nicht alles ist so einfach wie in CMSMS. Das fängt schon bei den News an, aber das ist hier der falsche Thread um über Powercms zu diskutieren
Sory für den negativen Touch dieses Textes!
Wenn man schon Werbung macht, dann aber bitte etwas verständlicher...

Wenn man schon Werbung macht, dann aber bitte etwas verständlicher...
wo denn?abschreiben
Last edited by SimonSchaufi on Tue Aug 14, 2007 8:20 am, edited 1 time in total.
Re: Static HTML Export
PowerCMS hat ein eigenes Forum - wenn ihr darüber diskutieren wollt, könnt ihr euch gern dort treffen.
Ansonsten isses hier Off Topic und wird gemäß der Forenregeln gekillt.
Ansonsten isses hier Off Topic und wird gemäß der Forenregeln gekillt.
Re: Static HTML Export
Nöwenn ihr darüber diskutieren wollt
NöWerbung macht
Selbst ist der angehender Informatiker.wo denn?
Re: Static HTML Export
Ich kopiere doch keinen Code von einer drittklassigen Light-Version!wuschel wrote: Noch einfacher Powercms holen und abschreiben bzw. in CMSMS einsetzen, dauert 10 Minuten.
Um es mit Deinen Worten zu sagen:
In diesem Sinne Danke für Deine Unterstützung.wuschel wrote: Selbst ist der angehender Informatiker.
Solche User braucht kein Forum.
Re: Static HTML Export
So.
Ich habe mal eine Alpa-Version meiner Idee zum Download bereitgestellt.
Das Script ist nicht perfekt.
Dummerweise dauert das Exportieren einer Seite länger als das Generieren durch Smarty.
Liegt wohl an meiner etwas sehr umständlichen Art das Template zu parsen.
Wie gesagt, falls sich jemand mit solchen Dingen auskennt, wäre ich für den ein oder anderen Tipp dankbar.
Ansonsten scheint es gut zu funktionieren.
Ich habe mal eine Alpa-Version meiner Idee zum Download bereitgestellt.
Das Script ist nicht perfekt.
Dummerweise dauert das Exportieren einer Seite länger als das Generieren durch Smarty.
Liegt wohl an meiner etwas sehr umständlichen Art das Template zu parsen.
Wie gesagt, falls sich jemand mit solchen Dingen auskennt, wäre ich für den ein oder anderen Tipp dankbar.
Ansonsten scheint es gut zu funktionieren.
Re: Static HTML Export
Ähm, ja sorry.
Darum hab ich mich noch garnicht gekümmert.
Werd demnächst ne neue Version reinstellen.
Verwende momentan für die Backendadministration die Klasse AdminTheme.
Dadurch kann ich irgendwie nicht auf meine Sprachdateien zugreifen, sondern nur auf die im Bereich Admin.
Baue in der neuen Version das Layout dann mit meinen eigenen Funktionen auf.
Damit müsste das Problem mit der Sprache geklärt sein.
Mir ist aufgefallen, dass ich die Funktion "auto export" auch mit Hilfe des Eventmanagers lösen könnte.
Somit bräuchte ich in der Index.php am Anfang nur noch eine Zeile Code einfügen.
Allerdings scheint die Funktion AddEventHandler nicht richtig zu funktionieren oder ich rufe sie falsch auf.
Ich bekomme beim Einschalten der Option keine Fehlermeldung aber es passiert auch nichts.
Eigentlich sollte das doch so funktionieren, oder?
Gleiches gilt auch, wenn ich bei der Installation einen User-Tag anlegen möchte.
Kann mir das jemand erklären?
Darum hab ich mich noch garnicht gekümmert.
Werd demnächst ne neue Version reinstellen.
Verwende momentan für die Backendadministration die Klasse AdminTheme.
Dadurch kann ich irgendwie nicht auf meine Sprachdateien zugreifen, sondern nur auf die im Bereich Admin.
Baue in der neuen Version das Layout dann mit meinen eigenen Funktionen auf.
Damit müsste das Problem mit der Sprache geklärt sein.
Mir ist aufgefallen, dass ich die Funktion "auto export" auch mit Hilfe des Eventmanagers lösen könnte.
Somit bräuchte ich in der Index.php am Anfang nur noch eine Zeile Code einfügen.
Allerdings scheint die Funktion AddEventHandler nicht richtig zu funktionieren oder ich rufe sie falsch auf.
Ich bekomme beim Einschalten der Option keine Fehlermeldung aber es passiert auch nichts.
Eigentlich sollte das doch so funktionieren, oder?
Code: Select all
$contentoperations =& $gCms->GetContentOperations();
$contentoperations->AddEventHandler('eventname', 'modul/user-tag');
Kann mir das jemand erklären?