Planète

Voici comment ajouter un ou plusieurs champs au formulaire de configuration « paramètres de base du site ».

On commence par créer un service qui nous permettra de surcharger le formulaire de base : 

modules/mon_module/mon_module.services: 

services:
  mon_module.route_subscriber:
    class: Drupal\mon_module\Routing\RouteSubscriber
    tags:
      - { name: event_subscriber }

modules/mon_module/src/Routing/RouteSubscriber.php

<?php
namespace Drupal\mon_module\Routing;
use Drupal\Core\Routing\RouteSubscriberBase;
use Symfony\Component\Routing\RouteCollection;
use Drupal\mon_module\Form\BasicSiteInformationForm;
class RouteSubscriber extends RouteSubscriberBase {
  /**
   * {@inheritdoc}
   */
  protected function alterRoutes(RouteCollection $collection) {
    if ($route = $collection->get('system.site_information_settings'))
      $route->setDefault('_form', BasicSiteInformationForm::class);
  }
}

Et la surcharge du formulaire :

modules/mon_module/src/Form/BasicSiteInformationForm.php

<?php

namespace Drupal\mon_module\Form;

use Drupal\Core\Form\FormStateInterface;
use Drupal\system\Form\SiteInformationForm;


class BasicSiteInformationForm extends SiteInformationForm {

  public function buildForm(array $form, FormStateInterface $form_state) {
    $config = $this->config('system.site');
    $form = parent::buildForm($form, $form_state);
    // On ajoute nos champs
    $form['site_information']['email_service_commercial'] = [
      '#type' => 'email',
      '#title' => t('Adresse email Service Commercial'),
      '#default_value' => $config->get('email_service_commercial') ?? '',
      '#description' => t("Adresse à laquelle sera envoyée les notifications de création de compte"),
      '#required' => TRUE,
    ];
    return $form;
  }

  public function submitForm(array &$form, FormStateInterface $form_state) {
    // Et on les enregistre
    $this->config('system.site')
      ->set('email_service_commercial', $form_state->getValue('email_service_commercial'))
      ->save();
    parent::submitForm($form, $form_state);
  }
}

Et voila : 

Image

Les raisons peuvent être diverses, mais parfois on veut que certaines tables soient dans une base de données spécifique au lieu de la principale. 

Dans mon cas c'est lors d'un déploiement « bleu / vert ». 

J'ai deux bases de données : prod_a et prod_b, la prod_a est la base active. 

Voici le processus de mise en prod simplifié

La base de données de staging est copiée sur la base de prod non active : prod_b.Une copie de certaines tables (watchdog, inscrits_newsletter...) et faite depuis la base prod_a vers prod_b.Bascule entre les deux base de prod, la prod_b devient la base active et la prod_a ne sert plus.

dans les faits, cela fonctionne, mais l'étape 2 peut-être longue. Pour gagner du temps on peut mettre les tables qui ne doivent pas être écrasées sur une troisième base que l'on appellera prod_common.

voici la définition classique d'une base de données drupal :

 $databases['default']['default'] = [
  'database' => 'prod',
  'username' => 'user',
  'password' => 'password',
  'prefix' => '',
  'host' => '',
  'port' => '3306',
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
];

nous allons définir maintenant une seconde base prod_common 

 $databases['default']['common'] = [
  'database' => 'prod_common',
  'username' => 'user',
  'password' => 'password',
  'prefix' => '',
  'host' => '',
  'port' => '3306',
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
];

Notez bien le changement de clé dans le nom de la base :  $databases['default']['common']

Maintenant pour spécifier quelles tables doivent être dans quel schema, nous allons utiliser l'attribut prefix de notre définition, voici la version complète : 

 $databases['default']['default'] = [
  'database' => 'prod',
  'username' => 'user',
  'password' => 'password',
  'prefix' => [
    'default' => '', // par défaut, tout doit être dans le schéma par défaut
    'watchdog' => 'prod_common.', // la table watchdog va elle dans la base prod_common (attention au point)
    'inscrits_newsletter' => 'prod_common.', // idem pour la table inscrits_newsletter
  ],
  'host' => '',
  'port' => '3306',
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
];

// Je duplique la définition de ma base prod en modifiant uniquement le nom de la base de données
$databases['default']['common'] = $databases['default']['default'];
$databases['default']['common']['database'] = 'prod_common';

Et voila, pour les deux tables spécifiées, drupal ira chercher et enregistrer les informations sur la base prod_common.

Vous avez un site internet Drupal en version 8 ou 9, votre prestataire vous propose une mise à jour en drupal 10 alors que votre site marche très bien ? Nous allons voir pourquoi cela reste une bonne idée.

Note : ce post est rédigé à destination de plusieurs agences avec lesquelles je travaille afin de fournir un argumentaire pour pousser cette montée de version aux clients finaux.

La sécurité

La dernière version de Drupal 8 (8.9.20) est arrivée en fin de vie en novembre 2021.

