Planète

Par kgaut
Kevin Gautreau

Drupal 10 - Créer un Event, le lancer et l'intercepter

Version actualisée de Drupal 8 - Créer un Event, le lancer et l'intercepter pour drupal 10+

Nous allons voir ici comment créer un Event, le lancer et l'intercepter.

Cet évènement sera lancé lorsqu'un utilisateur se connecte au site.

Création de l'event

Dans modules/monmodule/src/Event/UserLoginEvent.php

<?php

namespace Drupal\monmodule\Event;

use Drupal\user\UserInterface;
use Drupal\Component\EventDispatcher\Event;

/**
* Event that is fired when a user logs in.
*/
class UserLoginEvent extends Event {

  const EVENT_NAME = 'kgaut_tools_user_login';

  /**
   * The user account.
   *
   * @var \Drupal\user\UserInterface
   */
  public $account;

  /**
   * Constructs the object.
   *
   * @param \Drupal\user\UserInterface $account
   *   The account of the user logged in.
   */
  public function __construct(UserInterface $account) {
    $this->account = $account;
  }
}

Lancement de l'Event (dispatcher)

Dans mon cas en particulier, je dois répondre lorsqu'un utilisateur se connecte, je vais donc utiliser le hook HOOK_user_login.

Dans modules/monmodule/monmodule.module

function monmodule_user_login($account) {
  $event = new \Drupal\monmodule\Event\UserLoginEvent($account);
  /** @var \Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher $event_dispatcher */
  $event_dispatcher = \Drupal::service('event_dispatcher');
  $event_dispatcher->dispatch($event, $event::EVENT_NAME);
}

Interception de l'évènement (Subscriber)

Nous allons pour cela créer un EventSubscriber.

Dans modules/monmodule/src/EventSubscriber/UserLoginSubscriber.php

<?php

namespace Drupal\monmodule\EventSubscriber;

use Drupal\monmodule\Event\UserLoginEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class UserLoginSubscriber implements EventSubscriberInterface {

  public static function getSubscribedEvents() {
    // Ici on défini pour chaque évènement, la méthode à utiliser
    return [UserLoginEvent::EVENT_NAME => 'UserLoginCallback'];
  }

  public function UserLoginCallback(UserLoginEvent $event) {
    $account = $event->account;
    //Ici faire le traitement voulu
  }

}

Note : Pour cette dernière partie, il est aussi possible d'utiliser la commande drush :

drush generate service:event-subscriber
Par kgaut
Kevin Gautreau

Drupal - Utiliser une autre base de données pour certaines tables

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.

Par kgaut
Kevin Gautreau

Drupal - Créer son premier service

En anglais, une bonne ressource pour créer son premier service avec Drupal.

Une fois le principe compris, il existe aussi la commande 

drush generate service:custom
Par kgaut
Kevin Gautreau

Pourquoi faire la mise à jour drupal 10 ?

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
Ckeditor 5

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

Image
Thème BO claro

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

Par kgaut
Kevin Gautreau

Drupal - Nouveau module : Database Dashboard

Il y a quelques semaines, souci rencontré sur un projet client avec une base de données qui grossissait de manière anormale. Ne gérant pas l'hébergement pour ce projet, je n'ai eu aucune alerte, avant que le site plante car le serveur de base de données n'avait plus d'espace disque disponible.

Quelques requêtes plus tard nous avons pu identifier les tables fautives et donc les causes.

Afin de surveiller ça de manière basique, j'ai alors développé un petit module drupal qui affiche les tables avec le plus de lignes et les tables qui prennent le plus d'espace disque. Et la même chose pour les tables de cache au passage.

Image
Tableau de bord Base de données

J'ai pris le temps de packager le module sur drupal.org, car je me suis dis qu'il pourrait être utile à d'autres (et à moi pour d'autres projets).

La page drupal.org est la suivante : https://www.drupal.org/project/database_dashboard

Installation

Comme n'importe quel module drupal : 

composer require drupal/database_dashboard

Il vous faudra modifier le fichier settings.php ou settings.local.php et ajouter les lignes suivantes à la fin :

