Flux RSS Kgaut.NET

Uzinasit : retour d'expérience sur mon usine à site Drupal 11

kgaut — Fri, 29 May 2026 12:18:28 +0200

J'ai profité d'avoir un peu de temps durant l'été 2025 pour commencer à rationaliser l'ensemble de mes sites histoire de m'en simplifier la gestion

Pourquoi une site factory ?

Au fil des années, j'ai accumulé des sites Drupal mais aussi d'autres CMS (Wordpress, Joomla), certains pour moi (celui-là, des outils métiers comme mon dashboard de projets, des sideprojects comme mon site de photos de drone.) Mais aussi des sites pour des activités pro d'amis ou membres de la famille.

Le problème quand on a douze sites indépendants, c'est que la maintenance devient compliquée et chronophage... Certains joomla n'étaient plus du tout à jour, plus upgradable, idem pour des wordpress... j'avais encore des drupal 8... un beau bazar.

J'ai donc construit Uzinasit, ma propre "Usine à site" Drupal : une seule base de code, un seul composer.json, plusieurs bases de données, des configs Drupal isolées par site. Du multi-site Drupal natif, mais industrialisé avec mes propres outils autour (Lando pour le dev local, GitLab CI pour le déploiement, une commande Drush maison pour scaffolder un nouveau site en deux minutes).

Aujourd'hui, ajouter un site se résume à drush uzc. Mettre à jour Drupal core sur les douze sites se fait en un composer update et un git push. C'est de cette mécanique dont je veux parler dans cet article.

Au programme :

La vue d'ensemble de l'architectureComment une seule codebase Drupal sert douze sitesL'environnement de dev local avec LandoLes scripts spécifiques qui me font gagner un temps fouLa commande drush uzc pour ajouter un siteLe déploiement via GitLab CI (matrix sur les sites)Le workflow de mise à jour Drupal (le vrai gain)1. Vue d'ensemble de l'architecture

Avant de plonger, un schéma simplifié de l'infra :

┌─ Un repo Git (uzinasit) ─────────────────────────────┐
│                                                       │
│  web/                                                 │
│   ├── core/  + contribs (gérés par Composer)          │
│   ├── modules/<site>/   (1 module custom par site)    │
│   ├── themes/<site>/    (thèmes propres à chaque site)│
│   └── sites/                                          │
│        ├── sites.php          (hostname → dossier)    │
│        ├── settings-shared.php  (le cœur !)           │
│        ├── kgaut/settings.php                         │
│        ├── dashboard/settings.php                     │
│        ├── drone/settings.php                         │
│        └── …                                          │
│                                                       │
│  scripts/        (db-sync, deploy-code, …)            │
│  drush/sites/    (alias Drush par site)               │
│  .lando.yml      (stack Lando dev local)              │
│  .gitlab-ci.yml  (pipeline CI/CD)                     │
└───────────────────────────────────────────────────────┘
              │                          │
              ▼                          ▼
        ┌────────────┐            ┌────────────┐
        │   LANDO    │            │    PROD    │
        │ 12 DBs     │            │ 12 DBs     │
        │ Redis      │            │ Redis      │
        │ Mailpit    │            │ Sentry     │
        │ PMA        │            │ Backups    │
        └────────────┘            └────────────┘

Les briques principales :

Drupal 11 en mode multi-site natif (web/sites/<dossier>/).Composer pour gérer le code : un seul composer.json, un seul composer.lock, donc une version unique de Drupal et de chaque contrib pour tous les sites.Lando (surcouche de docker) pour le dev local : 1 service appserver, 12 services MariaDB, du Redis, du Mailpit, du PhpMyAdmin.GitLab CI pour le déploiement, avec une matrix qui parallélise les jobs sur tous les sites.Drush + des alias par site, pour cibler @kgaut, @dashboard, @drone… aussi bien en local qu'en prod.Sentry pour le monitoring (un projet par site).2. L'infra Drupal - comment une même codebase sert une douzaine de sites

Drupal supporte le multi-site nativement depuis très longtemps. Le mécanisme est simple : selon l'URL de la requête, Drupal cherche un dossier web/sites/<quelque-chose>/ contenant un settings.php, et utilise les paramètres de ce fichier (base de données, fichiers, config…) pour cette requête. Toute la magie d'Uzinasit consiste à rendre ce mécanisme industrialisable.

2.1 sites.php - router les hostnames vers les dossiers

Premier fichier clé, web/sites/sites.php. C'est lui qui mappe les URL aux dossiers de sites :

<?php

$sites['kgaut.net'] = 'kgaut'; // URL PROD
$sites['kgaut.lndo.site'] = 'kgaut'; // URL LOCALE

$sites['drone.kgaut.net'] = 'drone';
$sites['drone.lndo.site'] = 'drone';

// … etc, une entrée par environnement, par site

Pour chaque site j'ai au minimum deux entrées (URL prod + URL locale .lndo.site), parfois trois (URL preprod). Tout cela pointe vers le même dossier Drupal, qui contient les paramètres spécifiques au site.

2.2 Le fichier settings.php minimaliste

Tous les settings.php de tous les sites font exactement la même chose. Quatre lignes utiles, pas une de plus. Exemple web/sites/kgaut/settings.php :

<?php

$siteFolder = 'kgaut';
$siteFolderUp = strtoupper($siteFolder);
require $app_root . '/sites/settings-shared.php';
if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) {
  include $app_root . '/' . $site_path . '/settings.local.php';
}

C'est tout. Pour le site dashboard, c'est strictement identique, sauf que $siteFolder = 'dashboard'. Toute la configuration réelle est centralisée dans settings-shared.php. C'est ce fichier qui fait le vrai boulot.

2.3 settings-shared.php - le cœur de l'usine

