Voici comment fonctionne le processus de rendu du site dans le CMS bluetronix
À chaque appel de page, le CMS bluetronix traverse plusieurs étapes de traitement. Dans ce tutoriel, vous découvrirez le processus complet de rendu et apprendrez quand des vérifications de sécurité sont effectuées, quand des scripts PHP sont exécutés, quand des variables de mise en page sont remplacées et quand les pages HTML finales sont générées.
1. Chargement des scripts de sécurité
Au début, le CMS bluetronix charge les scripts liés à la sécurité. Cela inclut Secure Check, le contrôle du nombre d'appels, la préparation ou le contrôle des paramètres MySQL ainsi que l'analyse des paramètres GET et POST.
Les vérifications qui ne nécessitent pas de connexion à la base de données sont effectuées à ce stade.
2. Chargement de la configuration du module
Si disponible, le fichier /bx_Mod/config_own.php est chargé. Les scripts et variables de configuration définis à l'intérieur sont donc déjà disponibles au début du processus de rendu.
3. Démarrer la session
Le CMS démarre la session PHP avec @session_start();. Trois variables de session sont particulièrement importantes : $_SESSION["S_User"] pour l'utilisateur CMS ou le mode édition, $_SESSION["S_Language"] pour la langue actuelle et $_SESSION["Web_User"] pour l'utilisateur d'une connexion frontend.
4. Charger les paramètres de page
Ensuite, le CMS lit les informations sur l'appel actuel depuis les variables de serveur. $domain reçoit le nom de domaine à partir de $_SERVER["SERVER_NAME"], $FileParameter le chemin de requête y compris les paramètres GET à partir de $_SERVER["REQUEST_URI"] et $file le chemin du fichier exécuté à partir de $_SERVER["PHP_SELF"].
$ReferURL contient la valeur de $_SERVER["HTTP_REFERER"], si elle a été transmise. Elle peut par exemple être utilisée lors du rechargement de cadres ou de sections de pages.
5. Établir la connexion à la base de données
Le CMS établit automatiquement la connexion à la base de données. Ensuite, les tables de la base de données du CMS sont disponibles pour d'autres vérifications et pour le chargement du contenu des pages.
6. Vérifier à nouveau les paramètres GET et POST
Après l'établissement de la connexion à la base de données, le CMS appelle SECUREGetPost(); Les paramètres GET et POST transmis sont de nouveau vérifiés et éventuellement ajustés. Maintenant, des vérifications nécessitant des informations de la base de données sont également possibles.
7. Redirections de domaine, d'édition et de langue
En fonction de la configuration du CMS, du domaine appelé, du mode d'édition, de la langue choisie et des paramètres d'appel, une redirection peut avoir lieu. Les cibles possibles sont le domaine principal, le domaine d'édition ainsi que des domaines ou URL dépendants de la langue.
8. Redirection HTTPS
Si le site Web a été appelé sans HTTPS, une redirection vers la version SSL ou HTTPS de la page s'effectue.
9. Charger les scripts PHP centraux
Le CMS charge maintenant ses fonctions PHP centrales. Cela inclut par exemple BlueSMTPMail() pour l'envoi d'e-mails et BlueFormSend() pour le traitement des formulaires. D'autres fonctions centrales sont également intégrées.
10. Charger les données de la page depuis 00_site
Les données de la page demandée sont lues à partir de la table de base de données 00_site. Les variables du CMS comme $Template y sont déterminées.
De plus, $LayoutHTML et $SitePHP sont initialisés. $LayoutHTML contiendra plus tard la mise en page HTML complète, tandis que $SitePHP contiendra le code PHP qui appartient directement à la page appelée.
11. Charger la mise en page depuis 00_layout
Le design associé à la page est chargé à partir de la table de base de données 00_layout et sert de base au traitement ultérieur dans $LayoutHTML.
12. Définir les fichiers JavaScript dépendants de la langue
S'il existe des fichiers spécifiques à la langue, le CMS peut remplacer les fichiers standards BxScript.js et BxHeadScript.js par des variantes linguistiques appropriées, comme BxScript_de.js ou BxScript_en.js.
Les balises de fichier __FV_/bx_script/BxScript_own_min.js__ et __FV_/bx_script/BxHeadScript_own_min.js__ sont ajustées dans la mise en page.
13. Générer l'en-tête et le contenu dynamique
Des contenus dynamiques sont maintenant générés et des scripts PHP spécifiques à la page sont exécutés. DynMenue() génère des menus dynamiques, IncludeModul() intègre des modules configurés et EditMARK() définit les marques d'édition du CMS.
Avec eval($SitePHP), le code PHP de la page actuelle est exécuté ; eval($IncludePHP) exécute les scripts PHP intégrés.
14. Définir les paramètres de changement pour CSS et JavaScript
Pour les fichiers CSS et JavaScript, un paramètre de changement est défini. Ainsi, le navigateur peut charger une nouvelle version des fichiers mis à jour, plutôt que d'utiliser un ancien fichier de son cache.
Par exemple, une référence de fichier comme /css/style.css peut devenir un appel avec un paramètre de version comme /css/style.css?v2026....
15. Définir le mode sombre ou clair
Le CMS lit le mode d'affichage configuré à partir de /bx_style/BxSource/CSSEditDarkLight.bx. En fonction du contenu du fichier, le mode sombre ou clair est appliqué à la mise en page.
16. Définir les variables de configuration du module dans la mise en page
La configuration des modules à partir de /bx_Mod/config_own.php est appliquée à la mise en page. Par exemple, si les modules de boutique, de recherche, de connexion ou de traduction sont désactivés, les éléments de contrôle associés peuvent être masqués automatiquement.
Les balises de mise en page telles que __DB_GB_DesktopIconBasket_Display__, __DB_GB_DesktopIconSearch_Display__, __DB_GB_DesktopIconLogin_Display__ ou __DB_GB_DesktopIconLang_Display__ sont remplacées par none.
17. Supprimer les marques de remplacement restantes
Les placeholders du CMS non remplacés sont supprimés du HTML final. Cela concerne notamment les balises suivant les modèles __DB_...__ et __ST_...__ ainsi que les balises de commentaire internes xxx prévues à cet effet.
18. Supprimer les commentaires HTML
Le CMS retire ensuite les commentaires HTML de $LayoutHTML. Cela permet d'éviter que des textes de commentaires inutiles ne soient envoyés au navigateur.
19. Effectuer la traduction de la langue
Si $_SESSION["S_Language"] n'est pas égal à $GBMainLang, les textes marqués sont traduits dans la langue actuellement utilisée. Les traductions proviennent de la table de base de données Translation.
Si un texte nécessaire n'est pas encore présent, un nouvel enregistrement est créé dans Translation. Le CMS identifie les contenus traduisibles grâce aux marques My Text et My Text.
20. Remplacer les appels d'images par IMG.pl
Les appels d'images et les découpes d'images via IMG.pl sont remplacés par des fichiers d'images préalablement créés ou optimisés. La page HTML finale peut donc accéder directement à ces variantes d'images.
21. Afficher la page finale
Après le traitement, $LayoutHTML est envoyé au navigateur avec le type de contenu text/html; charset=utf-8, par exemple via print $LayoutHTML;.
Pour les domaines non activés ou internes, la sortie est marquée avec noindex, nofollow afin que ces pages ne soient pas indexées par les moteurs de recherche.
22. Écrire le cache
Après la sortie de la page, le CMS peut enregistrer la page générée dans le cache. La condition est qu'aucun S_User ne soit connecté, que la page ne soit pas en mode édition et que le caching pour cette page soit activé.
Lors des appels ultérieurs, la page HTML enregistrée peut être utilisée, sans devoir exécuter à nouveau le processus de rendu complet.
FAQ
ce que nos clients nous demandent souvent
Qu'est-ce que le processus de rendu du site ?
Le tutoriel désigne par cela les étapes de traitement par lesquelles le CMS bluetronix génère la page HTML finale à partir des données de page et de mise en page et la délivre au navigateur.
Quelles vérifications de sécurité sont effectuées avant la connexion à la base de données ?
Avant la connexion à la base de données, notamment un contrôle sécurisé, la vérification du nombre d'appels, la préparation des paramètres MySQL et l'analyse des paramètres GET et POST sont effectués.
Quand la configuration du module est-elle chargée ?
Le fichier /bx_Mod/config_own.php est chargé, s'il est présent, déjà avant le début de la session et avant l'établissement de la connexion à la base de données.
À quoi servent S_User, S_Language et Web_User ?
S_User désigne l'utilisateur CMS ou le mode édition, S_Language la langue actuelle de la page Web et Web_User l'utilisateur d'une connexion frontale.
D'où proviennent les données de page et de mise en page ?
Les données de la page sont chargées à partir de 00_site. La mise en page associée est lue à partir de 00_layout et traitée dans $LayoutHTML.
Quand le code PHP d'une page est-il exécuté ?
Lors de la génération de l'en-tête et du contenu dynamique, le code propre à la page est exécuté via eval($SitePHP) et le code PHP inclus via eval($IncludePHP).
Quand les fichiers JavaScript dépendants de la langue sont-ils utilisés ?
Lorsque des variantes linguistiques appropriées sont disponibles, BxScript.js et BxHeadScript.js peuvent être remplacés par les fichiers spécifiques à la langue correspondante.
Comment le mode sombre ou clair est-il déterminé ?
Le CMS lit le fichier /bx_style/BxSource/CSSEditDarkLight.bx et définit le mode d'affichage dans la mise en page en fonction de son contenu.
Quand les textes sont-ils automatiquement traduits ?
Lorsque la langue actuelle diffère de $GBMainLang, les textes marqués en conséquence sont traduits selon les entrées dans la table Translation.
Dans quelles conditions la page finie est-elle mise en cache ?
Le cache peut être écrit si aucun S_User n'est connecté, si la page n'est pas en mode édition et si le caching pour cette page a été activé.