$databases['schema']['default'] = [
  'host' => 'mariadb', // À adapter
  'database' => 'information_schema',
  'username' => 'drupal', // À adapter
  'password' => 'drupal', // À adapter
  'prefix' => '',
  'port' => '3306',
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
];

Activez le module via le backoffice ou via drush.

Ensuite rendez-vous sur /admin/reports/database ou via le menu d'administration : Rapports / Database Dashboard afin de consulter la page.

Rien de révolutionnaire, mais ça peut servir. 

N'hésitez-pas si vous avez des idées d'indicateurs à ajouter !

 

Par kgaut
Kevin Gautreau

Drupal - Modifier de la config directement via drush

Parfois cela peut dépanner d'aller modifier directement une clé de config depuis son terminal.

C'est là que drush avec la commande config:edit (alias : cedit) vient à la rescousse.

par exemple, si l'on souhaite désactiver le cache et l'aggregation des fichiers css et js :

drush cedit system.performance

Ouvrira dans votre éditeur par défaut la config et vous n'aurez qu'à modifier ce que vous souhaitez

Image
Drush cedit

Enregistrez et les modifications seront directement faites en base de données.

Image
Drush cedit result

Attention, cela modifiera la configuration en base de données, mais pas celle exportées en fichiers YAML. 

Pour conserver vos modifications, pensez à les exporter via la commande drush config:export (ou drush cex)

Si vous ne savez pas quel fichier de config utiliser, la commande drush cedit sans paramètre vous listera toutes les clés de configuration :

$ drush cedit                                                                                                                                                                                                                  

Choose a configuration:
  [0  ] announcements_feed.settings
  [1  ] automated_cron.settings
  [2  ] block.block.claro_breadcrumbs
  [3  ] block.block.claro_content
  [4  ] block.block.claro_help
  [5  ] block.block.claro_help_search
  [6  ] block.block.claro_local_actions
  [7  ] block.block.claro_messages
  [8  ] block.block.claro_page_title
  [9  ] block.block.claro_primary_local_tasks
  [10 ] block.block.claro_secondary_local_tasks
  [11 ] block.block.olivero_account_menu
...

 

Par kgaut
Kevin Gautreau

Drupal & GCS écrire un fichier via le code

Voici comment écrire directement dans un Bucket Google Cloud Storage depuis un script drupal (ou une migration) via le module flysystem_gcs.

Ici une POC via un script drush : 

<?php
use League\Flysystem\Config;
$path ="test/sous-dossier";
$filename ="mon-fichier-2";
$fileContent = "Bonjour";
/** @var \Drupal\flysystem\FlysystemFactory $flyeSystemFactory */
$flySystemFactory = \Drupal::service('flysystem_factory');
/** @var \Drupal\flysystem_gcs\Flysystem\Adapter\GoogleCloudStorageAdapter $cloudStorageAdapter */
$cloudStorageAdapter = $flySystemFactory->getPlugin('cloud-storage')->getAdapter();
$cloudStorageAdapter->write("$path/$filename", $fileContent, new Config());

À noter, la clé cloud-storage, correspond à la définition dans votre fichier settings.php, dans mon cas : 

$settings['flysystem'] = [
  'cloud-storage' => [
    'driver' => 'gcs',
    'config' => [
      'bucket' => XXX,
      'keyFilePath' => XXX,
      'projectId' => XXX,
      '_localConfig' => [
        'prefix' => '',
      ],
    ],
    'cache' => true,
  ],
];

 

Par Artusamak
Julien Dubois

Guide pour préparer et suivre la migration de vos contenus web

Guide pour préparer et suivre la migration de vos contenus web
stephanie@happyculture.coop
jeu 15/06/2023 - 11:22
Guide pour préparer et suivre la migration de vos contenus web

Découvrez les étapes clés et nos conseils pour éviter les écueils et bien préparer votre migration de contenu afin de préserver votre SEO.

Contributeurs multiples
Blog, par 2 auteurs, le 15 juin 2023
Temps de lecture estimé : 6 minutes

Pages