Ce fichier est inclus par les douze settings.php, et il configure dynamiquement Drupal en fonction du $siteFolder qui lui est passé. Voici les parties intéressantes (La partie classique du settings.php n'est pas affichée ici, mais présente dans le fichier) :

Connexion DB à partir d'env vars :

$databases['default']['default'] = [
  'database'         => getenv($siteFolderUp . '_DB'),
  'username'         => getenv($siteFolderUp . '_USER'),
  'password'         => getenv($siteFolderUp . '_PWD'),
  'host'             => getenv($siteFolderUp . '_HOST'),
  'port'             => '3306',
  'isolation_level'  => 'READ COMMITTED',
  'driver'           => 'mysql',
  'namespace'        => 'Drupal\\mysql\\Driver\\Database\\mysql',
  'autoload'         => 'core/modules/mysql/src/Driver/Database/mysql/',
];

Pour le site kgaut, récupération des variables d’environnement KGAUT_DB, KGAUT_USER, KGAUT_PWD, KGAUT_HOST. Pour dashboard, c'est DASHBOARD_DB, etc. Un nouveau site : on ajoute 4 lignes dans .env.

Fichiers privés, tmp, config sync, isolés par site :

$settings['file_private_path']     = '../files/' . $siteFolder . '/private';
$settings['file_temp_path']        = '../files/' . $siteFolder . '/tmp';
$settings['config_sync_directory'] = '../files/' . $siteFolder . '/config/sync';

Chaque site a ses propres dossiers files/<site>/{private,tmp,config,dumps}. Aucun risque qu'un site écrive dans les fichiers d'un autre.

Redis optionnel, activé par site :

$redisKey = $siteFolderUp . '_REDIS_ENABLED';
if (getenv($redisKey) && (bool) getenv($redisKey) === TRUE) {
  $settings['redis.connection']['host']      = getenv('REDIS_HOST');
  $settings['redis.connection']['port']      = getenv('REDIS_PORT');
  $settings['redis.connection']['interface'] = getenv('REDIS_INTERFACE');
  $settings['container_yamls'][]             = DRUPAL_ROOT . '/sites/redis.services.yml';
  $settings['cache']['default']              = 'cache.backend.redis';
  $settings['cache_prefix']['default']       = $siteFolder . '_';
}

Le préfixe de cache est dérivé de $siteFolder, donc deux sites peuvent partager la même instance Redis sans collision. Les sites qui en ont besoin (typiquement le dashboard, très sollicité) activent Redis via DASHBOARD_REDIS_ENABLED=true dans le .env. Les petits sites qui n'en ont pas besoin tournent sur cache base de données classique.

Sentry par site :

if (getenv($siteFolderUp . '_SENTRY_DSN')) {
  $_SERVER['SENTRY_DSN'] = getenv($siteFolderUp . '_SENTRY_DSN');
}

Chaque site a son propre projet Sentry. Quand kgaut.net lève une exception, je la vois remonter dans le projet Sentry kgaut, pas dans celui du dashboard.

Indicateur d'environnement :

if (getenv('APP_ENV')) {
  $environements = [
    'dev'     => ['name' => 'dev',     'bg_color' => '#006600', 'fg_color' => '#ffffff'],
    'preprod' => ['name' => 'Staging', 'bg_color' => '#FF9900', 'fg_color' => '#000000'],
    'prod'    => ['name' => 'Prod',    'bg_color' => '#ef5350', 'fg_color' => '#000000'],
  ];
  if (isset($environements[getenv('APP_ENV')])) {
    $config['environment_indicator.indicator'] = $environements[getenv('APP_ENV')];
  }
}

Combiné avec le module environment_indicator, ça m'affiche un bandeau vert en dev, orange en preprod, rouge en prod dans l'admin Drupal. Basique, mais ça évite les erreurs du « oups je viens de faire la modif en prod au lieu du local ».

Config split par environnement :

$config["config_split.config_split.".getenv("APP_ENV")]["status"] = TRUE;

J'ai des splits config_split.dev, config_split.preprod, config_split.prod qui activent ou désactivent automatiquement des modules selon l'env (par exemple devel en dev seulement).

Et en dev seulement, on charge les services de développement et on route les mails vers Mailpit :

if (getenv('APP_ENV') && getenv('APP_ENV') === 'dev') {
  $settings['container_yamls'][] = DRUPAL_ROOT . '/sites/development.yml';
  $config['system.logging']['error_level']                = 'verbose';
  $config['symfony_mailer.settings']['default_transport'] = 'mailpit';
}

Tout ça est dans un seul fichier, qui sert les douze sites. Quand j'ajoute une nouvelle fonctionnalité de configuration partagée (ex: ajouter un Sentry, routage des mails), il bénéficie automatiquement à tous les sites.

2.4 Le .env, la config par site

APP_ENV='dev'

KGAUT_USER="drupal11"
KGAUT_PWD="drupal11"
KGAUT_HOST="database_kgaut"
KGAUT_DB="kgaut"
KGAUT_SENTRY_DSN="https://…@sentry.io/…"

DASHBOARD_USER="drupal11"
DASHBOARD_PWD="drupal11"
DASHBOARD_HOST="database_dashboard"
DASHBOARD_DB="dashboard"
DASHBOARD_REDIS_ENABLED=true
DASHBOARD_SENTRY_DSN="https://…@sentry.io/…"

REDIS_HOST=redis
REDIS_PORT=6379
REDIS_INTERFACE=PhpRedis

En dev, tous les sites partagent le même utilisateur MySQL drupal11/drupal11. En prod, j'ai un utilisateur MySQL distinct par base, avec un mot de passe distinct, pour une isolation plus forte.

2.5 Les alias Drush - pouvoir cibler chaque site en CLI

Pour cibler un site en ligne de commande, Drush utilise des alias. J'ai un fichier drush/sites/<site>.site.yml par site, par exemple drush/sites/kgaut.site.yml :

dev:
  root: /app
  uri: https://kgaut.lndo.site

2.6 Modules custom - un par site, un mutualisé

L'organisation des modules est claire :

web/modules/<site>/ : module propre à chaque site, contient le code métier spécifique (par exemple web/modules/dashboard/ contient le code de mon site de suivi de projet, web/modules/dronestagram/ contient mon module pour mon site de photos drones).

Côté thèmes, même logique, chaque site a son thème.

3. L'infra Lando pour le dev local

Pour faire tourner les douze sites en local, j'utilise Lando. C'est une surcouche sur Docker qui simplifie énormément la déclaration de stacks de dev, avec une configuration YAML lisible et des « recipes » toutes faites (Drupal 11 inclus).

L'alternative serait un docker-compose.yml à la main. Lando me donne en plus :

Un proxy automatique qui résout les domaines .lndo.site en HTTPS valide (certificat auto-signé installé dans le store du système)Une notion de « tooling » qui définit des commandes haut niveau (lando drush, lando phpstan…)3.1 Le .lando.yml - la stack complète

Voici le squelette de mon .lando.yml (j'ai raccourci la partie services DB) :

name: uzinasit
recipe: drupal11
config:
  webroot: web

proxy:
  appserver:
    - kgaut.lndo.site
    - dashboard.lndo.site
    - drone.lndo.site
    ...
  mailpit:
    - 'mail.lndo.site:8025'
  pma:
    - pma.lndo.site

services:

  node:
    type: 'node:22'
    ssl: true
    sslExpose: true
    portforward: 4444

  mailpit:
    api: 3
    type: lando
    services:
      image: axllent/mailpit
      ports: [8025, 1025]
      environment:
        MP_MAX_MESSAGES: 5000
        MP_SMTP_AUTH_ACCEPT_ANY: 1

  cache:
    type: redis
    persist: true
  redis:
    type: 'redis:5'

  pma:
    type: phpmyadmin
    hosts:
      - database_kgaut
      - database_dashboard
      - database_drone
      # … les 12

  database_kgaut:
    type: 'mariadb:10.11'
    portforward: true
    creds: { user: drupal11, password: drupal11, database: kgaut }
  database_dashboard:
    type: 'mariadb:10.11'
    portforward: true
    creds: { user: drupal11, password: drupal11, database: dashboard }
  # … etc, une entrée par site

Les points à noter :

Node est un service à part, utilisé pour les builds front (SASS, gulp...)Mailpit capture tous les mails envoyés en dev — visible sur mail.lndo.site:8025.Une base MariaDB 10.11 par site. PhpMyAdmin centralise l'accès aux douze bases sur pma.lndo.site.3.2 Pourquoi douze bases différentes plutôt qu'une seule avec préfixes ?

C'est un choix d'architecture. Drupal sait travailler avec des préfixes de tables (prefix dans $databases), donc on pourrait mutualiser une seule instance MariaDB. Mais j'ai choisi une instance par site, pour ces raisons :

Cohérence avec la prod : en prod chaque site est sur sa propre base, avec son propre utilisateur MySQL. Faire pareil en local évite les surprises.Isolation totale : drop database kgaut; ne touchera jamais le dashboard.Dumps simples : un fichier .sql.gz par site, qu'on importe sans réfléchir à des préfixes. Le même dump fonctionne en local et en prod.Performance : pas de mutualisation, donc pas de contention. La pause d'un dump n'impacte que le site concerné.3.3 Démarrer la stack

Une fois .env rempli :

lando start

Et voilà, douze Drupal accessibles en HTTPS sur https://kgaut.lndo.site, https://dashboard.lndo.site, etc. Ajouter un nouveau site ne demandera pas de toucher à cette config — la commande drush uzc (qu'on voit plus loin) le fera automatiquement.

4. Les scripts spécifiques - le vrai gain de productivité quotidien

Lando offre une section tooling qui permet de définir des commandes haut niveau. Toutes les commandes du tableau ci-dessous se lancent en lando <commande>, depuis la racine du projet :

Commande LandoCe qu'elle faitlando front:buildnpm i + build des thèmes (je pourrais isoler, mais j'ai choisi la simplicitélando db-export-allDump SQL horodaté de chaque base, dans files/<site>/dumps/lando drush-allExécute la même commande Drush sur les 12 sites, séquentiellementlando db-get-allRapatrie le dernier dump prod de tous les sites via SSHlando db-import-allImporte localement le dernier dump .sql.gz de tous les siteslando db-sync <site>db-get + db-import + drush deploy enchaînés pour un seul sitelando db-sync-allIdem mais pour tous les sites détectéslando phpstanAnalyse PHPStan sur les modules customlando phpcsAnalyse PHPCSlando rectorRector (refactoring automatique guidé)lando phpunitPHPUnitlando grumphpSuite complète CS + PHPStan + composer check (utilisé en hook pre-commit)4.1 db-sync - Rapatriement de la base de prod en local

Un simple :

lando db-sync dashboard

Et 30 secondes plus tard, ma base locale dashboard contient le dernier dump prod, et le drush deploy a tourné. Je suis aligné à la prod, prêt à développer.

Le script scripts/db-sync.sh est volontairement court — il orchestre deux scripts plus simples :

#!/usr/bin/env bash
set -euo pipefail

SITE="${1:-}"
DRY_RUN=false
NO_DEPLOY=false

# parse des flags --dry-run et --no-deploy
for arg in "${@:2}"; do
  case "$arg" in
    --dry-run)   DRY_RUN=true ;;
    --no-deploy) NO_DEPLOY=true ;;
  esac
