Ecco come funziona il processo di rendering del sito nel bluetronix CMS
Ad ogni accesso alla pagina, il bluetronix CMS attraversa diversi passaggi di elaborazione. In questo tutorial scoprirai l'intero processo di rendering e quando avvengono i controlli di sicurezza, vengono eseguiti gli script PHP, vengono sostituite le variabili di layout e vengono generate le pagine HTML finali.
1. Carica gli script di sicurezza
All'inizio, il CMS bluetronix carica gli script rilevanti per la sicurezza. Questi includono il Controllo Sicuro, la verifica del numero di accessi, la preparazione o verifica dei parametri MySQL e l'analisi dei parametri GET e POST.
I controlli che non richiedono una connessione al database vengono già eseguiti a questo punto.
2. Carica la configurazione del modulo
Se presente, viene caricata la file /bx_Mod/config_own.php. Gli script e le variabili di configurazione definiti al suo interno sono quindi già disponibili all'inizio del processo di rendering.
3. Avviare la sessione
Il CMS avvia la sessione PHP con @session_start();. Sono particolarmente importanti tre variabili di sessione: $_SESSION["S_User"] per l'utente del CMS o modalità di modifica, $_SESSION["S_Language"] per la lingua attuale e $_SESSION["Web_User"] per l'utente di un login frontend.
4. Caricare i parametri della pagina
Successivamente, il CMS legge le informazioni relative alla chiamata attuale dalle variabili di server. $domain ottiene il nome di dominio da $_SERVER["SERVER_NAME"], $FileParameter il percorso di richiesta inclusi i parametri GET da $_SERVER["REQUEST_URI"] e $file il percorso del file eseguito da $_SERVER["PHP_SELF"].
$ReferURL contiene il valore di $_SERVER["HTTP_REFERER"], se è stato inviato. Può ad esempio essere utilizzato durante il caricamento di frame o aree della pagina.
5. Stabilire la connessione al database
Il CMS stabilisce automaticamente la connessione al database. Successivamente, le tabelle del database CMS sono disponibili per ulteriori verifiche e per il caricamento dei contenuti delle pagine.
6. Verificare nuovamente i parametri GET e POST
Dopo aver stabilito la connessione al database, il CMS chiama SECUREGetPost();. I parametri GET e POST forniti vengono nuovamente verificati e, se necessario, adattati. Ora sono possibili anche verifiche che richiedono informazioni dal database.
7. Reindirizzamenti di dominio, modifica e lingua
In base alla configurazione del CMS, al dominio chiamato, alla modalità di modifica, alla lingua selezionata e ai parametri di chiamata, può avvenire un reindirizzamento. Possibili destinazioni sono il dominio principale, il dominio di modifica e domini o URL specifici per lingua.
8. Reindirizzamento HTTPS
Se il sito è stato richiamato senza HTTPS, avverrà un reindirizzamento alla versione SSL o HTTPS della pagina.
9. Caricare gli script PHP centrali
Ora il CMS carica le sue funzioni PHP centrali. Queste includono ad esempio BlueSMTPMail() per l'invio di email e BlueFormSend() per l'elaborazione dei moduli. Altre funzioni centrali vengono anch'esse collegate.
10. Caricare i dati della pagina da 00_site
I dati della pagina richiesta vengono letti dalla tabella del database 00_site. Vengono determinate variabili CMS come $Template.
Inoltre, $LayoutHTML e $SitePHP vengono inizializzati. $LayoutHTML conterrà in seguito il layout HTML completo, mentre $SitePHP conterrà il codice PHP direttamente legato alla pagina richiesta.
11. Caricare il layout da 00_layout
Il layout assegnato alla pagina viene caricato dalla tabella del database 00_layout e costituisce la base per ulteriori elaborazioni in $LayoutHTML.
12. Impostare i file JavaScript dipendenti dalla lingua
Se esistono file specifici per lingua, il CMS può sostituire i file standard BxScript.js e BxHeadScript.js con le varianti linguistiche appropriate, come BxScript_de.js o BxScript_en.js.
In questo modo, i segnaposto dei file __FV_/bx_script/BxScript_own_min.js__ e __FV_/bx_script/BxHeadScript_own_min.js__ vengono adattati nel layout.
13. Generare intestazioni e contenuti dinamici
Ora vengono generati contenuti dinamici ed eseguiti script PHP specifici per la pagina. DynMenue() genera menu dinamici, IncludeModul() integra moduli configurati e EditMARK() imposta i segni di modifica del CMS.
Con eval($SitePHP) viene eseguito il codice PHP della pagina attuale; eval($IncludePHP) esegue script PHP inclusi.
14. Impostare i parametri di modifica per CSS e JavaScript
Per i file CSS e JavaScript viene impostato un parametro di modifica. In questo modo, il browser può caricare una nuova versione per file aggiornati, anziché utilizzare un file obsoleto dalla sua cache.
Ad esempio, da un riferimento a un file come /css/style.css può derivare una chiamata con un parametro di versione come /css/style.css?v2026....
15. Impostare la modalità scura o chiara
Il CMS legge la modalità di visualizzazione configurata da /bx_style/BxSource/CSSEditDarkLight.bx. A seconda del contenuto del file, viene impostato il Dark- o Light-Mode nel layout.
16. Impostare le variabili di configurazione del modulo nel layout
La configurazione del modulo da /bx_Mod/config_own.php viene applicata al layout. Se ad esempio il modulo Shop, Ricerca, Login o Traduzione è disattivato, i relativi elementi di controllo possono essere automaticamente nascosti.
I segnaposto del layout come __DB_GB_DesktopIconBasket_Display__, __DB_GB_DesktopIconSearch_Display__, __DB_GB_DesktopIconLogin_Display__ o __DB_GB_DesktopIconLang_Display__ vengono sostituiti con none.
17. Rimuovere i segnaposto rimanenti
I segnaposto CMS non sostituiti vengono rimossi dall'HTML finale. Questo riguarda, tra l'altro, i segnaposto dei modelli __DB_...__ e __ST_...__ e i commenti interni xxx previsti per questo.
18. Rimuovere i commenti HTML
Il CMS rimuove successivamente i commenti HTML da $LayoutHTML. In questo modo, il testo non necessario dei commenti non viene consegnato al browser.
19. Eseguire la traduzione linguistica
Se $_SESSION["S_Language"] non è uguale a $GBMainLang, i testi contrassegnati vengono tradotti nella lingua attualmente in uso. Le traduzioni provengono dalla tabella del database Translation.
Se un testo necessario non è ancora presente lì, viene creato un nuovo ingresso in Translation. Il CMS riconosce i contenuti traducibili in base ai segni My Text e My Text.
20. Sostituire le chiamate alle immagini tramite IMG.pl
Le chiamate delle immagini e i ritagli delle immagini tramite IMG.pl vengono sostituiti da file immagine precedentemente creati o ottimizzati. La pagina HTML finale può quindi accedere direttamente a queste varianti delle immagini.
21. Restituire la pagina completata
Al termine dell'elaborazione, $LayoutHTML viene restituito al browser con il tipo di contenuto text/html; charset=utf-8, ad esempio tramite print $LayoutHTML;.
Per i domini non attivati o interni, l'output è contrassegnato con noindex, nofollow affinché queste pagine non siano indicizzate dai motori di ricerca.
22. Scrivere nella cache
Dopo l'uscita della pagina, il CMS può memorizzare la pagina generata nel cache. La condizione è che nessun S_User sia loggato, che la pagina non sia in modalità di modifica e che la memorizzazione nella cache per questa pagina sia attivata.
Nelle chiamate successive, la pagina HTML memorizzata può essere utilizzata senza eseguire nuovamente l'intero processo di rendering.
FAQ
cosa ci chiedono spesso i clienti
Cos'è il processo di rendering del sito?
Con questo il tutorial si riferisce ai passaggi di elaborazione tramite i quali il CMS bluetronix genera la pagina HTML finale dai dati di pagina e layout e la restituisce al browser.
Quali controlli di sicurezza vengono eseguiti prima della connessione al database?
Prima della connessione al database vengono eseguiti, tra l'altro, Secure Check, il controllo del numero di accessi, la preparazione dei parametri MySQL e l'analisi dei parametri GET e POST.
Quando viene caricata la configurazione del modulo?
Il file /bx_Mod/config_own.php viene caricato, se presente, già prima dell'inizio della sessione e prima della creazione della connessione al database.
A cosa servono S_User, S_Language e Web_User?
S_User indica l'utente del CMS o la modalità di modifica, S_Language la lingua corrente del sito web e Web_User l'utente di un login frontend.
Da quali tabelle del database provengono la pagina e il layout?
I dati della pagina vengono caricati da 00_site. Il layout corrispondente viene letto da 00_layout e elaborato in $LayoutHTML.
Quando viene eseguito il codice PHP di una pagina?
Durante la generazione dell'intestazione e dei contenuti dinamici, il codice specifico della pagina viene eseguito tramite eval($SitePHP) e il codice PHP incluso tramite eval($IncludePHP).
Quando vengono utilizzati i file JavaScript dipendenti dalla lingua?
Se sono presenti varianti linguistiche appropriate, BxScript.js e BxHeadScript.js possono essere sostituiti dai relativi file specifici per la lingua.
Come viene determinato il Dark o Light Mode?
Il CMS legge il file /bx_style/BxSource/CSSEditDarkLight.bx e imposta il modo di visualizzazione nel layout in base al suo contenuto.
Quando i testi vengono tradotti automaticamente?
Se la lingua attuale è diversa da $GBMainLang, i testi contrassegnati vengono tradotti in base alle voci nella tabella Translation.
In quali condizioni la pagina finale viene memorizzata nella cache?
Il cache può essere scritto se non c'è nessun S_User loggato, se la pagina non è in modalità di modifica e se la memorizzazione nella cache per questa pagina è stata attivata.