Migration d'un site Drupal 7 en Drupal 9
Trucs, astuces et bouts de code pour migrer votre site web de Drupal 7 à Drupal 9
Trucs, astuces et bouts de code pour migrer votre site web de Drupal 7 à Drupal 9
Petite vidéo que je souhaitais faire depuis longtemps : une présentation de l'utilitaire numéro 1 de tout·e développeur·euse Drupal : Drush !
Drush est un utilitaire en ligne de commande, qui fonctionne sous linux, windows et macos permettant d'exécuter des commandes d'administration sur son site Drupal :
Vidage de cache
Activation de module
Export / Import de configuration (voir mon autre vidéo sur la gestion de la configuration)
Et plein d'autres choses
Depuis quelques temps, drush s'interface avec Drupal Code Generator, et permet de scaffolder des modules, des types d'entités, des formulaires des blocs et bien d'autres chose. Cette fonctionnalité est très pratique et je l'utilise presque tous les jours. C'est ce que permettait de faire drupal console, qui du coup est maintenant beaucoup moins utile.
Dans la vidéo qui suit je vous présente les bases de drush, les commandes de base et les générateurs.
Retrouver le support à l'adresse suivante : https://slides.kgaut.net/presentations/2021/drush.html
Quelques liens utiles :
Le site officiel de Drush : https://www.drush.org
Drush Launcher : https://github.com/drush-ops/drush-launcher
Liste des commandes drush : https://www.drush.org/latest/commands/all/
Rejoignez la communauté Drupal francophone et contribuez aux différents projets Drupal lors de ce week-end spécial de contribution les samedi 30 et dimanche 31 janvier prochains.
Les DrupalCamp, les DrupalCon et les différentes rencontres vous manquent sûrement. Elles nous manquent aussi , mais également à notre projet préféré.
Ce week-end de contribution sera l'occasion pour nous de nous retrouver et travailler. Ensemble, comme lors des évènements qui nous manquent tant.
En cette période particulièrement difficile que nous traversons, le télétravail est devenu pour la plupart d'entre nous un état de fait. Nous, développeurs et développeuse construisions notre communauté par les moments de travail, les moments de partages associatifs et communautaires avec nos proches, nos amis, et des personnes que nous découvrions par le biais des rencontres. Notre réseau personnel, notre réseau professionnel, comme nos rencontres issues du monde associatif, ou amical; rencontrer des ami•e•s d'ami•e•s... tout cela est devenu très très difficile.
C'est pour cela que ce week-end, bien sûr en ligne, et ne remplaçant en rien une journée de contribution classique, sera pour nous toutes et tous l'occasion de nous tous nous retrouver.
Nous comptons sur votre présence.
Afin de créer des groupes de travail et les espaces de collaboration qui leurs seront dédiés, nous vous invitons à vous inscrire sur ce fichier tableur, en ajoutant une ligne sous le projet sur lequel vous seriez disponible pour participer :
https://docs.google.com/spreadsheets/d/1uwGmBLba4Qf2B81WPBw8uFCndMYrpGzT...
N'hésitez pas à ajouter votre nom à un projet existant, ajouter un projet sur lequel vous souhaitez intervenir (et vous nommer référent si besoin), mais aussi renseigner vos disponibilités sur les journées de samedi 30 et dimanche 31 janvier 2021.
Si vous rencontrez le moindre soucis, ou avez la moindre question, contactez le bureau de l'association Drupal France et Francophonie par email sur bureau@drupal.fr ou plus simplement sur notre slack drupalfrance.slack.com dans le canal #contrib .
De nombreux projets ont besoin de votre soutien.
Rejoignez la communauté Drupal francophone et contribuez aux différents projets Drupal lors de ce week-end spécial de contribution les samedi 30 et dimanche 31 janvier prochains.
Les DrupalCamp, les DrupalCon et les différentes rencontres vous manquent sûrement. Elles nous manquent aussi , mais également à notre projet préféré.
Ce week-end de contribution sera l'occasion pour nous de nous retrouver et travailler. Ensemble, comme lors des évènements qui nous manquent tant.
En cette période particulièrement difficile que nous traversons, le télétravail est devenu pour la plupart d'entre nous un état de fait. Nous, développeurs et développeuse construisions notre communauté par les moments de travail, les moments de partages associatifs et communautaires avec nos proches, nos amis, et des personnes que nous découvrions par le biais des rencontres. Notre réseau personnel, notre réseau professionnel, comme nos rencontres issues du monde associatif, ou amical; rencontrer des ami•e•s d'ami•e•s... tout cela est devenu très très difficile.
C'est pour cela que ce week-end, bien sûr en ligne, et ne remplaçant en rien une journée de contribution classique, sera pour nous toutes et tous l'occasion de nous tous nous retrouver.
Nous comptons sur votre présence.
Afin de créer des groupes de travail et les espaces de collaboration qui leurs seront dédiés, nous vous invitons à vous inscrire sur ce fichier tableur, en ajoutant une ligne sous le projet sur lequel vous seriez disponible pour participer :
https://docs.google.com/spreadsheets/d/1uwGmBLba4Qf2B81WPBw8uFCndMYrpGzT...
N'hésitez pas à ajouter votre nom à un projet existant, ajouter un projet sur lequel vous souhaitez intervenir (et vous nommer référent si besoin), mais aussi renseigner vos disponibilités sur les journées de samedi 30 et dimanche 31 janvier 2021.
Si vous rencontrez le moindre soucis, ou avez la moindre question, contactez le bureau de l'association Drupal France et Francophonie par email sur bureau@drupal.fr ou plus simplement sur notre slack drupalfrance.slack.com dans le canal #contrib .
De nombreux projets ont besoin de votre soutien.
Le système de configuration de Drupal 9 stock l’ensemble des informations du site (blocks, vues, types de champs et de contenus, taxonomie…) sans inclure les données (contenu des blocks, terme de taxonomie, valeur des champs, ...). Dans Drupal 7 le système de configuration était stockée dans la base de données, ce qui rendait difficile le transfert d’une copie du site, en particulier si des modules (extensions) modifiaient la configuration.
Cette enquête a été lancée afin de récolter les salaires des Drupalistes en France et dans les pays francophones pour faire un état des lieux des rémunérations dans l’écosystème Drupal. Son but : réaliser un baromètre des salaires au sein de notre communauté, et vous proposer cet outil de comparaison. Cette enquête a eu lieu du 19 Juin au 31 août 2020 et vous avez été 76 à y répondre. Nous vous en remercions.
Il est à noter que sur l’intégralité des réponses que nous avons recueillies, seuls 68 d’entre vous ont renseigné la région dans laquelle ils étaient employés. Les autres items ont tous été pleinement renseignés.
Les réponses à cette enquête sont intéressantes et révélatrices d’un milieu masculin dominé principalement par les agences et ESN (Entreprise de service numérique). Si plus de 90 % des personnes ayant répondu sont des hommes, plus de la moitié d’entre vous a entre 30 et 40 ans.
Côté salaire, vous vous placez entre 33 500 et 67 000€. Si la fourchette est assez grande, vous êtes un peu plus de la moitié à trouver que vous êtes un peu sous-payés, et un peu plus d’un quart à trouver que votre salaire correspond à vos activités.
Il serait difficile de parler de ce sondage en 2020 sans parler télétravail avec la crise sanitaire que nous traversons. Il est encourageant de voir que dans un domaine permettant facilement le travail à distance, plus de la moitié des personnes ayant répondu à cette enquête a le droit à du télétravail partiel, voire total, même si un peu moins d’un quart d’entre vous n’y a pas droit.
Choix ou obligation, notre enquête ne le dit pas. Nous rajouterons cette question dans la prochaine édition du sondage.
Lors de la création du formulaire de cette enquête, notre équipe a oublié de proposer l’item “30 - 34 heures” de travail effectué par semaine. Nous nous en excusons et vous le proposerons l’année prochaine.
Ces informations sont à mettre en corrélation avec les aménagements de postes effectués dans le cadre de la crise sanitaire du COVID-19.
Nous vous prions à nouveau de nous excuser pour avoir oublié l’item “6 à 10 par ans”. Nous le mettrons bien sûr dans la prochaine édition.
Si le domaine du web est un milieu très masculin qui tente de changer, nous avons voulu en savoir plus dans la communauté Drupal et le jugement est sans appel.
Nous en avons profité pour regarder un peu la moyenne des salaires par genre, ce qui donne
Merci à tous d’avoir répondu à ce sondage, si vous souhaitez poser des questions ou en savoir plus n’hésitez pas à nous contacter sur slack, ça sera un plaisir que d’en discuter avec vous.
Cette enquête a été lancée afin de récolter les salaires des Drupalistes en France et dans les pays francophones pour faire un état des lieux des rémunérations dans l’écosystème Drupal. Son but : réaliser un baromètre des salaires au sein de notre communauté, et vous proposer cet outil de comparaison. Cette enquête a eu lieu du 19 Juin au 31 août 2020 et vous avez été 76 à y répondre. Nous vous en remercions.
Il est à noter que sur l’intégralité des réponses que nous avons recueillies, seuls 68 d’entre vous ont renseigné la région dans laquelle ils étaient employés. Les autres items ont tous été pleinement renseignés.
Les réponses à cette enquête sont intéressantes et révélatrices d’un milieu masculin dominé principalement par les agences et ESN (Entreprise de service numérique). Si plus de 90 % des personnes ayant répondu sont des hommes, plus de la moitié d’entre vous a entre 30 et 40 ans.
Côté salaire, vous vous placez entre 33 500 et 67 000€. Si la fourchette est assez grande, vous êtes un peu plus de la moitié à trouver que vous êtes un peu sous-payés, et un peu plus d’un quart à trouver que votre salaire correspond à vos activités.
Il serait difficile de parler de ce sondage en 2020 sans parler télétravail avec la crise sanitaire que nous traversons. Il est encourageant de voir que dans un domaine permettant facilement le travail à distance, plus de la moitié des personnes ayant répondu à cette enquête a le droit à du télétravail partiel, voire total, même si un peu moins d’un quart d’entre vous n’y a pas droit.
Choix ou obligation, notre enquête ne le dit pas. Nous rajouterons cette question dans la prochaine édition du sondage.
Lors de la création du formulaire de cette enquête, notre équipe a oublié de proposer l’item “30 - 34 heures” de travail effectué par semaine. Nous nous en excusons et vous le proposerons l’année prochaine.
Ces informations sont à mettre en corrélation avec les aménagements de postes effectués dans le cadre de la crise sanitaire du COVID-19.
Nous vous prions à nouveau de nous excuser pour avoir oublié l’item “6 à 10 par ans”. Nous le mettrons bien sûr dans la prochaine édition.
Si le domaine du web est un milieu très masculin qui tente de changer, nous avons voulu en savoir plus dans la communauté Drupal et le jugement est sans appel.
Nous en avons profité pour regarder un peu la moyenne des salaires par genre, ce qui donne
Merci à tous d’avoir répondu à ce sondage, si vous souhaitez poser des questions ou en savoir plus n’hésitez pas à nous contacter sur slack, ça sera un plaisir que d’en discuter avec vous.
Drupal est l’un des meilleurs systèmes de gestion de contenu libre open-source. En effet, ce CMS est notamment connu pour ses fonctionnalités importantes, telles que la fiabilité, la flexibilité, l’évolutivité, ou encore la performance. Lancé sur le marché en 2000, Drupal comprend plusieurs versions à son actif : Drupal 7, 8 et 9.
Gin est mon thème backoffice coup de coeur de ces derniers mois, il donne un coup de fouet au backoffice de drupal !
Gin
Thème
Backoffice
Gin est un thème backoffice « moderne » qui intègre un mode dark.
En cours de test de mon côté, pour l'instant je suis convaincu, on verra si ça tiens dans la durée.
Modules additionnels recommandés :
gin_toolbar : Fournir une toolbar optimisée pour le thème
gin_login : Un bel écran de connexion !
Lire la suite de Gin
Il est possible de lui adjoindre une feuille de style css pour surcharger quelques propriétés sans avoir à lui créer un thème enfant, très pratique !
Pour cela rien de plus simple, il suffit de créer un fichier gin-custom.css dans le répertoire public:// donc la plupart du temps : web/sites/default/files/gin-custom.css.
Attention, généralement, ce dossier est exclu du versionning, mais il est possible de forcer l'ajout d'un fichier avec la commande :
git add -f web/sites/default/files/gin-custom.css
Note : cette manipulation est possible depuis la version 8.x-3.0-alpha31, sortie le 02 décembre 2020 (plus d'informations ici : https://www.drupal.org/project/gin/issues/3179676)
Encore mieux, ce thème utilise des variables CSS pour les couleurs, si vous souhaitez changer les couleurs de « focus » c'est possible avec les lignes suivantes, à ajuster en fonction de vos goûts :
* { --colorGinPrimary: #cc7700; --colorGinFocus: #cc7700; --colorGinPrimaryActive: #ff9900; --colorGinPrimaryHover: #ff9900;}
Petit article un peu particulier afin de présenter mon dernier side-project : un outil de gestion de mes projets de maintenance.
Jusqu'à peu, je gérais mes projets de maintenance dans des feuilles de calcul où pour chaque intervention, je notais le temps passé, pour ensuite facturer en fin de mois.
Dans le même temps, je travaille avec de multiples clients qui ont chacun leur système de ticket (github, gitlab.com, gitlab auto-hébergé, pivotal tracker...) et donc je n'avais pas non plus de vue globale sur l'ensemble de mes tickets à traiter au niveau de tous mes clients.
Tombant par hasard sur un module drupal gitlab_api, l'idée m'est venue de faire un outil pour lister l'ensemble de mes tickets gitlab (avec dans l'idée ensuite de faire des connecteurs avec d'autres systèmes). Le module n'accepte par défaut la connexion à un seul serveur, j'ai donc proposé une nouvelle fonctionnalité : l'utilisation de config entities, afin de gérer de multiples connexions (gitlab.com, et autant de gitlab auto-hébergés que nécessaires).
J'ai par la suite développé un module équivalent pour me connecter à l'api de github, puis un autre pour me connecter à pivotal tracker.
Image
Image
L'idée ensuite est de pouvoir ajouter des « clients » et de leur affecter un projet.
Voici la liste des clients, avec vision des tickets en cours, du CA global, du CA en attente de facturation...
Image
Chaque projet étant lié à un dépôt gitlab / github / pivotal tracker :
Image
Ainsi, automatiquement sont récupérés les tickets liés à ce projet. Chaque ticket peut-être estimé si le client le demande.
Image
Ces tickets sont récupérés et mis à jour à intervalle régulier, via une tache cron.
Sur la capture précédente, on voit l'ensemble des tickets (clôturé ou actif) d'un seul projet, mais via les filtres au-dessus du tableau, je peux voir l'ensemble des tickets au niveau global / par client / par projet…
Ensuite, à chaque ticket, je peux affecter une « tâche », correspondant à une intervention effectuée sur le projet et qui devra être facturée.
Image
Ces tâches sont enfin visibles sur un tableau de bord, lui aussi filtrable par client / projet / ticket / statut de facturation / facture :
Image
En fin de période de facturation, je sélectionne les tâches que je souhaite facturer et renseigne mon numéro de facture, ainsi ces tâches passent en état « facturé ». L'intégration avec ma solution de comptabilité n'est pas encore faite, mais le processus de création est grandement simplifié, je n'ai quasiment plus qu'à saisir le total.
Le client à lui aussi accès à un tableau de bord, où il peut voir toutes ses tâches en cours, et donc les dépenses engagées. Il peut aussi consulter le détail d'une facture :
Image
Chaque intervention était liée à un ticket, en cliquant sur le lien, il tombera directement sur le ticket correspondant sur gitlab / github / pivotal tracker…
J'ai pu importer tous mon historique de tâches qui étaient dans des google docs en passant par des fichiers csv et un petit script de parsage.
Au niveau technique c'est un petit drupal 9.1.0 (mis à jour hier, jour de la sortie de la première version stable) avec peu de modules activés.
Les clients, projets, tickets et tâches sont des types d'entités personnalisé. les listing sont créés directement via des ListBuilder et non pas des vues. Les tickets se mettent à jours via des QueueWorkers.
Il y a pas mal de champs calculés pour, par exemple avoir au niveau d'un client le CA facturé, le CA en cours... J'ai factorisé mon code au maximum.
Le core de cet applicatif consiste en un seul module « custom » qui nécessite donc 3 autres modules :
gitlab_api : pour s'interconnecter avec plusieurs serveurs gitlab, module tiers disponible sur drupal.org auquel j'ai contribué.
github_api : pour s'interconnecter avec github, module développé par mes soins un peu « quick'n'dirty »
pivotal_api : pour s'interconnecter avec pivotal tracker, développé aussi par mes soins, mais encore trop sale pour être opensourcé pour l'instant.
Dans les faits, le module core est suffisamment générique pour être opensourcé, si vous êtes intéressé, n'hésitez-pas à vous signaler, ça me donnera la motivation à accélérer le processus ! Je pense que d'autres freelances pourraient être intéressés par la solution.
C'est là qu'on voit toute la puissance de drupal (surtout à partir de la version 8) pour développer très rapidement des applicatifs métiers puissants, intégrés et interconnectés. Le tout en codant en se faisant plaisir !
Il est possible dans drupal 8 et 9 de surcharger l'auto-completion d'un champ « référence à un type d'entité », à la fois la requête générée (pour par exemple faire la recherche sur d'autres champs que le titre, mais aussi le label des éléments retournés.
Attention, la seconde étape diffère entre les versions 8 et 9 de drupal. Logiquement la version drupal 9 fonctionne sur les dernières version de drupal 8, je n'ai pas vérifié. Mais l'inverse ne fonctionne en tout cas pas !
Modification du formulaire (drupal 8 et drupal 9)
Pour cela il faut commencer par altérer le formulaire pour modifier un attribut de notre champ autocomplete :
// mon_module.module (ou bien un fichier de définition de formulaire directement // ici, mon champ « entity_reference » est issue// dashboard:issue est une clé qui sera définie à l'étape 2 function mon_module_form_alter(&$form, FormStateInterface $form_state) { if ($form['id'] === '...') { $form['issue']['widget'][0]['target_id']['#selection_handler'] = 'dashboard:issue'; }}
Définition du nouveau filtre de sélection (drupal 9)
mon_module/src/Plugin/EntityReferenceSelection/IssueSelection.php getConfiguration()['target_type']; // ici c'est une EntityQuery classique $query = $this->buildEntityQuery($match, $match_operator); $or = $query->orConditionGroup(); // Je fais une condition sur le titre de mon contenu mais aussi sur le champ « external_id » $or->condition('title', $match, $match_operator); $or->condition('external_id', $match, $match_operator); $query->condition($or); if ($limit > 0) { $query->range(0, $limit); } $result = $query->execute(); if (empty($result)) { return []; } $options = []; /** @var \Drupal\dashboard\Entity\Issue[] $entities */ $entities = $this->entityTypeManager->getStorage($target_type)->loadMultiple($result); foreach ($entities as $entity_id => $entity) { $project = $entity->getProject(); $bundle = $entity->bundle(); // Ici, pour chaque résultat, définition du label de l'élément qui sera affiché dans la liste déroulante $options[$bundle][$entity_id] = Html::escape($project->label() . ' #' . $entity->getExternalId(). ' - ' . $entity->label() ); } return $options; } }
Définition du nouveau filtre de sélection (drupal 8)
mon_module/src/Plugin/EntityReferenceSelection/IssueSelection.php getConfiguration()['target_type']; // ici c'est une EntityQuery classique $query = $this->entityManager->getStorage($target_type)->getQuery(); $or = $query->orConditionGroup(); // Je fais une condition sur le titre de mon contenu mais aussi sur le champ « external_id » $or->condition('title', $match, $match_operator); $or->condition('external_id', $match, $match_operator); $query->condition($or); if ($limit > 0) { $query->range(0, $limit); } $result = $query->execute(); if (empty($result)) { return []; } $options = []; /** @var \Drupal\dashboard\Entity\Issue[] $entities */ $entities = $this->entityManager->getStorage($target_type)->loadMultiple($result); foreach ($entities as $entity_id => $entity) { $project = $entity->getProject(); $bundle = $entity->bundle(); // Ici, pour chaque résultat, définition du label de l'élément qui sera affiché dans la liste déroulante $options[$bundle][$entity_id] = Html::escape($project->label() . ' #' . $entity->getExternalId(). ' - ' . $entity->label() ); } return $options; } }
Voici comment ajouter un basefield slug à un type d'entité client. La définition de cette propriété se trouvant dans la méthode baseFieldDefinitions de notre type d'entité :
function dashboard_update_9005() { $entity_type_id = 'client'; // nom machine de notre type d'entité $fields = ['slug']; // champ(s) à créer $definition_update_manager = \Drupal::entityDefinitionUpdateManager(); \Drupal::entityTypeManager()->clearCachedDefinitions(); $entity_type = $definition_update_manager->getEntityType($entity_type_id); foreach ($fields as $field) { $fieldDefinition = $entity_type->getClass()::baseFieldDefinitions($entity_type)[$field]; $definition_update_manager->installFieldStorageDefinition($field, $entity_type_id, $entity_type_id, $fieldDefinition); }}
En adaptant la seconde ligne de la fonction, il est possible d'ajouter autant de propriétés que l'on souhaite à notre type d'entité.
À la différence d'une propriété « lien » (voir : Drupal 8 & Drupal 9 - Entité - Champ de base « link ») un champ de type « uri » ne prendra qu'une colonne dans votre table de base de données : pas de titre, pas d'options (target...) Mais du coup plus économique si on se fiche de ces attributs.
$fields['url'] = BaseFieldDefinition::create('uri') ->setLabel(t('Issue URL')) ->setRequired(TRUE) ->setDisplayConfigurable('view', TRUE) ->setDisplayConfigurable('form', TRUE);
Je me suis rendu compte que je n'avais jamais documenté comment ajouter une propriété « référence à une entité » :
Pour un type d'entité « client » :
$fields['client'] = BaseFieldDefinition::create('entity_reference') ->setLabel(t('Client')) ->setSetting('target_type', 'client') ->setDisplayConfigurable('form', TRUE) ->setDisplayConfigurable('view', TRUE);
Pour un nœud :
$fields['contenu'] = BaseFieldDefinition::create('entity_reference') ->setLabel(t('Contenu')) ->setSetting('target_type', 'node') ->setDisplayConfigurable('form', TRUE) ->setDisplayConfigurable('view', TRUE);
Il est aussi possible de restreindre le/les bundle(s) :
$fields['contenu'] = BaseFieldDefinition::create('entity_reference') ->setLabel(t('Contenu')) ->setSetting('target_type', 'node') - ->setSetting('handler_settings', [ 'target_bundles' => [ 'article' => 'article', 'page' => 'page', ] ]) ->setDisplayConfigurable('form', TRUE) ->setDisplayConfigurable('view', TRUE);
Phpcs (ou PHP Code Sniffer) est un inspecteur de code permettant de vérifier la validité du code écrits en fonction de standards.
Pour l'ajouter à notre projet drupal géré via composer :
composer require squizlabs/php_codesniffer # Ou si vous utilisez docker-compose docker-compose exec php composer require squizlabs/php_codesniffer
Drupal a son propre fichier de règles (un fichier xml) utilisable par phpcs, il est compris dans une dépendance drupal spécifique : coder
Pour l'installer :
composer require drupal/coder:^8.3.1 # Ou avec docker-compose docker-compose exec php composer require drupal/coder:^8.3.1
Une fois coder installé, il faut informer phpcs de l'emplacement du fichier de règles (contenu dans coder) :
# /var/www/html/ est le docroot de mon projet dans mon container dockerdocker-compose exec php vendor/bin/phpcs --config-set installed_paths /var/www/html/vendor/drupal/coder/coder_sniffer
On vérifie que « Drupal » est maintenant bien présent dans les standards de code installés :
docker-compose exec php vendor/bin/phpcs -i # Ce qui devrait vous retourner : # The installed coding standards are PEAR, PSR2, Zend, MySource, Squiz, PSR12, PSR1, DrupalPractice and Drupal
Et voila, nous pouvons maintenant lancer des inspections :
# Note : ici je me contente d'inspecter le module "mespronos" situé dans le dossier : ./web/modules/mespronosdocker-compose exec php ./vendor/bin/phpcs --colors --standard=Drupal --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md,yml ./web/modules/mespronos # on pourrait imaginer inspecter tous nos modules custom avec la commande suivante : docker-compose exec php ./vendor/bin/phpcs --colors --standard=Drupal --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md,yml ./web/modules/custom
Si vous utilisez un makefile (plus d'informations) vous pouvez vous créer un « raccourci » :
## phpcs : Launch phpcs inspections for ./web/modules/customphpcs: @docker-compose exec php ./vendor/bin/phpcs --colors --standard=Drupal --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md,yml ./web/modules/custom
Ainsi pour lancer vos inspections, vous n'aurez qu'à lancer la commande « make phpcs »
Dans le contexte d'un webform, je voulais pouvoir envoyer une notification à un email en particulier en fonction du sujet du message de contact.
Au niveau de mon webform, mon champ sujet est un select dont les options sont issues d'un vocabulaire de taxonomie :
Image
Dans le vocabulaire en question, j'ai ajouté un champ de type email field_destinataire_message :
Image
Ainsi pour chaque sujet de contact, l'administrateur pourra saisir un destinataire différent.
Maintenant reste la partie la plus importante, le gestionnaire de notification du webform.
Création d'un plugin EmailWebformHandler :
web/modules/custom/mon_module/src/Plugin/WebformHandler/ContactWebformHandler.php
get('mail'); // Je recupère la valeur du champ « sujet » (un entier : l'id du terme de taxonomy) $subjectTid = $webform_submission->getRawData()['subject']; if (($subject = Term::load($subjectTid)) && $destinataire = $subject->get('field_destinataire_message')->value) { $recipient = $destinataire; } // je définis le destinataire $message['to_mail'] = $recipient; parent::sendMessage($webform_submission, $message); } }
Pour terminer, il faut activer cette notification cela se passe au niveau de notre webform dans l'administration : onglet « paramètres », sous-onglet « Emails / Handlers » : Ajouter un gestionnaire :
Image
Sélectionner le handler que l'on vient de créer puis cliquez sur le lien « Ajouter un gestionnaire ».
Et il ne restera plus qu'à configurer la notification comme classiquement, sauf qu'évidement cette fois le champ destinataire n'est pas disponible !
Une nouvelle vidéo fraîchement mise en ligne pour le weekend. Au programme du jour : Git et comment l'utiliser sur un projet drupal.
Mini introduction sur git et ses fondamentaux
Passage en revue des dossiers et fichiers composants l'architecture d'un projet Drupal
Exemple d'organisation pour travailler en équipe avec les branches Git et les environnements.
Attention, je le répète, dans la troisième parti je présente une organisation de fonctionnement qui me convient à moi et qui répond aux problématiques que j'ai rencontré. Mais ça n'est pas la seule et unique manière de faire et encore moins la meilleure.
Désolé pour le petit faux-contact au niveau du micro qui entraîne parfois un peu de bruit, mon ingé son est viré, le problème est résolu.
Le dépôt utilisé dans la vidéo est librement accessible : https://gitlab.kgaut.net/kgaut/formation-drupal-git
Retrouvez la vidéo sur youtube directement (pensez à passer en plein écran) ou bien juste ci-dessous.
N'oubliez-pas que vous pouvez voter ou me proposer des sujets à l'adresse suivante : https://kgaut.net/suggestion-sujet-video-formation.
Commandes GIT vues dans la vidéo
Initialiser un dépôt
git init
Versionner un fichier et le commiter
git add readme.mdgit commit -m "Ajout fichier readme"
Ajouter une remote
git remote add origin URL_DEPOT_GIT
Créer un tag git
git tag NOMTAG # exemple : git tag 1.0.0 # ou git tag 20201030-01
Créer une nouvelle branche git
git checkout -b feature-blog
Voici comment installer un type d'entité personnalisé via un hook_update.
À noter, les types d'entités d'un module sont automatiquement installés lors de l'installation du module. Ce snippet n'est utile que pour un type d'entité créé à postériori.
/** * Create entity Type « inscription_newsletter » */function MON_MODULE_update_8008() { \Drupal::entityTypeManager()->clearCachedDefinitions(); \Drupal::entityDefinitionUpdateManager()->installEntityType(\Drupal::entityTypeManager()->getDefinition('inscription_newsletter'));}
Voici comment définir une propriété (basefield) « e-mail » sur un type d'entité.
$fields['email'] = BaseFieldDefinition::create('email') ->setLabel(t('Email')) ->setDefaultValue('') ->setDisplayConfigurable('form', TRUE) ->setDisplayConfigurable('view', TRUE);
Il est possible dans un contrôleur ou un bloc de récupérer un formulaire et de l'afficher comme n'importe quelle autre variable.
À l'époque de drupal 7 on utilisait la fonction drupal_get_form(), à partir de drupal 8, il faut utiliser le service form_builder et sa méthode getForm() en lui passant la classe du formulaire :
#dans la méthode build de mon bloc ou mon controleur :$build['#mon_formulaire'] = \Drupal::service('form_builder')->getForm(\Drupal\mon_module\Form\LoginForm::class);$build['#theme'] = 'mon_template';
Note : il est toujours préférable d'injecter le service en utilisant l'injection de dépendance.
Ensuite il sera possible d'afficher le formulaire dans le template via la variable mon_formulaire :
{# Dans le template twig : mon-template.html.twig #}{{ mon_formulaire }}
Évidement, il ne faut pas oublier d'avoir déclaré la variable mon_formulaire dans la déclaration du template :
//mon_module.module function mon_module_theme() { $themes = []; $themes['mon_template'] = [ 'render element' => 'elements', 'variables' => [ 'mon_formulaire' => [], ], 'template' => 'mon-template', ]; return $themes;}