done

GET_SCRIPT="./scripts/db-get.sh"
IMPORT_SCRIPT="./scripts/db-import.sh"

echo "--- Récupération du dump ---"
"$GET_SCRIPT" "$SITE" || echo "Pas de nouveau dump distant, on utilise le local."

echo "--- Import du dump ---"
IMPORT_ARGS=("$SITE")
[[ "$NO_DEPLOY" == true ]] && IMPORT_ARGS+=(--no-deploy)
"$IMPORT_SCRIPT" "${IMPORT_ARGS[@]}"

Les deux briques qu'il chaîne :

db-get.sh se connecte en SSH à mon serveur, cherche le dump .sql.gz le plus récent dans le dossier files/<site>/dumps/ distant, et le rapatrie en local via rsync (avec fallback scp si rsync absent) :

REMOTE_BASE="/home/uzinasit/public_html/files/${SITE}/dumps"
LOCAL_BASE="./files/${SITE}/dumps"

LATEST_REMOTE_FILE=$(ssh "${REMOTE_USER}@${REMOTE_HOST}" \
  "ls -1t ${REMOTE_BASE}/*.sql.gz 2>/dev/null | head -n1")

rsync -avz --progress \
  "${REMOTE_USER}@${REMOTE_HOST}:${LATEST_REMOTE_FILE}" \
  "${LOCAL_BASE}/"

db-import.sh importe le .sql.gz directement via mysql sans extraction intermédiaire (zcat | mysql), puis lance drush deploy :

MYSQL_CMD=$(drush "@$SITE" sql:connect 2>/dev/null)
zcat "$LATEST_FILE" | eval "${MYSQL_CMD} --skip-ssl"

echo "Dump importé pour $SITE"
if [[ "$NO_DEPLOY" == true ]]; then
  echo "Drush deploy ignoré (--no-deploy)"
else
  drush "@$SITE" deploy
fi

Le drush deploy est important : il importe la config Drupal locale (config:import), passe les hooks update (updatedb), reconstruit le cache. Après ça, le site local correspond exactement à l'état du code courant + les données de prod.

Les flags --dry-run (vérifier sans rien faire) et --no-deploy (importer sans lancer drush deploy) sont là pour les cas particuliers, typiquement, quand je veux la base prod mais sans réimporter le config split « dev ».

4.2 db-sync-all - Le gros reset

Si je reviens d'une semaine de vacances et que je veux remettre à plat toute mon usine locale, je lance :

lando db-sync-all

