A seguito un elenco di buone pratiche da seguire durante lo sviluppo.
Ambienti
Il preprod è un ambiente di anteprima da mostrare al cliente e dove il cliente può compiere dei test; pertanto le nuove soluzioni non andrebbero sviluppate in pp.
Il preprod2 lo vediamo solo noi ed è l'ambiente ideale dove sviluppare. Dato che pp2 ha una memoria più limitata di pp, si sconsiglia di importare la cartella /files.
Installazione moduli
Per l'installazione di un nuovo modulo è bene seguire questi passaggi:
- si installa il modulo in una copia del sito in locale e ci si accerta che il modulo funzioni correttamente e non crei conflitti;
- si installa il modulo in un branch del basecode e si fa il suo deploy in pp2. A fine test si elimina il branch;
- si installa il modulo nel master del basecode e si fa il suo deploy in pp.
Quindi, se va tutto bene ed il cliente ci ha dato l'ok, si fa il deploy in prod.
Non bisogna installare moduli in pp usando un diverso branch, perchè lascierebbe degli strascichi nel database e si correrebbe il rischio di avere dei conflitti. Se succede, si fa il dump del database di produzione in preprod.
Nel caso il cliente rifiuti il modulo, lo si disabilita e poi si prova a rimuoverlo dal codice usando Composer; ad esempio per eliminare il modulo Pathauto si esegue:
composer remove drupal/pathauto
Temi
Quando si crea un sottotema (ad esempio unime_fed), non occorre ereditare le librerie presenti nel file .info.yml del tema originale (ad esempio unime_base), perchè queste vengono ereditate in automatico.
Importazione moduli fra Composer
Quando si importano i moduli da un composer.json all'altro, controllare che la chiave ""minimum-stability" coincida in entrambi; diversamente alcuni moduli potrebbero non venire installati. ad esempio:
"minimum-stability": "dev"
Aggiornamento core
Dopo avere aggiornato il core, si deve eseguire
drush update db
Ribaltamento prod in pp
Si disattivano i seguenti moduli:
- Matomo e/o Analytics
- Purge (e relativi moduli)
Si rimuove la compressione dei file JS e CSS andando alla pagina /admin/config/development/performance.
Cartella /tmp
La cartella /tmp deve essere sul filesystem condiviso, al percorso sites/[nome_sito]/files/tmp (e non su /tmp, che rimane locale al webserver che sta servendo la risposta in quel momento), perchè può capitare (anche se non usuale) che il processo, ad esempio, di upload di un file inizi su un webserver e che il batch sia servito da un altro, con la conseguenza che non riuscirà a trovare il file temporaneo da salvare essendo sull'alto server.
Quindi nel file settings.php va riportato:
$settings["file_temp_path"] = "sites/[nome_sito]/files/tmp";
Template
Come base per un nuovo template, si utilizza il contenuto del relativo file .html.twig contenuto in core/modules/.
Nel caso però che il tema su cui si sta lavorando sia basato sul tema Bootstrap Barrio, se l'entità ha un corrispettivo template Bootstrap, si utilizza quello. Ad esempio se il tema custom si basa su Bootstrap Barrio, il template node caricato da Drupal è quello contenuto in bootstrap_barrio/templates/content/node.html.twig, non quello in core/modules/system/templates/page.html.twig.
Shield
Meglio non modificare lo shield in pp, in quanto anche gli Atenei ne hanno le credenziali.