La dernière version de Drupal 9 (9.5.11) est arrivée en fin de vie en novembre 2023.

Drupal 7 lui a vu sa date de fin de vie plusieurs fois repoussée, maintenant fixée à janvier 2025.

C'est-à-dire que ces versions ne reçoivent plus de mise à jour, et si une faille de sécurité est découverte, en théorie elle ne sera pas corrigée. Dans les faits, lors de certaines grosses failles impactant le core de drupal, des patchs avaient été créés même pour les versions théoriquement non supportées. Mais rien ne dit que ce sera le cas à l’avenir.

La version actuelle de drupal (10.2.2) sera supportée jusqu’à décembre 2024. Cela peut sembler peu, mais depuis Drupal 8, les mises à jour de version intermédiaires (de 10.1.x à 10.2.x) sont grandement simplifiées. En suivant ces mises à jour régulièrement, une version intermédiaire sortant tous les 6 mois, la date de fin de vie est repoussée d’autant.

Les mises à jour de versions majeures (9.x à 10.x par exemple) demandent un peu plus de temps, mais n’ont rien à voir avec une mise à jour depuis la version 7 vers une version supérieure, qui nécessite une réécriture du code ainsi qu’un travail de migration du contenu.

Au-delà de cette migration « one shot », il est stratégique de prévoir avec votre prestataire un accompagnement régulier pour maintenir le core de drupal ainsi que les modules à jour, de faire les mises à jour intermédiaires (10.1.x vers 10.2.x par exemple) régulièrement. Ainsi vous avez l’assurance d’avoir un site supporté au niveau de la sécurité, et que les mises à jour majeures (10.x vers la future 11.x) soient le plus indolore possible.

Permettre l’évolutivité de votre site

L’autre gros avantage de mettre son site à jour et de le garder maintenable et permettre les évolutions. Aujourd’hui rares sont les modules drupal contrib qui sorte une nouvelle version encore compatible avec drupal 9, encore moins avec drupal 8. 

Vous risquez ainsi de vous retrouver rapidement bloqué et que toute nouvelle fonctionnalité nécessite un développement spécifique qui sera plus long que l’activation et la configuration d’un module existant, donc plus cher. 

Même pour du développement spécifique, à chaque nouvelle version de drupal, son API évolue et propose de nouvelles fonctionnalités pour le code et le theming.

Les prérequis évoluent aussi, ainsi pour drupal 10 la version minimale de php est la 8.1, qui apporte là aussi de nouvelles fonctions et améliorations de performances.

Profiter de nouvelles fonctionnalités

Le code change mais l'expérience d’administration évolue aussi, à chaque nouvelle version de drupal, des modules core sont améliorés, certains remplacés par d’autres. 

On pourra notamment citer dans les nouveautés de drupal 10 : 

Le remplacement de l’éditeur de texte Ckeditor 4 par Ckeditor 5

Image

Le changement du thème d’administration : claro (en remplacement de Seven qui date de drupal 7, comme son nom l’indique)

Image

Un nouveau concept de « workspace », qui permet d’avoir plusieurs versions de son site avec les différentes révisions de contenu. Une version « Prod » pour ce qui est visible pour les internautes, une version « Staging » pour le contenu en validation.

Combien ça va me couter ?

Ça dépend. 

Oui évidemment. 

Là ou une mise à jour de drupal 7 vers drupal 10 peut-être considérée comme une refonte complète et nécessite une réécriture complète du code, les mises à jour depuis drupal 8 vers drupal 10 sont elles plus simples. le framework bas niveau reste le même. Il faudra juste à votre prestataire de faire les mises à jour des modules « contrib » (les modules communautaires), adapter le code « custom » (code métier, développé spécifiquement pour votre site) en corrigeant les fonctions dépréciées… 

Comme je l’ai dis plus tôt, une montée de version de drupal entraîne aussi généralement une montée de version de PHP, qui peut là aussi nécessiter des modifications du code custom pour la compatibilité.

Suivi donc la complexité du code custom, l’utilisation de modules contrib un peu exotiques, une montée de version de drupal 9 à drupal 10 peut nécessiter d’une demie journée à 2-3 jours, voir plus sur certains projets très complexes.

Des outils pour aider dans cette migration

Il existe pour les développeurs des outils pour gagner du temps lors de cette migration : 

Upgrade Status

 Upgrade

Module permettant d'avoir un tableau de bord pour préparer la mise à jour de son site drupal, que ça soit de drupal 8 à drupal 9 ou de drupal 9 à drupal 10.

Il liste les modules tiers (contrib) qui sont à mettre à jour, permet de scanner les modules et thèmes custom pour signaler les appels de fonctions dépréciés. 

Lire la suite de Upgrade Status

Rector

 Upgrade

Scan votre code custom et remplace automatiquement les appels de fonction dépréciés par leur remplaçants.

Cela fonctionne à la fois pour Drupal lors d'une montée de version, mais aussi pour les montées de version de PHP.

Lire la suite de Rector