Un nuovo tema
 con Drupal 8

Ovvero come iniziare un nuovo progetto senza dover reinventare la ruota.

Copertina Drupal 8

Introduzione

L’obiettivo di questa ricerca è quello di creare un tema di base per nuovi siti Drupal 8.
 Avere un punto di partenza comune, con linee guida definite per la strutturazione dei file e alcuni componenti base, contribuirebbe ad ottenere diversi vantaggi quali:

  • Minore effort nelle fasi iniziali di impostazione del progetto
  • Condivisione di un metodo nel theming dei progetti Drupal
  • Risparmio di tempo nei processi di onboarding e nei passaggi di consegne

Ritrovare le stesse strutture, lo stesso approccio alla realizzazione di nuove funzionalità e la stessa organizzazione dei file nella cartella di tema, sarebbe lo scenario ideale per tutti gli addetti ai lavori.
Il punto di arrivo di questa ricerca è ambizioso, solo inoltrandomi nell’analisi e nello sviluppo vero e proprio mi sono reso conto di tutte le variabili in gioco e delle complessità reali. La varietà dei progetti e delle possibili esigenze dei clienti, mi ha portato a comprendere meglio la dimensione di questa ricerca e a suddividerla in più fasi.
In questi mesi ho affrontato una prima fase concentrando i miei sforzi su:

  1. Installazione e configurazione iniziale dell’ambiente
  2. Impostazione iniziale del tema di base
  3. Realizzazione di componenti generici

Il sito Drupal con il tema applicato è visibile all’indirizzo:
 http://dev.andreadlabarile.it/hinto-theme

1. Installazione e configurazione

