Planète

Avec l'arrivée prévue le 3 juin 2020 de drupal 9, il n'y a pas besoin de créer une branche 9.x-1.x spécifiquement pour drupal 9, vous pouvez facilement indiquer que votre module est compatible avec cette nouvelle version en ajoutant dans votre fichier mon_module.info.yml la clé suivante :

core_version_requirement: ^8 || ^9

La clé core est à conserver pour garder la compatibilité avec les versions inférieures à drupal 8.7.7 (oui c'est d'un pratique...) Exemple dans un de mes modules.

En outre, il en sera bientôt terminé des versions de module "8.x-1.0", le versionnement sémantique est adopté et est compatible à partir de drupal 8.8.3, C'est à dire que les nouvelles branches de vos projets seront nommées 2.x (au lieu de 8.x-2.x) et les tags (versions) pourront être sous la forme :

2.0.0-beta1
2.0.0
2.0.1
2.1.0

Si vous passez au versionnement sémantique, les numéros de versions doivent être incrémentés, ainsi, si actuellement vous avez actuellement une branche 8.x-2.x, conservez là pour toutes les versions de drupal inférieures à 8.8.3, mais vous pouvez dès maintenant créer une branche 3.x pour la compatibilité avec les versions 8.8.3+ et 9.0.0 de drupal.

Il est possible de spécifier qu'une branche ne sera compatible qu'avec drupal 9 dans le fichier info.yml :

core_version_requirement: ^9

Plus d'informations sur le versionnement sémantique

Plus d'informations sur les changements du fichier mon_module.info.yml

tl;dr

Si vous avez un module avec une branche 8.x-2.x :