Le script découvre tout seul la liste des sites en scannant drush/sites/*.site.yml, et appelle db-sync.sh pour chacun :

mapfile -t ALIAS_FILES < <(printf '%s\n' "${DRUSH_SITES_DIR}"/*.site.yml | sort)

SITES=()
for f in "${ALIAS_FILES[@]}"; do
  alias_name="${$(basename -- "$f")%.site.yml}"
  case "$alias_name" in
    self|uzinasit|mbc) continue ;;  # skip les techniques
    *) SITES+=("$alias_name") ;;
  esac
done

echo "Sites détectés (${#SITES[@]}): ${SITES[*]}"

for site in "${SITES[@]}"; do
  if "$SYNC_ONE_SCRIPT" "$site" "${EXTRA_ARGS[@]}"; then
    SUCCESS=$((SUCCESS + 1))
  else
    FAILED=$((FAILED + 1))
  fi
done

echo "Résumé sync-all: ${SUCCESS} succès, ${FAILED} échec(s)."

Quand j'ajoute un nouveau site avec drush uzc, son alias drush/sites/<site>.site.yml est créé automatiquement → il est inclus automatiquement au prochain db-sync-all. Aucune liste à maintenir nulle part.

5. Ajouter un nouveau site avec drush uzc

Ajouter un nouveau site dans Uzinasit demande sept modifications de fichiers dans le bon ordre :

web/sites/sites.php (mapping hostname → dossier)drush/sites/<alias>.site.yml (alias Drush).lando.yml (service MariaDB, proxy, PMA, tooling…).env (4 variables)files/<alias>/ (création des dossiers)web/sites/<alias>/ (settings.php + services.yml).gitlab-ci.yml (ajout dans la matrix)

J'ai fait ça a la main quelques fois, et j'en ai eu marre, oubli, perte de temps...

J'ai donc écrit une commande Drush qui fait tout ça automatiquement. Elle vit dans drush/Commands/uzinasit/CreateCommand.php et s'appelle drush uzinasit:create, alias drush uzc.

Le déroulé interactif :

$ drush uzc
Enter the site alias (e.g., ulm) [ulm]: monnouveausite
Enter the local URL (must end with .lndo.site) [monnouveausite.lndo.site]:
Enter the production URL (without the procol) [monnouveausite.uzinasit.kgaut.net]: monnouveausite.kgaut.net

 Site Information
 ────────────────
 ┌────────────────┬───────────────────────────────────┐
 │ Parameter      │ Value                             │
 ├────────────────┼───────────────────────────────────┤
 │ Site Alias     │ monnouveausite                    │
 │ Local URL      │ monnouveausite.lndo.site          │
 │ Production URL │ monnouveausite.kgaut.net          │
 └────────────────┴───────────────────────────────────┘

 Do you want to create this site? (yes/no) [yes]:

Updating sites.php... ✅ sites.php updated.
Creating Drush alias file... ✅ Drush alias file created.
Updating .lando.yml... ✅ .lando.yml updated.
Updating .env file... ✅ .env file updated.
Creating site files directory... ✅ Site files directory created.
Creating site configuration directory... ✅ Site configuration directory created and settings.php updated.
Updating .gitlab-ci.yml... ✅ .gitlab-ci.yml updated with new site alias.

[OK] Site 'monnouveausite' has been successfully created!

Sous le capot, la commande utilise Symfony\Component\Yaml\Yaml pour lire/écrire .lando.yml et .gitlab-ci.yml proprement. Voici l'extrait qui modifie le .lando.yml pour ajouter le service MariaDB et le tooling associé :

$landoYml = Yaml::parseFile($landoYmlPath);

// Ajoute l'URL locale au proxy appserver
$landoYml['proxy']['appserver'][] = $localUrl;

// Ajoute un nouveau service MariaDB pour ce site
$dbServiceName = "database_$alias";
$landoYml['services'][$dbServiceName] = [
  'type'        => 'mariadb:10.11',
  'portforward' => true,
  'creds'       => [
    'user'     => 'drupal11',
    'password' => 'drupal11',
    'database' => $alias,
  ],
];

// Inscrit la nouvelle base dans PhpMyAdmin
$landoYml['services']['pma']['hosts'][] = $dbServiceName;

// Ajoute le site dans tous les tooling concernés
$landoYml['tooling']['db-export-all']['cmd'][] = [
  $dbServiceName => "/helpers/sql-export.sh /app/files/$alias/dumps/`date +%Y-%m-%d_%H-%M-%S`-$alias.sql"
];
$landoYml['tooling']['drush-all']['cmd'][]     = ["drush @$alias"];
$landoYml['tooling']['db-get-all']['cmd'][]    = "./scripts/db-get.sh $alias";
$landoYml['tooling']['db-import-all']['cmd'][] = "./scripts/db-import.sh $alias";

file_put_contents($landoYmlPath, Yaml::dump($landoYml, 10, 2));

Et la mise à jour de la matrix GitLab CI utilise une regex sur la liste des sites :

if (preg_match('/- SITE: \[(.*?)\]/', $content, $matches)) {
  $sitesList = $matches[1];
  $sites = array_map('trim', explode(',', $sitesList));

  if (!in_array("'$alias'", $sites)) {
    $sites[] = "'$alias'";
    $newSitesList = implode(', ', $sites);
    $newContent = preg_replace('/- SITE: \[(.*?)\]/', "- SITE: [$newSitesList]", $content);
    file_put_contents($gitlabCiPath, $newContent);
  }
}

Pour les deux dossiers à créer (files/<alias>/ et web/sites/<alias>/), la commande copie des templates de scaffolding depuis drush/Commands/uzinasit/scaffolding/ :

$sourceDir = dirname(__FILE__) . "/scaffolding/sites_SITE";
$targetDir = "$projectRoot/web/sites/$alias";
$fs->mirror($sourceDir, $targetDir);

// Remplace le placeholder dans le settings.php scaffoldé
$content = file_get_contents("$targetDir/settings.php");
$content = str_replace("\$siteFolder = 'ulm';", "\$siteFolder = '$alias';", $content);
file_put_contents("$targetDir/settings.php", $content);

Une fois la commande terminée, il ne me reste qu'à faire :

lando restart                    # pour prendre en compte la nouvelle DB

Et voilà. Site ajouté en deux minutes.

6. Le déploiement - GitLab CI et la matrice sur les sites

Tout le code vit dans un repo GitLab (j'auto-héberge mon GitLab, mais cela fonctionnerait pareil sur gitlab.com). Le déploiement est piloté par .gitlab-ci.yml, qui s'appuie sur mes propres templates partagés entre plusieurs projets : kgaut/gitlab-ci-templates.

6.1 La structure du pipeline

variables:
  CI_TEMPLATE_VERSION: &CI_TEMPLATE_VERSION 0.4.21
  QA_DOCKER_IMAGE: wodby/drupal-php:8.3-dev
  DAYS_DUMP_TO_KEEP: 7
  SENTRY_ORG: 'kgautnet'

include:
  - project: kgaut/gitlab-ci-templates
    ref: *CI_TEMPLATE_VERSION
    file:
      - '/templates/generic/stages-variables-extends.yml'
      - '/templates/drupal/backup.yml'
      - '/templates/drupal/deploy.yml'
      - '/templates/generic/deploy-tracking.yml'
      - '/templates/qa/qa.yml'
      - '/templates/qa/phpstan.yml'
      - '/templates/qa/phpcs.yml'
      - '/templates/qa/phpunit.yml'

Mes templates externalisés gèrent tout le boilerplate (SSH, stages, conventions de nommage). Le pipeline a 5 stages : QA → predeploy → deploy → postdeploy → scheduled.

6.2 La matrix - les jobs en parallèle, par site

C'est le mécanisme central qui permet de paralléliser sur les sites :

.drush-aliases:
  parallel:
    matrix:
      - SITE: ['kgaut', 'dashboard', ...]

.sentry-sites:
  parallel:
    matrix:
      - SITE: ['kgaut', 'dashboard', ...]

Tout job qui extends: .drush-aliases est automatiquement lancé une fois par site, en parallèle, avec la variable $SITE qui prend chaque valeur. Donc prod:deploy-config, prod:clear-cache, prod:postdeploy:backup, prod:scheduled-backup — toutes ces étapes tournent en parallèle sur 11 jobs (un par site).

Et quand j'ajoute un nouveau site avec drush uzc, il est automatiquement ajouté à cette matrix (la commande Drush modifie le .gitlab-ci.yml toute seule, on l'a vu juste avant).

6.3 Les jobs clés

QA (stage QA) — tourne sur chaque merge request et push sur main :

phpstan : analyse statique sur les modules customphpcs : coding standards Drupalphpunit : tests unitaires

assets:generation (stage predeploy) compile les CSS et JS sur runner Node 22 :

assets:generation:
  image: node:22
  stage: predeploy
  script:
    - npm i
    - npm run sass-build-kgaut
    - npm run sass-build-wam
    - npm run sass-build-daash
    - npm i --prefix ./web/libraries/
    - npm i --prefix ./web/themes/custom/yfdev
    - npm run build --prefix ./web/themes/custom/yfdev
    - ...
  artifacts:
    paths:
      - web/themes/kgaut_2024/css
      - web/themes/daash/css
      - web/themes/wam_theme/css
      - web/themes/custom/yfdev/dist
      - web/libraries/node_modules
      - ...
    expire_in: 20 minutes

Les CSS générés sont publiés en artefacts (durée de vie 20 min, juste assez pour le job suivant).

assets:deploy (stage deploy) pousse les assets compilés en SSH avec rsync :

assets:deploy:
  image: alpine
  stage: deploy
  before_script:
    - apk update && apk add openssh git curl rsync
  script:
    - rsync -avhzi --delete --stats web/themes/kgaut_2024/css \
        -e "ssh -p $SSH_PORT" $SSH_USER@$SSH_HOST:$PROJECT_ROOT/web/themes/kgaut_2024
    - rsync -avhzi --delete --stats web/themes/daash/css \
        -e "ssh -p $SSH_PORT" $SSH_USER@$SSH_HOST:$PROJECT_ROOT/web/themes/daash
    # … etc
  needs: [assets:generation, prod:deploy]

prod:deploy (stage deploy) c'est ici qu'on déploie le code PHP. Ce job SSH dans la prod et exécute scripts/deploy-code.sh :

.deploy:
  stage: deploy
  extends: [.ssh]
  script:
    - $SSH_CHAIN 'bash -s' < ./scripts/deploy-code.sh \
        $PROJECT_ROOT $DRUPAL_SITE_PATH $DRUSH_BIN \
        $CI_ENVIRONMENT_NAME $CI_PIPELINE_IID $CI_COMMIT_REF_NAME

Le script deploy-code.sh est volontairement minimaliste :

#!/bin/bash
set -e

PROJECT_ROOT="$1"
CI_ENVIRONMENT_NAME="$4"
CI_PIPELINE_IID="$5"
CI_COMMIT_REF_NAME="$6"

cd "$PROJECT_ROOT"

# Passer les dossiers settings en écriture pendant la mise à jour
chmod +w "$PROJECT_ROOT/web/sites/default"
chmod +w "$PROJECT_ROOT/web/sites/default/settings.php"
chmod +w "$PROJECT_ROOT/web/sites/monboncoin"
chmod +w "$PROJECT_ROOT/web/sites/monboncoin/settings.php"
# … pour chaque site

if [ $CI_ENVIRONMENT_NAME = "prod" ]; then
  TAG="$6"
  git fetch --tags
  git checkout "$TAG"
else
  git fetch --all
  git reset --hard origin/$CI_COMMIT_REF_NAME
fi

composer install --no-dev

# Restaurer les perms read-only
chmod ugo-w "$PROJECT_ROOT/web/sites/default"
chmod ugo-w "$PROJECT_ROOT/web/sites/default/settings.php"
# …

En prod : on déploie sur un tag. En staging : sur la branche courante. Et composer install --no-dev garantit qu'on tourne sans les dépendances de dev (phpstan, phpcs…). Tout le reste — la config Drupal à importer, les caches à vider, les backups — est délégué à des jobs GitLab qui suivent.

prod:deploy-config pour chaque site en parallèle, exécute drush deploy (qui fait updatedb + config:import + cache:rebuild) :

prod:deploy-config:
  extends: [.prod, .ssh, .drush-aliases]
  script:
    - $SSH_CHAIN 'bash -s' < ./scripts/deploy-config.sh \
        $PROJECT_ROOT $DRUPAL_SITE_PATH $DRUSH_BIN \
        $CI_ENVIRONMENT_NAME $CI_PIPELINE_IID \
        $CI_COMMIT_REF_NAME "@$SITE.main" $SITE
  needs: [prod:deploy]

prod:clear-cache, drush cr sur chaque site, en parallèle :

prod:clear-cache:
  extends: [.prod, .drush-aliases, .ssh]
  stage: postdeploy
  script:
    - $SSH_CHAIN "$PROJECT_ROOT/$DRUSH_BIN $DRUSH_ALIAS cr"

prod:postdeploy:backup, dump SQL horodaté de chaque site juste après le deploy. Permet de revenir en arrière facilement si une release casse quelque chose :

prod:postdeploy:backup:
  extends: [.ssh, .backup, .drush-aliases, .prod]
  script:
    - $SSH_CHAIN "$PROJECT_ROOT/$DRUSH_BIN @$SITE.main sql-dump \
        | gzip -9 > $PROJECT_ROOT/files/$SITE/dumps/`date +%Y-%m-%d_%H-%M-%S`-$SITE-post-$CI_COMMIT_REF_NAME.sql.gz"

prod:scheduled-backup, tourne sur un cron GitLab (chaque nuit). Idem mais en mode planifié.

prod:scheduled-clean, purge les dumps de plus de 7 jours :

script:
  - $SSH_CHAIN "find $PROJECT_ROOT/files/$SITE/dumps/ \
      -type f -mtime +$DAYS_DUMP_TO_KEEP -name '*.sql.gz' -delete"

prod:sentry-release, crée une release Sentry par site avec les commits associés :

prod:sentry-release:
  variables:
    RELEASE: "$CI_COMMIT_TAG"
    SENTRY_PROJECT: "$SITE"
  extends: [.sentry-sites, .prod, .sentry-release]

À la fin du pipeline, j'ai :

Le code déployé sur les 12 sitesLes CSS et JS recompilés et "rsyncés"La config Drupal importée sur chaque siteLes caches vidésUn dump SQL pre-deploy et un dump post-deploy par siteUne release Sentry par site avec les commits associés à cette version

Et tout ça tourne en ~5 à 10 minutes selon la taille de la mise à jour, grâce à la parallélisation par matrice.

7. Le workflow de mise à jour Drupal

C'est l'argument principal de cette archi. Voyons concrètement comment ça se passe pour une mise à jour de Drupal core :

cd uzinasit
composer update drupal/core --with-dependencies
lando drush-all updb -y # mise à jour de la DB
lando drush-all cex # export de la config
# On teste via les tests unitaires et manuels
git commit -am "feat(core): update Drupal 11.x.y"
git tag x.y.z
git push
git push --tags

Et la CI fait le reste : QA, build des assets, déploiement code sur la prod (un seul composer install), drush deploy en matrice sur les 12 sites, vidage de cache, backup post-deploy, releases Sentry. Le tout en moins de 10 minutes, en parallèle.

Et le composer.lock étant unique, j'ai la garantie absolue que mes 12 sites tournent exactement avec la même version de Drupal core et des mêmes contribs. Plus de dérive entre sites.

C'est ce que je voulais. Maintenance routinière → quasi zéro temps. La dernière fois qu'une vulnérabilité critique Drupal core a été publiée, j'ai appliqué la mise à jour en 5 minutes. Sans cette archi, j'aurais bloqué une demi-journée.

Idem pour les modules contrib : composer require drupal/un_module rend le module disponible pour les 12 sites. Charge à chaque site d'activer ce module ou pas (via son core.extension.yml dans files/<site>/config/sync/).

Pour conclure

Je suis très content de cette infra,

La mise en place d'un nouveau site est maintenant très rapideMes sites sont maintenant tout le temps à jourBackup simplifié pour l'ensemble des sites

Quelques limites :

Quand je fais des modifs concernant un site, c'est 12 sites qui sont publié, backupé, caches vidés... peut-être réflechir à un moyen de limiter le déploiement à un seul site quand ça n'est pas de la mise à jour de module / libEvidement je ne gère aucun site de client sur cette infrastructure.

Prochaine piste que le voudrais creuser : Les Drupal recipes pour scaffolder un site avec un set de modules prédéfinis (Actu, blog, site vitrine...)

N'hésitez-pas si vous avez des suggestions ou des questions

Drupal changer le titre d'une page Views (vues)

kgaut — Fri, 27 Mar 2026 09:26:12 +0100

Le titre d'une page de vue se gère normalement directement dans la vue, mais il es possible de changer le changer dynamiquement si nécessaire.

/**
 * Implements hook_views_post_render().
 */