Nonostante questo processo non fosse al centro degli obiettivi di studio di questa ricerca, ho trovato molto utile e interessante approfondire il discorso Docker/Drupal (https:// wodby.com/docs/stacks/drupal/local). Una volta impostato l’ambiente (non senza fatica), ho cercato di individuare delle pratiche di base da svolgere su una nuova installazione Drupal. Una sorta di check-list per l’inizializzazione di un progetto.

Moduli Drupal

Una nuova installazione Drupal si porta dietro tutta una serie di moduli che generalmente non utilizziamo. La prima cosa da fare, una volta accertato che non li utilizzeremo, è disinstallarli. Ecco una lista sommaria di questi moduli:

  • Color
  • Comment (per farlo è necessario eliminare prima il campo commenti nel ct article)
  • Help
  • History
  • Search (se non serve la ricerca di default o ne è prevista una con Search API e/o Solr)
  • Tour

Una volta rimossi i moduli core inutilizzati, possiamo pensare a quelli che non sono presenti di default, ma che utilizzeremo quasi sicuramente. Ecco una lista con alcuni di questi moduli:

  • Admin toolbar: Per un menù di amministrazione dropdown
  • Block class: Per dare classi personalizzate ai blocchi
  • Field collections: Per creare insiemi di campi
  • Paragraphs: Per la creazione di componenti dinamici
  • Pathauto: Per la gestione delle url
  • Twig tweak: Per estendere le funzionalità di Twig e facilitare la gestione dei template
  • Devel: Per il debugging del tema e non solo

Layout dei blocchi

Ogni nuova installazione Drupal offre elementi di base (logo, menù principale, messaggi di stato, menù utente, login form, ecc..) in blocchi già inseriti in particolari regioni del tema (approfondimento sulle regioni). Siccome nel nostro tema andremo a creare una nuova struttura, probabilmente con regioni diversamente organizzate e blocchi personalizzati, il prossimo passo sarà la rimozione di tutti i blocchi di default dalle varie regioni, ad eccezione dei seguenti:

  • Messaggi di stato: Feedback di sistema
  • Schede: Tab per la gestione contestuale dei contenuti
  • Contenuto della pagina principale: Il contenuto di ogni pagina

In questo modo ci ritroveremo in una situazione ideale per andare a impostare il nostro tema.

2. Impostazione del tema

Studiando la documentazione ufficiale per il theming in Drupal 8, ho creato un nuovo tema con nome “hinto”, con la seguente struttura dei file e delle cartelle:

-  hinto 
  -  css
  -  images
  -  js
  -  scss
  -  templates - vendor
  -  hinto.info.yml
  -  hinto.libraries.yml
  -  hinto.theme
  -  screenshot.png
  -  logo.svg

Le regioni e il file *info.yml

Questo file è il punto di partenza. In base al prototipo del nostro nuovo sito, dovremo individuare una struttura e suddividerla in regioni. Una volta definite tutte le possibili regioni del nostro sito le andremo ad indicare nel file hinto.info.yml con la seguente sintassi:

regions:
  page_top: 'Page top'
  page_bottom:  'Page bottom'
  top_bar: 'Top'
  logo:  'Logo'
  menu: Menu'
  header:  'Header'
  preface:  'Preface'
  content: 'Content'
  sidebar_left: 'Sidebar Left'
  sidebar_right: 'Sidebar Right'
  postscript: 'Postscript'
  footer: ‘Footer'

Le regioni Page top, Page bottom e Content dovranno sempre essere presenti, le altre sono a nostra discrezione, possiamo modificarne i nomi o creare nuove regioni.

La definizione delle regioni in questo file si riflette poi nella gestione del layout dei blocchi di Drupal. Potremo quindi andare a posizionare i vari blocchi con funzionalità e componenti all’interno delle regioni create. Con i templates, in un secondo momento, potremo creare la struttura HTML della pagina posizionando le varie regioni a nostro piacimento.

I templates twig

Nella cartella templates sono contenuti i file con il markup html di quasi tutti gli elementi presenti nel sito. Nel nostro tema di base ho strutturato le cartelle in questo modo:

- templates
  - block
  - content
  - field
  - field-collection
  - form
  - layout
  - misc
  - paragraphs
  - views

Ogni cartella contiene il template di base rispetto all’elemento indicato dal nome della cartella e le variazioni di tali elementi. Per questo tema ho recuperato e realizzato dei template di base con le informazioni minime indispensabili.
Ho cercato di ridurre al minimo la presenza di tag HTML e classi superflue.

Il template più importante, quello con cui definiremo la struttura del layout della mia pagina con le varie regioni, è page.html.twig all’interno della cartella layout.

Al suo interno avremo la massima libertà per la creazione della struttura. In questo caso ho impostato il layout utilizzando le classi di Bootstrap.

Bootstrap ma non troppo

Bootstrap è senza dubbio uno dei framework HTML/CSS/JS più utilizzati al mondo.
Nonostante rappresenti senza dubbio un supporto molto utile e talvolta necessario, presenta a mio avviso alcuni problemi:

  • Si porta dietro tutta una serie di funzionalità, impostazioni e regole che spesso non vengono neanche utilizzate e talvolta creano conflitti con funzionalità custom.
  • Spesso le richieste del cliente non coincidono esattamente con ciò̀ che il framework ci offre, allora ci ritroviamo a sovrascrivere malamente i componenti per adattarli, creando agglomerati mostruosi di classi, markup sporco e abusi di !important.

Mi sono reso conto che a volte molti progetti, pur basandosi sull’intero framework di Bootstrap, fanno uso di una sola, utilissima funzionalità: il sistema a griglia (https:// getbootstrap.com/docs/4.0/layout/grid/).
Basandomi su questa idea ho estrapolato una versione ridotta di Bootstrap 4 e ho inserito nel tema solo le regole per le impostazioni della griglia.

Una volta definite le regioni in base al prototipo e impostata la struttura della pagina con le regole per le griglie, mi sono occupato dell’organizzazione dei file SCSS.

SMACSS e BEM, non sono parolacce

In questi anni di lavoro come front-end, ogni volta che mi sono trovato a lavorare su un progetto già avviato, ho dovuto spendere tempo ed energie per comprendere la struttura dei fogli di stile esistenti (SASS, LESS o CSS puro).
Ogni volta mi sono sforzato di entrare nella mente del povero diavolo che mi ha preceduto per capire la logica (o talvolta l’assenza di questa) dietro all’organizzazione dei file e delle regole.

Individuare una metodologia condivisa per l’impostazione di struttura e regole per i fogli di stile è sicuramente un passo da compiere per migliorare il nostro lavoro.

Per il tema base sul quale ho lavorato ho scelto di adottare delle versioni leggermente rivisitate di SMACSS e BEM.

SMACSS (Scalable and Modular Architecture for CSS)

SMACSS è un approccio popolare e modulare per la gestione dei CSS su siti di grandi dimensioni basato sul concetto di “riutilizzo, riduzione e riciclo”. La base di SMACSS è la categorizzazione delle regole CSS. Partendo da questa metodologia e applicandola ad un caso d’uso con un sito Drupal, ho elaborato la seguente struttura di file e cartelle:

-  scss
   -  base
   -  components
   -  layout
   -  _variables.scss
   -  _mixins.scss
   -  base.scss
   -  components.scss
   -  layout.scss

  • Cartella base: Contiene tutti i file con regole per gli elementi html di base (titoli, paragrafi, link, liste, form). Questi file vengono poi richiamati e accorpati nel file base.scss
  • Cartella components: Contiene tutti i file con regole per i componenti del nostro sito. All’interno di questa cartella posso fare una suddivisione ulteriore tra i componenti globali e quelli specifici legati a determinati contesti. Ad esempio, in questa base ho creato una cartella paragraphs all’interno di components, nella quale ho inserito un file per ogni componente creato con il modulo paragraphs. Tutti questi file vengono poi richiamati e accorpati nel file components.scss
  • Cartella layout: Contiene tutti i file con regole relative al layout e alla struttura. Non dovrebbe contenere regole legate all’aspetto prettamente visual (colori e tipografia), ma solo indicazioni sulla struttura e sulla gestione degli spazi. In questa cartella ci sono i file con le regole estrapolate da bootstrap per la gestione del layout. Questi file vengono richiamati e accorpati nel file layout.scss.

Nei file _variables.scss e _mixins.scss sono inserite tutte le nostre variabili di base (font, colori, breakpoints) e i mixin da noi creati. Questi file non verrano convertiti in CSS, sono solo utilità per gli chi dovrà scrivere le regole.

Utilizzando un task manager (in questo caso Gulp.js) per la compilazione dei file SCSS, all fine avremo tre file CSS (base, layout e components) che verranno incorporati nella libreria globale del nostro tema tramite il file hinto.libraries.yml.

global:
   version: VERSION
   css:
       base:
           css/base.css: {}
       layout:
          css/layout.css: {}
       component:
            css/components.css: {}

BEM (Block Element Modifier)

Una volta determinata una struttura per i file di stile, ho cercato un metodo per rendere più leggibile il codice. Così è entrato in gioco BEM.
L’idea alla base della metodologia BEM è quella di definire alcune regole per la definizione delle classi degli elementi basandosi sulle proprietà degli elementi stessi. La definizione delle classi si basa su tre componenti: il blocco, l’elemento e la variante.

  • Blocco: Da non confondere con i blocchi Drupal, è il contenitore o il contesto in cui l’elemento si trova. È un' entità indipendente che può essere semplice o composta da ulteriori blocchi. Un esempio di blocco può essere il menù di navigazione principale oppure il footer:

.main-menu{}

.footer{}

  • Elemento: L’elemento è un singolo componente inserito in un blocco. La classe di ogni elemento viene definita da un nome semplice, chiaro e univoco preceduto dal blocco e da due underscore. Portando avanti l’esempio precedente potremmo prendere in considerazione una voce del menu di navigazione principale oppure un elemento secondario del footer:

.main-menu__item{}

.footer__box{}

  • Variante: L’ultimo componente da valutare è la variante che definisce versioni differenti di un elemento. La variante andrà specificata come terzo parametro della classe e verrà separata dall’elemento con due trattini. Una voce di menu attiva o un elemento del footer con un colore diverso sono esempi concreti:

.main-menu__item--active{}

.footer__box--dark{}

Ecco un esempio di come la metodologia BEM può essere utilizzata con SASS:


 .main-menu{
    margin:0;
          &__item{
              display:inline-block;
              padding:0.5em  1em;
                   &--active{
                     color:#660000;
                   }
           }
 }

3. Realizzazione componenti

Non esiste un solo metodo per gestire o creare nuovi componenti per un sito realizzato con Drupal. La grande flessibilità di questo CMS e la varietà di moduli messi a disposizione dalla comunità Drupal in tutto il mondo, rendono arduo il compito di trovare un approccio condiviso e standardizzato.

In questa prima fase di ricerca ho ristretto il focus e ho provato ad individuare e realizzare alcuni componenti generici, riutilizzabili nell’ambito di siti web istituzionali o corporate.

Ma cosa si intende per “componenti”? Per dare una definizione al termine, ci torna utile la metodologia Atomic Design.

Atomic Design, molecole, organismi e componenti

Creata da Brad Frost nel 2013, l'Atomic design è una metodologia composta da 5 fasi, utile per creare un sistema di interfacce in maniera gerarchica.

Atomic Design, molecole, organismi e componenti

Le tre fasi iniziali sono quelle che ci interessano per la definizione di un componente del nostro nuovo tema: Atomi, Molecole e Organismi.

  • Atomi: Sono gli elementi fondamentali dell’interfaccia, la particella più piccola nella scala. Comprendono elementi HTML come tipografia, palette colori, input, bottoni e altri elementi che non possono essere suddivisi ulteriormente senza cessare di essere funzionali.
  • Molecole: Sono semplici gruppi di elementi d'interfaccia che funzionano uniti. Quando combiniamo due atomi, creiamo quindi una molecola.
  • Organismi: Sono elementi più o meno complessi, composti da gruppi di molecole e/o atomi. Creano diverse sezioni all'interno della nostra interfaccia.

Un componente del nostro tema è quello che in Atomic Design verrebbe definito Organismo.

Consideriamo come primo componente l’header del nostro sito:

Header

Possiamo suddividere questo componente in due elementi: il logo e il menù primario.
Possiamo considerare il logo come un atomo, mentre il menu come molecola. Quest’ultimo può infatti essere suddiviso in più atomi, rappresentati dalle singole voci di menù.

  • Logo: Per una maggiore libertà nella gestione di possibili microinterazioni legate al logo, ho creato un blocco
    personalizzato nel quale ho inserito il codice SVG del logo, ripulendolo e applicando classi coerenti.
  • Menù primario: In ottica di futuri sviluppi o richieste del cliente che prevedano una funzionalità dropdown, per questo menù ho sfruttato il modulo Superfish che permette di estendere le funzionalità del menu per diversi device.

Per la funzionalità sticky header e l'adattamento della componente in base allo scroll, ho sfruttato la libreria ScrollMagic.js. Scrollando la pagina, superata una certa soglia, l’header si restringe e diventa trasparente. Questa funzionalità è solo un esempio, i comportamenti dell’header e di qualsiasi elemento in base allo scroll sono personalizzabili con poche righe di CSS e jQuery o Javascript. Il limite è la creatività del designer (e il buon senso).

Se per questo componente ho sfruttato soltanto le funzionalità dei blocchi Drupal e i template TWIG per la gestione del layout, per gli altri ho utilizzato il modulo Paragraphs.

Componenti funzionali e narrative

Facciamo prima una distinzione tra componenti funzionali e narrative.

Componenti funzionali

  • Sono orientate allo svolgimento di uno o più task da parte dell’utente
  • Prevedono un’interazione più o meno complessa con l’utente
  • Sono più difficili da sviluppare e spesso richiedono un supporto backend
  • Difficilmente personalizzabili dal cliente

Esempi: stepper, webform di qualsiasi tipo, widget per la configurazione di un prodotto in un sito e-commerce.

Componenti narrative

  • Hanno una funzione prettamente visuale o di fruizione di contenuti
  • Prevedono un’interazione semplice ho la sola lettura da parte dell'utente
  • Sono più o meno facili da sviluppare con poche conoscenze tecniche
  • Si possono rendere dinamiche con più semplicità

Esempi: slideshow, blocchi di testo con immagini e links.

Tre componenti narrativi

Per iniziare ho creato tre componenti narrativi, quasi completamente dinamici, con il modulo Paragraphs.

1. Immagine laterale affiancata da un titolo, un testo e un link

Questo componente permette di aggiungere una o più immagini, un titolo, un testo formattato e un link esterno o interno al sito. Se si sceglie di inserire più di una immagine il sistema le organizza automaticamente in uno slideshow (realizzato con la libreria Swiper.js). Si può inoltre scegliere l’ordine nella disposizione degli elementi, per creare così un’alternanza dei pesi nel flusso visivo della pagina.

Immagine laterale affiancata da un titolo, un testo e un link

2. Immagine di sfondo con titolo, testo e link sovrapposti

Questo componente permette di aggiungere una immagine di sfondo, un titolo, un testo formattato e un link esterno o interno al sito. È possibile scegliere il layout di questo componente:

- Full width: la larghezza dello sfondo è pari all’intera finestra browser
- Container width: il componente è allineato al resto dei contenuti

Immagine di sfondo con titolo, testo e link sovrapposti

3. Titolo sezione e griglia blocchi 

Questo componente risponde ad una necessità molto comune, quella di organizzare blocchi di contenuto in più colonne affiancate o in un sistema a griglia, tutto in maniera dinamica e gestibile con semplicità senza scrivere codice. In ogni blocco che andrà a comporre la griglia è possibile inserire un’immagine, una label, un breve testo formattato e un link. Si può aggiungere un numero qualsiasi di blocchi di questo tipo e definire quanti blocchi dovranno esserci per ogni riga. Infine è possibile scegliere un titolo per la sezione.

Questa sezione è super dinamica

Conclusioni e sviluppi futuri

Drupal, grazie alla sua flessibilità alle sue molteplici estensioni, offre strade diverse per la soluzione di un determinato problema. Ciò che più conta nel nostro caso, non è trovare la soluzione più brillante, ma individuare un metodo condiviso per la gestione di dinamiche che possono riproporsi in più progetti.

Un punto molto interessante è senza dubbio quello che riguarda le gestione del tema, sia a livello di organizzazione dei file e delle cartelle, sia per le metodologie di scrittura delle regole di stile. Oltre a SMACSS e BEM, esistono altre metodologie che possiamo prendere in considerazione per trovare la nostra strada.

Gli sviluppi futuri di questa ricerca sono molteplici:

  • Prendere in considerazione altre metodologie di gestione dei CSS e analizzarle
  • Creare una sorta di libreria aperta di componenti narrativi  in continua evoluzione
  • Gettare le basi per la gestione di un design system creando una style guide con tutti gli elementi a partire dagli atomi
  • Integrare il tema con un modulo che contenga le configurazioni utili e che crei contenuti di base sui quali poter personalizzare l'interfaccia


Fonti

Se vuoi saperne di più 👉 contattaci