Architettura: com'è fatto Drupal
Capire come Drupal è costruito internamente aiuta a prendere decisioni migliori durante lo sviluppo: perché certi pattern esistono, perché alcune scelte architetturali sono obbligate e altre no, e dove si può intervenire senza rompere nulla.
Il core e Symfony
Da Drupal 8 in poi, il core è costruito sopra Symfony, uno dei framework PHP più diffusi e mantenuti. Questo significa che buona parte della logica fondamentale, la gestione delle richieste HTTP, il sistema di routing, la dependency injection, non è codice custom di Drupal ma componenti standard dell'ecosistema PHP.
Il vantaggio è duplice: chi conosce Symfony trova familiarità immediata in Drupal, e il core beneficia degli aggiornamenti di sicurezza e delle migliorie che la community di Symfony porta avanti indipendentemente.
Il componente più rilevante che Drupal eredita da Symfony è il service container: un registro centralizzato di oggetti, chiamati service, che il sistema istanzia e gestisce. Ogni funzionalità del core è un service, dall'entity manager al sistema di caching, e qualsiasi modulo può registrare i propri service o sovrascrivere quelli esistenti.
Il ciclo di una richiesta
Quando un browser chiede una pagina a Drupal, la richiesta attraversa questi strati in sequenza:
- Il server web (Apache o Nginx) riceve la richiesta e la passa a
index.php - Symfony HttpKernel prende in carico la richiesta e avvia il processo di routing
- Il router di Drupal confronta l'URL con le rotte registrate dai moduli e identifica il controller responsabile
- Il controller raccoglie i dati necessari, tipicamente interrogando l'entity system o il database
- I dati vengono passati al sistema di render, che costruisce un array di render elements
- Twig riceve l'array e produce l'HTML finale
- La risposta torna al browser, eventualmente passando per i livelli di cache
Ogni passaggio è intercettabile tramite gli event subscribers di Symfony o i hooks di Drupal, i punti di estensione che permettono ai moduli di modificare il comportamento senza toccare il core.
Il sistema di moduli
Drupal è modulare per design. Il core stesso è un insieme di moduli, alcuni obbligatori e altri opzionali. Sopra il core si trovano i moduli contrib, distribuiti su Drupal.org e installabili via Composer, e i moduli custom, scritti per un progetto specifico.
Ogni modulo può:
- Registrare nuove rotte e controller
- Definire nuovi tipi di entità o estendere quelli esistenti con campi aggiuntivi
- Dichiarare service nel container
- Implementare hook per intercettare eventi del sistema
- Fornire plugin, unità di funzionalità intercambiabili gestite dal plugin system
Il plugin system merita una menzione separata. È il meccanismo con cui Drupal gestisce famiglie di oggetti intercambiabili: i tipi di field, i formatter, i widget, i blocchi, i metodi di autenticazione sono tutti plugin. Aggiungere un nuovo tipo di campo significa scrivere un plugin che implementa l'interfaccia corretta, senza modificare nulla nel core.
Il sistema di cache
Drupal ha un sistema di cache a più livelli progettato per siti ad alto traffico. Ogni elemento renderizzato può essere associato a cache tags, identificatori che descrivono da quali dati dipende quell'elemento. Quando un nodo viene aggiornato, tutti gli elementi in cache che dipendono da quel nodo vengono invalidati automaticamente.
I cache contexts completano il quadro: permettono di variare la cache in base a parametri come l'utente corrente, la lingua, il ruolo, l'URL. Un blocco che mostra il nome dell'utente loggato ha un cache context per utente: viene cachato separatamente per ogni sessione.
Questa architettura permette a Drupal di servire pagine con contenuto personalizzato mantenendo prestazioni elevate, un problema che sistemi più semplici risolvono disabilitando la cache o costruendo workaround fragili.
Twig e il layer di presentazione
I template in Drupal sono scritti in Twig, il motore di template di Symfony. Ogni elemento dell'interfaccia, dalla pagina completa al singolo campo, ha un template Twig corrispondente che può essere sovrascritto nel tema.
Il sistema di template suggestions permette di applicare template diversi in base al contesto: un campo di tipo immagine può avere un template generico, uno specifico per il content type "Articolo" e uno ancora più specifico per il campo "Immagine in evidenza" dell'Articolo. Drupal sceglie automaticamente il template più specifico disponibile.
Headless e API-first
Da Drupal 8, il core include i moduli JSON:API e RESTful Web Services, che espongono tutti i contenuti e la configurazione tramite API standardizzate. Questo ha reso Drupal una scelta comune per architetture headless, dove il frontend è costruito con React, Next.js o qualsiasi altro framework e Drupal si occupa esclusivamente della gestione dei contenuti e della loro distribuzione via API.
Il modulo GraphQL, disponibile come contrib, aggiunge un ulteriore livello di flessibilità per chi preferisce query dichiarative alle API REST. La coesistenza di questi approcci nello stesso sistema è una delle caratteristiche che distingue Drupal dai CMS costruiti attorno a un unico paradigma di distribuzione.