function MON_MODULE_views_post_render(Drupal\views\ViewExecutable $view) {
  if ($view->element['#view_id'] === 'ma_vue') {
    if ($view->element['#display_id'] === 'page_1') {
      $title = "Mon titre dynamique;
      $view->setTitle($title);
      $route = \Drupal::routeMatch()->getCurrentRouteMatch()->getRouteObject();
      $route->setDefault('_title_callback', function() use ($title) {
        return $title; 
      });
      }
    }
  }

Drupal - Ajouter Scheduler à un type d'entité custom

kgaut — Wed, 18 Feb 2026 16:35:28 +0100

Scheduler est un module drupal qui permet, pour un contenu, de définir une date de publication et/ou une date de dépublication.

Par défaut, il ne s'interface qu'avec les noeuds (Node), mais depuis la version 2.x il est possible de l'interfacer avec des type entités custom, attention : uniquement si elle possède des bundle, cela ne fonctionnera pas pour un type d'entité sans bundle. (Issue drupal sur le sujet : https://www.drupal.org/project/scheduler/issues/3355087)

Si c'est le cas, alors il est très facile de définir que votre type d'entité doit être « schedulable », il suffit de créer un plugin dans le dossier src/Plugin/Scheduler de votre module.

Dans mon cas mon type d'entité s'appelle Annonce (id : annonce) j'ai donc créé la classe /modules/custom/mon_module/src/Plugin/Scheduler/AnnonceScheduler.php avec le contenu suivant :

<?php

namespace Drupal\mon_module\Plugin\Scheduler;

use Drupal\Core\Plugin\ContainerFactoryPluginInterface;
use Drupal\scheduler\SchedulerPluginBase;

/**
 * Plugin for Annonce entity type.
 *
 * @package Drupal\Scheduler\Plugin\Scheduler
 *
 * @SchedulerPlugin(
 *  id = "annonce_scheduler",
 *  label = @Translation("Annonce Scheduler Plugin"),
 *  description = @Translation("Provides support for scheduling Annonce entities"),
 *  entityType = "annonce",
 *  dependency = "mon_module",
 * )
 */
class AnnonceScheduler extends SchedulerPluginBase implements ContainerFactoryPluginInterface {}

Videz votre cache, et vous pourrez alors modifier les paramètres directement sur la configuration du bundle de votre type d'entité :

Image

Drupal - Créer des entrées custom pour XML Sitemap via le code

kgaut — Mon, 05 Jan 2026 16:13:54 +0100

Si vous utilisez le module drupal xmlsitemap, il est possible d'ajouter des liens personnalisés vers des controleurs ou des vues via le sous module xmlsitemap_custom et l'UI accessible à l'uri : /admin/config/search/xmlsitemap/custom/add :

Image

Du coup ces « custom links » ne seront pas en config, donc non déployable.

Voici comment en créer via le code :

mon_module.post_update.php

/**
 * Create Custom XML Sitemap Entries.
 */
function mon_module_post_update_create_xmlsitemap_custom_entries() {
  $entries = [
    [
      'loc' => '/ma-page-fr',
      'language' => 'fr',
    ],
    [
      'loc' => '/ma-page-en',
      'language' => 'en',
    ],
    [
      'loc' => '/mon-autre-page-fr',
      'language' => 'fr',
    ],
  ];
  /** @var \Drupal\xmlsitemap\XmlSitemapLinkStorageInterface $linkStorage */
  $linkStorage = \Drupal::service('xmlsitemap.link_storage');
  $query = \Drupal::database()->select('xmlsitemap', 'x');
  $query->addExpression("MAX(CAST(id AS INT))");
  $query->condition('type', 'custom');
  $id = (int) $query->execute()->fetchField();
  foreach ($entries as $entry) {
    $entry += [
      'id' => ++$id,
      'type' => 'custom',
      'subtype' => '',
      'priority' => 0.7,
      'changefreq' => XMLSITEMAP_FREQUENCY_DAILY,
    ];
    $linkStorage->save($entry);
  }

}

Drupal - Un petit filtre pour les commentaires en fonction d'une liste de mots bannis

kgaut — Fri, 05 Dec 2025 09:19:56 +0100

C'est loin d'être la solution la plus moderne au monde, mais voila un petit filtre qui, en fonction d'une liste de mots publiera ou non un commentaire posté sur votre site.

Évidement l'idée peut s'adapter à toute sorte de formulaire de votre site.

J'ai utilisé le hook comment_presave :

Fichier : web/modules/mon_module/src/Hook/EntityHooks.php

<?php

namespace Drupal\mon_module\Hook;

use Drupal\comment\CommentInterface;
use Drupal\Core\DependencyInjection\AutowireTrait;
use Drupal\Core\DependencyInjection\ContainerInjectionInterface;
use Drupal\Core\Entity\EntityInterface;
use Drupal\Core\Hook\Attribute\Hook;

/**
 * Provides hook implementations for Entity alterations.
 */
final class EntityHooks implements ContainerInjectionInterface {

  use AutowireTrait;

  /**
   * Comments blacklisted words.
   */
  protected static array $commentBlackListWords = [
    "useful",
    "nexus",
    "д",
    "Psilocybin",
    "?link",
    "url?",
    "dark market?",
    "dark web",
    "darkweb",
    "darknet",
    "Gambling",
    "darkmarket",
    "drug",
    "Russia",
    "อ",
    "ส์",
    "Why SQL Matters in Business Analytic",
  ];

  /**
   * Hook method triggered before a comment is saved.
   *
   * Checks the comment body for blacklisted words and updates the comment
   * status to "not published" if any blacklisted word is detected.
   *
   * @param \Drupal\Core\Entity\EntityInterface $entity
   *   The comment entity being processed.
   */
  #[Hook('comment_presave')]
  public function commentPresave(EntityInterface $entity): void {
    if ($entity instanceof CommentInterface) {
      $body = $entity->get('comment_body')->value;
      $body = strtolower($body);
      foreach (self::$commentBlackListWords as $word) {
        if (str_contains($body, strtolower($word))) {
          $entity->set('status', CommentInterface::NOT_PUBLISHED);
        }
      }
    }
  }

}

Drupal - Comment surcharger vos nodes avec les classes de bundle

kgaut — Fri, 05 Dec 2025 08:01:52 +0100

Cela n'est pas franchement une nouveauté, les Classes de Bundle (Bundle Classes) ont été introduites dans le core dès Drupal 9.3 en 2021. Pourtant, je vois encore beaucoup de projets qui s'en passent, et cela fait longtemps que je voulais aborder le sujet ici.

C'est une fonctionnalité qui change la donne en termes d'architecture et de maintenabilité. Aujourd'hui, nous allons voir comment les mettre en place, en profitant de l'occasion pour utiliser la nouvelle syntaxe de hooks orientée objet disponible depuis Drupal 11 (voir à ce sujet : https://kgaut.net/blog/2024/drupal-11-utiliser-la-nouvelle-syntaxe-orientee-objet-pour-les-hooks)

Pourquoi les classes de bundle ?

De tout temps dans Drupal, le contenu est principalement représenté par des nœuds. Techniquement, un nœud de type "Article" et un nœud de type "Concert" sont tous deux des instances de la même classe générique : Drupal\node\Entity\Node.

Depuis Drupal 8, il est possible de surcharger cette classe pour y ajouter une couche métier. Imaginons que vous ayez un type de contenu "Concert" avec un champ date. Vous pourriez vouloir une méthode getDateConcert() pour récupérer cette date formatée facilement.

Le problème, c'est que si vous surchargez la classe Node générique, cette méthode getDateConcert() se retrouve disponible sur tous vos nœuds, y compris les articles de blog ou les pages statiques, ce qui n'a aucun sens sémantiquement.

C'est là qu'interviennent les Classes de Bundle. Elles permettent de corriger ce défaut en définissant une classe PHP spécifique pour un bundle précis.

Exemple d'utilisation : Concerts et Articles

Prenons un exemple concret. Dans un module personnalisé mon_module, nous voulons gérer deux types de contenus :

Concert (concert) : Nous voulons une méthode pour récupérer facilement sa date.

Article (article) : Nous voulons juste qu'il ait sa propre classe pour de futurs besoins.

Étape 1 : Créer les classes

Pour faire les choses proprement et avoir un socle solide, je commence par définir une classe abstraite. Elle servira de base à toutes mes classes de bundle de nœuds et contiendra les méthodes communes si besoin.

Fichier : mon_module/src/Entity/AbstractNode.php

<?php

namespace Drupal\mon_module\Entity;

use Drupal\node\Entity\Node;

/**
 * Classe abstraite de base pour nos classes de bundle.
 */
abstract class AbstractNode extends Node {
    // On pourra ajouter ici des méthodes utiles à tous nos types de contenus.
}

Ensuite, je crée la classe spécifique pour mon type de contenu "Concert". C'est ici que j'ajoute ma logique métier.

Fichier : mon_module/src/Entity/ConcertNode.php

<?php

namespace Drupal\mon_module\Entity;

use Drupal\Core\Datetime\DrupalDateTime;

/**
 * Classe spécifique pour le bundle 'concert'.
 */
class ConcertNode extends AbstractNode {

  /**
   * Retourne la date du concert sous forme d'objet DrupalDateTime.
   *
   * @return \Drupal\Core\Datetime\DrupalDateTime|null
   * La date du concert ou null si le champ est vide.
   * @throws \Drupal\Core\TypedData\Exception\MissingDataException
   */
  public function getDate(): ?DrupalDateTime {
    if ($this->hasField('field_date') && !$this->get('field_date')->isEmpty()) {
        return $this->get('field_date')->date;
    }
    return null;
  }

  /**
   * Une méthode helper pour savoir si le concert est passé.
   */
  public function isPast(): bool {
      $date = $this->getDate();
      if ($date) {
          return $date->getTimestamp() < \Drupal::time()->getRequestTime();
      }
      return FALSE;
  }

}

Je crée aussi rapidement celle pour l'article, même si elle est vide pour l'instant :

Fichier : mon_module/src/Entity/ArticleNode.php

<?php

namespace Drupal\mon_module\Entity;

class ArticleNode extends AbstractNode {}

Étape 2 : Déclarer les classes (Nouvelle méthode Drupal 11)

Maintenant, il faut dire à Drupal : "Quand tu charges un nœud de type 'concert', utilise ma classe ConcertNode au lieu de la classe par défaut".

Cela se fait via le hook entity_bundle_info_alter. Utilisons la syntaxe moderne avec les attributs PHP dans une classe dédiée aux hooks :

Fichier : mon_module/src/Hook/EntityHooks.php

<?php

namespace Drupal\mon_module\Hook;

use Drupal\Core\Hook\Attribute\Hook;
use Drupal\mon_module\Entity\ArticleNode;
use Drupal\mon_module\Entity\ConcertNode;

/**
 * Fournit les implémentations de hooks relatives aux entités.
 */
final class EntityHooks {

  /**
   * Implements hook_entity_bundle_info_alter().
   *
   * Modifie la définition des bundles pour associer nos classes personnalisées.
   */
  #[Hook('entity_bundle_info_alter')]
  public function bundleInfoAlter(array &$bundles): void {
    // Mapping pour le type de contenu 'concert'
    if (isset($bundles['node']['concert'])) {
      $bundles['node']['concert']['class'] = ConcertNode::class;
    }
    // Mapping pour le type de contenu 'article'
    if (isset($bundles['node']['article'])) {
      $bundles['node']['article']['class'] = ArticleNode::class;
    }
  }

}

N'oubliez pas de vider les caches pour que Drupal prenne en compte le nouveau hook et les nouvelles classes !

Le résultat : une utilisation simplifiée

C'est là que la magie opère. Vous n'avez rien à changer dans votre manière de charger des entités. Drupal instanciera automatiquement la bonne classe.

Dans du code PHP (un contrôleur, un service...) :

use Drupal\node\Entity\Node;
use Drupal\mon_module\Entity\ConcertNode;

$nid = 25; // Imaginons que le nœud 25 est un concert.
$entity = Node::load($nid);

// PHP sait maintenant que $entity est une instance de ConcertNode.
if ($entity instanceof ConcertNode) {
    // On peut appeler nos méthodes personnalisées directement.
    $date = $entity->getDate();
    
    if ($entity->isPast()) {
        // Logique spécifique si le concert est passé...
    }
}

Dans Twig

C'est encore plus agréable pour les développeurs front-end. Grâce à la magie des getters dans Twig, getDate() devient accessible via node.date (si le nom ne rentre pas en conflit avec un champ) ou en appelant la méthode directement.

{# Dans node--concert.html.twig #}

<article class="concert {{ node.isPast ? 'concert--past' : 'concert--upcoming' }}">
  <h2>{{ label }}</h2>
  {# Appel direct de la méthode #}
  <p>Date du concert : {{ node.getDate().format('d/m/Y') }}</p>
  
  {# Utilisation de la méthode booléenne #}
  {% if node.isPast() %}
    <span class="badge">Concert terminé</span>
  {% endif %}
</article>

Fini les preprocess compliqués pour calculer des états ou formater des dates spécifiques !

Au-delà des Nœuds

L'exemple ici porte sur les nœuds, mais cela s'applique évidemment à l'ensemble des types d'entités de contenu : Utilisateurs, Termes de taxonomie, Media, etc.

Dans votre hook, vous pourriez ajouter :

// Dans EntityHooks::bundleInfoAlter

// Pour un vocabulaire 'tags'
if (isset($bundles['taxonomy_term']['tags'])) {
  $bundles['taxonomy_term']['tags']['class'] = TagTerm::class;
}
// Pour les utilisateurs (le bundle s'appelle aussi 'user')
if (isset($bundles['user']['user'])) {
  $bundles['user']['user']['class'] = UserCustom::class;
}

Conclusion

À titre personnel, je trouve cette fonctionnalité indispensable sur tout projet Drupal moderne. Cela permet d'ajouter toute une couche métier (getters, setters, méthodes utilitaires) directement là où elle doit être : dans l'objet qui représente la donnée.

Le code devient beaucoup plus propre, orienté objet, plus facile à tester unitairement, et bien plus maintenable sur le long terme. Si vous ne les utilisez pas encore, foncez !

Voir la présentation sur drupal.org : https://www.drupal.org/node/3191609

/now édito de décembre 2025

kgaut — Wed, 03 Dec 2025 20:47:06 +0100

La fin de l'année se profile déjà. Ce fut encore une belle année sur le plan pro, riche en projets intéressants.

Cette année aura marqué mes 10 ans de freelance à temps plein ainsi que les 10 ans de mon déménagement depuis les montagnes de Haute-Savoie vers les volcans du Puy-de-Dôme.

Fait marquant de l'année : depuis 2021, je travaillais pour le groupe Fournier (Perene, Mobalpa, SoCoo'c, Hygena et Delpha). D'abord développeur back Drupal, j'ai ensuite évolué vers un rôle transverse, à la croisée du développement et de l'infrastructure. J'ai notamment piloté la migration d'un hébergeur « classique » vers le Cloud (GCP). Cela a impliqué une grosse dose de Docker pour conteneuriser les sites et applications, de la CI avec GitLab pour orchestrer des pipelines de déploiement aux petits oignons, et une multitude d'optimisations pour simplifier la vie des développeurs. Cette mission s'est achevée fin octobre.

Cela a laissé un petit vide, mais ça fait du bien de souffler et de s'attaquer aux sujets qui traînaient : quelques sites pour des associations dont je suis membre et la refonte de mon serveur auto-hébergé. J'en profite d'ailleurs pour tout documenter. Avec Pierre Lecourt (minimachines.net), nous préparons une série de guides pour monter son « Home Server », de l'OS jusqu'au reverse proxy et Docker. Le premier guide devrait sortir rapidement !

Côté enseignement, après plus de dix ans en BUT INFO à Annecy-le-Vieux, j'ai fait une pause cette année. Les allers-retours devenaient trop fatigants, mais l'envie de transmettre est toujours là. Je reprendrai sûrement si je trouve une opportunité plus proche de chez moi.

Enfin, j'avais l'ambition de poster davantage ici (bilan mitigé). Je suis lassé de voir tant de contenu de qualité offert à des plateformes tierces instables ou rachetées par des mégalomanes. Pour moi, Internet, ce n'est pas ça. Le Web 2.0 ne nous laissera rien. Rendez-nous nos forums phpBB et nos blogs ; gardez vos posts LinkedIn générés par IA et vides de sens (mais rendez-nous Grégory Logan, au moins c'était drôle).

Drupal - Les « menu deriver » pour générer des éléments de menu dynamiquement

kgaut — Wed, 03 Dec 2025 20:04:49 +0100

Dans Drupal, les éléments de menu sont gérés soit via l'interface d'administration soit dans les fichiers mon_module.links.menu.yml, de la manière suivante :

Un lien vers un noeud :

enfarandole.main.help:
  title: 'Nous aider'
  weight: 2
  route_name: entity.node.canonical
  route_parameters:
    node: 5
  menu_name: main

Un lien vers une vue :

amicale.main.events:
  title: 'Évènements'
  weight: 1
  route_name: view.evenements.listing
  menu_name: main

Mais il est aussi possible d'utiliser un deriver, pour créer des éléments de menu de manière dynamique, dans l'exemple suivant je vais lister dans un sous menu tous les contenus d'un certains type, je commence par la déclaration de mon menu parent et de mon deriver, toujours dans le fichier mon_module.links.menu.yml :

# Mon élément parent, sans lien, qui sera dans le menu principal
amicale.main.sections:
  title: 'Sections'
  weight: 1
  route_name: '<nolink>'
  menu_name: main

# La définition de mon dériver pointant vers une classe
amicale.main.sections.section: 
  deriver: '\Drupal\mon_module\Plugin\Derivative\SectionMenuLinkDeriver'
  class: '\Drupal\Core\Menu\MenuLinkDefault'

La classe de mon dériver (web/modules/mon_module/src/Plugin/Derivative/SectionMenuLinkDeriver.php)

<?php

namespace Drupal\mon_module\Plugin\Derivative;

use Drupal\Component\Plugin\Derivative\DeriverBase;
use Drupal\Core\Entity\EntityTypeManager;
use Drupal\Core\Plugin\Discovery\ContainerDeriverInterface;
use Drupal\Core\Url;
use Symfony\Component\DependencyInjection\ContainerInterface;

/**
 * Menu deriver for content type « page_de_section ».
 */
final class SectionMenuLinkDeriver extends DeriverBase implements ContainerDeriverInterface {

  /**
   * The entity type manager.
   *
   * @var \Drupal\Core\Entity\EntityTypeManager
   */
  protected EntityTypeManager $entityTypeManager;

  /**
   * CategoryMenuLinkDeriver constructor.
   *
   * @param \Drupal\Core\Entity\EntityTypeManager $entityTypeManager
   *   The entity type manager.
   */
  public function __construct(EntityTypeManager $entityTypeManager) {
    $this->entityTypeManager = $entityTypeManager;
  }

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container, $base_plugin_id) {
    return new static($container->get('entity_type.manager'));
  }

  /**
   * {@inheritdoc}
   */
  public function getDerivativeDefinitions($base_plugin_definition) {
    $links = [];

    $storage = $this->entityTypeManager->getStorage('node');

    $query = $storage->getQuery();
    // Je charge tous les noeud du type « page_de_section »
    $query->accessCheck(TRUE);
    $query->condition('type', 'page_de_section');
    $query->sort('title');
    $sections = $query->execute();

    // Et pour chaque, je vais créer un élément de menu
    foreach ($sections as $section) {
      if (!$section = $storage->load($section)) {
        continue;
      }

      // Create menu ID.
      $menuId = 'amicale.main.sections.section:' . $section->id();

      $link = [
        'id' => $menuId,
        'route_name' => entity.node.canonical,
        'route_parameters' => ['node' => $section->id()],
        'title' => $section->label(), // Le titre de mon élément de menu (ici le titre du noeud)
        'parent' => 'amicale.main.sections', // je définis ici le menu item parent, si omis, ça sera un élément de menu de niveau 1
      ] + $base_plugin_definition;
      
      $links[$menuId] = $link;
    }

    return $links;
  }

}

On vide son cache, et voila !

Évidement tout est possible au niveau de ce que l'on veut ajouter comme élément de menu, catégories basée sur un vocabulaire, liste de membres...

Drupal - Utiliser le Lazy Builder pour charger un élément de manière asynchrone

kgaut — Wed, 12 Nov 2025 16:00:33 +0100

Dans Drupal Le lazybuilder permet permet de charger une partie d'une page (bloc, sous-partie, champ...) de manière asynchrone ce qui permet d'optimiser le chargement de la page ou de nous abstraire de certaines problématiques posées par le cache.

Voici comment la mettre en oeuvre :

Déclaration du placehoder :

Un renderable array, qui sera subsitiué par le contenu de notre lazy builder :

$variables['content']['field_coupons'] = [
  '#create_placeholder' => TRUE,
  '#lazy_builder' => [
    'mon_module.coupon.lazy_builder:renderCoupon', [$coupon->id(), $node->id(), $node->language()->getId()],
  ],
];

Je déclare donc une zone qui sera remplacée par ce que me retourne la méthode renderCoupon du service : mon_module.coupon.lazy_builder.

Déclaration du service

mon_module.services.yml

services:
  mon_module.coupon.lazy_builder:
    class: Drupal\mon_module\LazyBuilder\CouponLazyBuilder
    tags:
      - { name: lazy_builder }

l'implémentation du service

mon_module/src/LazyBuilder/CouponLazyBuilder.php

<?php

namespace Drupal\clearblue\LazyBuilder;

use Drupal\clearblue\Entity\Node;
use Drupal\Core\Security\TrustedCallbackInterface;

/**
 * Class LastViewedContentLazyBuilder
 * To render the last viewed content using Lazy Builder.
 *
 * @package Drupal\your_custom_module
 */
class CouponLazyBuilder implements TrustedCallbackInterface {

  /**
   * {@inheritdoc}
   */
  public static function trustedCallbacks(): array {
    return ['renderCoupon']; // je déclare ici explicitement les méthodes autorisées à être appelées en ajax
  }

  public function renderCoupon($couponId, $nodeId, $langcode): array {
    $node = Node::load($nodeId);
    
    // Ici je retourne l'affichage du champ d'un noeud, mais on peut évidement faire ce que l'on veut.
    $renderableArray = \Drupal::entityTypeManager()->getViewBuilder('node')->viewField($node->get('field_coupons'), [
      'type' => 'entity_reference_entity_view',
      'label' => 'hidden',
      'settings' => [
        'view_mode' => 'default',
        'link' => 'true',
      ],
    ]);

    $renderableArray['#cache']['tags'] = [
      'node:' . $nodeId,
      'langcode:' . $langcode,
      'coupons:' . $couponId,
    ];
    
    return $renderableArray;

  }

}

Migrer une instance gitlab sur un nouveau serveur

kgaut — Mon, 27 Oct 2025 08:08:44 +0100

Avec la fin de vie de Centos, j'ai du migrer mon installation gitlab sur un nouveau serveur. J'ai choisi pour cela la distribution Almalinux 9 (https://almalinux.org/), basée aussi sur RedHat, avec le même système de paquets, je ne serai pas perdu.

Cette procédure doit fonctionner avec toutes les distributions supportées par gitlab (https://docs.gitlab.com/install/package/#supported-platforms), modulo les adaptations dans certaines commandes (apt install au lieu de dnf install si vous êtes sur une base debian par exemple).

J'ai pris comme référence la documentation suivante : https://docs.gitlab.com/administration/backup_restore/restore_gitlab/

À noter, il faudra impérativement installer sur le nouveau serveur une version de gitlab identique à celle de l'ancien serveur, pour la trouver, rendez-vous sur le pannel d'administration et vous trouverez l'information en bas à droite :

Image

Il vous faudra donc un accès ssh à votre ancien serveur (dans la suite l'ip sera substituée par ANCIEN), un accès ssh sur le nouveau serveur (dans la suite l'ip sera substituée par NOUVEAU), Le nouveau serveur est dans mon cas une instance où est fraîchement installé un AlmaLinux 9, et rien d'autre.

Installation de gitlab sur le nouveau serveur

Connectez-vous en ssh à votre nouveau serveur (ssh root@NOUVEAU)

# Mises à jour et installation de paquets nécessaires
dnf update 
dnf install -y curl vim

# Installation des dépots Gitlab Community Edition
curl "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh" | sudo bash

# Trouver la version du paquet à installer correspondante à la version installée sur l'ancien serveur  

dnf search --showduplicates gitlab-ce

# dans mon cas : gitlab-ce-17.7.7-ce.0.el9

# Installation de gitlab en spécifiant l'url de l'instance
sudo EXTERNAL_URL="https://gitlab.exemple.com" dnf install gitlab-ce-17.7.7-ce.0.el9

Backup et transfert de l'instance existante

Connectez-vous en ssh à votre ancien serveur (ssh root@NOUVEAU)

# Si vous n'avez pas de paire de clé ssh sur votre ancien serveur, créez-en une :
ssh-keygen -t ed25519 -C "root@ancien"

# on ajoute la clée public de l'ancien serveur au nouveau afin de pouvoir s'y connecter sans mot de passe
ssh-copy-id root@NOUVEAU


# Avant de lancer le backup, on désactive l'accès à l'instance
sudo gitlab-ctl stop sidekiq
sudo gitlab-ctl stop puma

# On lance un backup de son instance gitlab
gitlab-backup create BACKUP=dump_full GZIP_RSYNCABLE=yes

# Transferts des secrets (fichier non présent dans le backup)
rsync /etc/gitlab/gitlab-secrets.json -e ssh root@NOUVEAU:/etc/gitlab/

# Transferts de la configuration (fichier non présent dans le backup)
rsync /etc/gitlab/gitlab.rb -e ssh root@NOUVEAU:/etc/gitlab/

# Transfert des backups 
rsync -avh --stats /var/opt/gitlab/backups/* -e ssh root@NOUVEAU:/var/opt/gitlab/backups/

Restauration de la sauvegarde sur le nouveau serveur

De nouveau connecté ssh à votre nouveau serveur (ssh root@NOUVEAU)

# On arrête les services connectés à la base de données
sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq

# on regarde le nom du backup à restaurer : 
ls -alh /var/opt/gitlab/backups/  

# dans mon cas l'archive se nomme dump_full
# on ne prend pas en compte la partie du fichier « _gitlab_backup.tar »
# -rw-------.  1 git  git   22G Oct 24 08:48 dump_full_gitlab_backup.tar  

# on lance la restauration (processus long)
sudo gitlab-backup restore BACKUP=dump_full

# on lance une reconfiguration de gitlab à partir des données restaurées
sudo gitlab-ctl reconfigure

# on relance tous les services
sudo gitlab-ctl start

# On vérifie que tout va bien
sudo gitlab-rake gitlab:check SANITIZE=true

# On vérifie l'intégritées des données chiffrées à partir du fichier secrets que l'on a transféré
sudo gitlab-rake gitlab:doctor:secrets

# On vérifie l'intégritée globale de l'ensemble des données restaurées
sudo gitlab-rake gitlab:artifacts:check
sudo gitlab-rake gitlab:lfs:check
sudo gitlab-rake gitlab:uploads:check

# On lance une analyse de la base de données via la console 
sudo gitlab-rails dbconsole --database main

SET STATEMENT_TIMEOUT=0 ; ANALYZE VERBOSE;

Fin de la migration

Si tout va bien, vous pouvez maintenant faire pointer soit changer la configuration dns pour pointer le nom de domaine de votre serveur gitlab vers le nouveau serveur ou alors affecter l'ip de l'ancien serveur au nouveau (ce que j'ai fait, étant sur des serveurs virtualisés).

Une fois que tout est ok, vous pourrez lancer les mises à jours de gitlab sur le nouveau serveur afin de profiter des dernières mise à jour :

sudo dnf update

Dans mon cas, j'ai du faire des mises à jour intermédiaires, 17.8.x, 17.11.x puis 18.2.x avant de lancer la mise à jour finale:

Pour trouver la dernière version d'une version intermédiaire :

dnf search --showduplicates gitlab-ce | grep "17.8"
Last metadata expiration check: 0:03:51 ago on Fri 24 Oct 2025 01:06:17 PM UTC.
gitlab-ce-17.8.0-ce.0.el9.x86_64 : GitLab Community Edition (including NGINX, Postgres, Redis)
gitlab-ce-17.8.1-ce.0.el9.x86_64 : GitLab Community Edition (including NGINX, Postgres, Redis)
gitlab-ce-17.8.2-ce.0.el9.x86_64 : GitLab Community Edition (including NGINX, Postgres, Redis)
gitlab-ce-17.8.4-ce.0.el9.x86_64 : GitLab Community Edition (including NGINX, Postgres, Redis)
gitlab-ce-17.8.5-ce.0.el9.x86_64 : GitLab Community Edition (including NGINX, Postgres, Redis)
gitlab-ce-17.8.6-ce.0.el9.x86_64 : GitLab Community Edition (including NGINX, Postgres, Redis)
gitlab-ce-17.8.7-ce.0.el9.x86_64 : GitLab Community Edition (including NGINX, Postgres, Redis)

j'ai donc lancé successivement :

sudo dnf instal gitlab-ce-17.8.7-ce.0.el9.x86_64

sudo dnf install gitlab-ce-17.11.7-ce.0.el9.x86_64

sudo dnf install gitlab-ce-18.2.8-ce.0.el9.x86_64

Pour terminer, pensez-bien à réinstaller gitlab runner si vous utilisiez la CI (https://docs.gitlab.com/runner/install/linux-repository/) et remettre en place la sauvegarde de votre instance. Voilà ce que j'ai dans mon crontab pour 2 sauvegarder par jour + une sauvegarde complète :

30 18 * * * gitlab-backup create BACKUP=dump_night GZIP_RSYNCABLE=yes SKIP=registry,artifacts  
30 11 * * * gitlab-backup create BACKUP=dump_day GZIP_RSYNCABLE=yes SKIP=registry,artifacts  
30 19 5 * * gitlab-backup create BACKUP=dump_full GZIP_RSYNCABLE=yes