So funktioniert der Site-Rendering-Prozess im bluetronix CMS
Bei jedem Seitenaufruf durchläuft das bluetronix CMS mehrere Verarbeitungsschritte. In diesem Tutorial lernst du den vollständigen Rendering-Prozess kennen und erfährst, wann Sicherheitsprüfungen stattfinden, PHP-Skripte ausgeführt, Layoutvariablen ersetzt und die fertigen HTML-Seiten erzeugt werden.
1. Sicherheits-Skripte laden
Zu Beginn lädt das bluetronix CMS die sicherheitsrelevanten Skripte. Dazu gehören Secure Check, die Prüfung der Aufrufanzahl, die Vorbereitung beziehungsweise Prüfung von MySQL-Parametern sowie die Analyse von GET- und POST-Parametern.
Prüfungen, die keine Datenbankverbindung benötigen, werden bereits an dieser Stelle durchgeführt.
2. Modul-Konfiguration laden
Sofern vorhanden, wird die Datei /bx_Mod/config_own.php geladen. Darin definierte Skripte und Konfigurationsvariablen stehen damit bereits zu Beginn des Rendering-Prozesses zur Verfügung.
3. Session starten
Das CMS startet die PHP-Session mit @session_start();. Dabei sind insbesondere drei Session-Variablen wichtig: $_SESSION["S_User"] für den CMS-Benutzer beziehungsweise Edit-Mode, $_SESSION["S_Language"] für die aktuelle Sprache und $_SESSION["Web_User"] für den Benutzer eines Frontend-Logins.
4. Seitenparameter laden
Anschließend liest das CMS Informationen zum aktuellen Aufruf aus den Servervariablen. $domain erhält den Domainnamen aus $_SERVER["SERVER_NAME"], $FileParameter den Request-Pfad einschließlich GET-Parametern aus $_SERVER["REQUEST_URI"] und $file den ausgeführten Dateipfad aus $_SERVER["PHP_SELF"].
$ReferURL enthält den Wert von $_SERVER["HTTP_REFERER"], sofern dieser übermittelt wurde. Er kann beispielsweise beim Nachladen von Frames oder Seitenbereichen verwendet werden.
5. Datenbankverbindung herstellen
Das CMS stellt automatisch die Datenbankverbindung her. Danach stehen die CMS-Datenbanktabellen für weitere Prüfungen und zum Laden der Seiteninhalte zur Verfügung.
6. GET- und POST-Parameter erneut prüfen
Nach dem Aufbau der Datenbankverbindung ruft das CMS SECUREGetPost(); auf. Die übergebenen GET- und POST-Parameter werden erneut geprüft und gegebenenfalls angepasst. Jetzt sind auch Prüfungen möglich, die Datenbankinformationen benötigen.
7. Domain-, Edit- und Sprachumleitungen
Abhängig von der CMS-Konfiguration, der aufgerufenen Domain, dem Edit-Modus, der gewählten Sprache und den Aufrufparametern kann eine Weiterleitung erfolgen. Mögliche Ziele sind die Hauptdomain, die Edit-Domain sowie sprachabhängige Domains oder URLs.
8. HTTPS-Umleitung
Wurde die Website ohne HTTPS aufgerufen, erfolgt eine Weiterleitung auf die SSL- beziehungsweise HTTPS-Version der Seite.
9. Zentrale PHP-Skripte laden
Nun lädt das CMS seine zentralen PHP-Funktionen. Dazu zählen beispielsweise BlueSMTPMail() zum Mailversand und BlueFormSend() für die Verarbeitung von Formularen. Weitere zentrale Funktionen werden ebenfalls eingebunden.
10. Seitendaten aus 00_site laden
Die Daten der angeforderten Seite werden aus der Datenbanktabelle 00_site gelesen. Dabei werden CMS-Variablen wie $Template ermittelt.
Außerdem werden $LayoutHTML und $SitePHP initialisiert. $LayoutHTML enthält später das vollständige HTML-Layout, während $SitePHP den PHP-Code enthält, der direkt zur aufgerufenen Seite gehört.
11. Layout aus 00_layout laden
Das der Seite zugeordnete Layout wird aus der Datenbanktabelle 00_layout geladen und bildet die Grundlage der weiteren Verarbeitung in $LayoutHTML.
12. Sprachabhängige JavaScript-Dateien setzen
Wenn sprachspezifische Dateien vorhanden sind, kann das CMS die Standarddateien BxScript.js und BxHeadScript.js durch passende Sprachvarianten ersetzen, beispielsweise durch BxScript_de.js oder BxScript_en.js.
Dabei werden die Dateimarken __FV_/bx_script/BxScript_own_min.js__ beziehungsweise __FV_/bx_script/BxHeadScript_own_min.js__ im Layout angepasst.
13. Header und dynamische Inhalte erzeugen
Jetzt werden dynamische Inhalte erzeugt und seitenspezifische PHP-Skripte ausgeführt. DynMenue() erzeugt dynamische Menüs, IncludeModul() bindet konfigurierte Module ein und EditMARK() setzt die Bearbeitungsmarken des CMS.
Mit eval($SitePHP) wird der PHP-Code der aktuellen Seite ausgeführt; eval($IncludePHP) führt eingebundene PHP-Skripte aus.
14. Änderungsparameter für CSS und JavaScript setzen
Für CSS- und JavaScript-Dateien wird ein Änderungsparameter gesetzt. So kann der Browser bei aktualisierten Dateien eine neue Version laden, anstatt eine veraltete Datei aus seinem Cache zu verwenden.
Beispielsweise kann aus einer Dateireferenz wie /css/style.css ein Aufruf mit einem Versionsparameter wie /css/style.css?v2026... entstehen.
15. Dark- oder Light-Mode setzen
Das CMS liest den konfigurierten Darstellungsmodus aus /bx_style/BxSource/CSSEditDarkLight.bx. Abhängig vom Dateiinhalt wird der Dark- beziehungsweise Light-Mode im Layout gesetzt.
16. Modul-Konfigurationsvariablen im Layout setzen
Die Modul-Konfiguration aus /bx_Mod/config_own.php wird auf das Layout angewendet. Sind beispielsweise Shop, Suche, Login oder Übersetzungsmodul deaktiviert, können die zugehörigen Bedienelemente automatisch ausgeblendet werden.
Dafür werden Layoutmarken wie __DB_GB_DesktopIconBasket_Display__, __DB_GB_DesktopIconSearch_Display__, __DB_GB_DesktopIconLogin_Display__ oder __DB_GB_DesktopIconLang_Display__ durch none ersetzt.
17. Verbleibende Ersatzmarken entfernen
Nicht ersetzte CMS-Platzhalter werden aus dem fertigen HTML entfernt. Das betrifft unter anderem Marken nach den Mustern __DB_...__ und __ST_...__ sowie die dafür vorgesehenen internen xxx-Kommentarmarken.
18. HTML-Kommentare entfernen
Das CMS entfernt anschließend HTML-Kommentare aus $LayoutHTML. Dadurch wird unnötiger Kommentartext nicht an den Browser ausgeliefert.
19. Sprachübersetzung durchführen
Ist $_SESSION["S_Language"] nicht gleich $GBMainLang, werden die markierten Texte in die aktuell verwendete Sprache übersetzt. Die Übersetzungen stammen aus der Datenbanktabelle Translation.
Ist ein benötigter Text dort noch nicht vorhanden, wird ein neuer Eintrag in Translation erzeugt. Das CMS erkennt übersetzbare Inhalte anhand der Marken My Text und My Text.
20. Bildaufrufe über IMG.pl ersetzen
Bildaufrufe und Bildzuschnitte über IMG.pl werden durch zuvor erzeugte beziehungsweise optimierte Bilddateien ersetzt. Die fertige HTML-Seite kann dadurch direkt auf diese Bildvarianten zugreifen.
21. Fertige Seite ausgeben
Nach Abschluss der Verarbeitung wird $LayoutHTML mit dem Inhaltstyp text/html; charset=utf-8 an den Browser ausgegeben, beispielsweise über print $LayoutHTML;.
Für nicht aktivierte beziehungsweise interne Domains wird die Ausgabe mit noindex, nofollow gekennzeichnet, damit diese Seiten nicht von Suchmaschinen indexiert werden.
22. Cache schreiben
Nach der Seitenausgabe kann das CMS die fertig erzeugte Seite im Cache speichern. Voraussetzung ist, dass kein S_User angemeldet ist, sich die Seite nicht im Edit-Mode befindet und das Caching für diese Seite aktiviert ist.
Bei späteren Aufrufen kann dann die gespeicherte HTML-Seite verwendet werden, ohne den vollständigen Rendering-Prozess erneut auszuführen.
FAQ
was Kunden uns häufig Fragen
Was ist der Site-Rendering-Prozess?
Damit bezeichnet das Tutorial die Verarbeitungsschritte, mit denen das bluetronix CMS aus Seiten- und Layoutdaten die fertige HTML-Seite erzeugt und an den Browser ausgibt.
Welche Sicherheitsprüfungen erfolgen vor der Datenbankverbindung?
Vor der Datenbankverbindung werden unter anderem Secure Check, die Prüfung der Aufrufanzahl, die Vorbereitung von MySQL-Parametern und die Analyse von GET- und POST-Parametern durchgeführt.
Wann wird die Modul-Konfiguration geladen?
Die Datei /bx_Mod/config_own.php wird, sofern sie vorhanden ist, bereits vor dem Start der Session und vor dem Aufbau der Datenbankverbindung geladen.
Wofür werden S_User, S_Language und Web_User verwendet?
S_User bezeichnet den CMS-Benutzer beziehungsweise Edit-Mode, S_Language die aktuelle Sprache der Webseite und Web_User den Benutzer eines Frontend-Logins.
Aus welchen Datenbanktabellen stammen Seite und Layout?
Die Seitendaten werden aus 00_site geladen. Das dazugehörige Layout wird aus 00_layout gelesen und in $LayoutHTML verarbeitet.
Wann wird der PHP-Code einer Seite ausgeführt?
Bei der Erzeugung von Header und dynamischen Inhalten wird der seiteneigene Code über eval($SitePHP) und eingebundener PHP-Code über eval($IncludePHP) ausgeführt.
Wann werden sprachabhängige JavaScript-Dateien verwendet?
Wenn passende Sprachvarianten vorhanden sind, können BxScript.js und BxHeadScript.js durch die entsprechenden sprachspezifischen Dateien ersetzt werden.
Wie wird der Dark- oder Light-Mode bestimmt?
Das CMS liest die Datei /bx_style/BxSource/CSSEditDarkLight.bx und setzt anhand ihres Inhalts den Darstellungsmodus im Layout.
Wann werden Texte automatisch übersetzt?
Wenn die aktuelle Sprache von $GBMainLang abweicht, werden die entsprechend markierten Texte anhand der Einträge in der Tabelle Translation übersetzt.
Unter welchen Bedingungen wird die fertige Seite gecacht?
Der Cache kann geschrieben werden, wenn kein S_User angemeldet ist, sich die Seite nicht im Edit-Mode befindet und das Caching für diese Seite aktiviert wurde.