Votre module est compatible avec drupal 9 : vous pouvez ajouter la clé "core_version_requirement: ^8 || ^9" à votre module.info.yaml (c'est ce que j'ai fais pour mon mini module popin : https://www.drupal.org/project/popin. Vous pourrez passer au versionnement sémantique pour la prochaine version majeure de votre module
Votre module nécessite de plus gros travaux pour être rendu compatible, vous pouvez garder la branche 8.x-2.x pour drupal 8 et démarrer une branche 3.x qui sera une branche de travail pour drupal 9.

Il peut être parfois utile de vouloir relancer un hook_update_n, pour ce faire vous pouvez utiliser cette commande drush. Dans cette exemple, je veux rejouer le hook my_paragraph_update_8001

drush ev "drupal_set_installed_schema_version('my_paragraph', '8000');" ; drush updb

Apidae tourisme est un « réseau d'informations touristiques » qui permet aux offices du tourisme, mairies... De créer des « lieux » (restaurants, hôtels...) ainsi que des évènements sur des cartes de manière collaborative.

Dans le cadre d'un ancien projet, j'avais du développer une intégration avec l'API de ce service et un site drupal. J'avais à l'époque développé ce module sur github afin de peut-être un jour le mettre à disposition de tous. Un drupalistos m'a signalé récèment qu'il était listé sur la page des intégrations disponible sur la doc développeur d'Apidae.

Rebelote pour un projet que je vais attaquer, du coup j'ai pris un peu de temps pour packager le module que j'avais développé à l'époque, le nettoyer un peu afin de le publier sur drupal.org. C'est chose faite aujourd'hui !

Le module permet à intervalle régulier de synchroniser les données venant d'Apidae et de créer / mettre à jours des nœuds en récupérant différents champs (noms, description, médias, téléphone, coordonnés GPS...)

Le module gère le multi-langue et on peut ainsi récupérer des traductions des fiches et générer des traductions des nœuds.

Actuellement seulement certains champs sont mappés, mais je compte rendre ça administrable dans un futur proche.

Je suis preneur de suggestions et n'hésitez-pas à me contacter si vous souhaitez de l'aide ou des informations dans sa mise en œuvre.

La page du module sur drupal.org : https://www.drupal.org/project/apidae_tourisme

Les contextual filters ou filtres contextuels sont une fonctionnalité très utile du module views de drupal : il permettent, comme le nom l'indique de filtrer les éléments affichés en fonction d'un paramètre contextuel (lié à un nœud, à l'internaute, un paramètre GET...).

Certains sont fournis de base avec drupal mais ils ne conviennent pas forcement à tous les cas d'utilisation.

Dans le cas présent, le but est de filtrer des nœuds en fonction de la localité de l'utilisateur (techniquement un terme de taxonomie) afin que l'utilisateur ne visualise que les nœuds qui concerne sa commune. Les nœuds ont un champ « référence à un terme de taxonomie » multiple, même chose pour l'utilisateur mais simple pour lui. Donc un nœud peut concerner plusieurs communes alors qu'un utilisateur n'appartient qu'à une seule commune.

Création du filtre contextuel :

# web/modules/custom/mon_module/src/Plugin/views/argument_default/UserLocalite.phpisAnonymous()) {      return 'all';    }    $user = User::load($user->id());    // getLocalitesId() est une methode personnalisée de la classe User    // qui retourne l'id du terme de taxonomy de la localité    return $user->getLocalitesId();  }   // Ma classe implémentant CacheableDependencyInterface, on peut ainsi ajouter des paramètres   // de cache, si ça n'est pas nécessaire, il suffit de supprimer l’implémentation et les deux méthodes ci-dessous.  public function getCacheMaxAge() {    return Cache::PERMANENT;  }   public function getCacheContexts() {    return ['user:localite'];  }}

Il nous reste plus qu'à sélectionner le filtre dans la liste des filtre contextuels de drupal, en choisissant bien le champs sur lequel le filtre doit s'appliquer (dans mon cas : node.localites_cibles) :

La page par défaut de liste des termes de taxonomie de drupal 8 n'est pas très flexible. Elle peut facilement être substituée à une vue mais dans ce cas on perd le « drag'n'drop » dans le cas d'une arborescence.

Pour garder ce comportement, mais pouvoir quand même ajouter des colonnes, il est possible de surcharger le formulaire gérant cette page.

Cela se passe en 3 étapes :

1. Déclaration du service d'alteration de la route

# mon_module.services.ymlservices:  mon_module.route_subscriber:    class: Drupal\mon_module\Routing\VocabularyOverviewRouteProvider    tags:      - { name: event_subscriber }

2. Altération de la route

get('entity.taxonomy_vocabulary.overview_form');    // Make a change for default taxonomy overview form.    $route->setDefault('_form', VocabularyOverviewTerms::class);    // Re-add the collection to override the existing route.    $collection->add('entity.taxonomy_vocabulary.overview_form', $route);  } }

3. Surcharge du formulaire

Note : Ici je ne modifie le formulaire que pour un seul vocabulaire (etudiant_promos) et j'ajoute une colonne « Domain ».

id() !== 'etudiant_promos') {      return $form;    }    // On ajoute l'entête du tableau    $form['terms']['#header']['domain'] = $this->t('Domain');     // On parcours les ligne pour ajouter notre colonne    foreach ($form['terms'] as $key => &$termRow) {      if(strpos($key, 'tid:') === 0) {        /** @var \Drupal\taxonomy\Entity\Term $term */        $term = Term::load($termRow['term']['tid']['#value']);        /** @var \Drupal\domain\Entity\Domain $domain */        $domain = $term->get('domain')->referencedEntities()[0];        $termRow['domain'] = ['#markup' => $domain->label()];      }    }    return $form;  } }

Les champs WYSIWYG prennent une place de plus en plus important dans la construction des pages web modernes.

Voici comment utiliser les WYSIWYG, les configurer et comment ajouter des fonctionnalités sous Drupal 8.

Pour convertir un champ texte long (ici: field_communiques_texte_wysiwig) en texte log formaté, il suffit de créer un .install dans un module contenant l'exemple ci-dessous :