Planète

Par Kgaut
Adhérent
Kevin Gautreau

Drupal 8 - ajouter du css ou du javascript à un module

Voici comment attacher une librairie javascript ou un fichier css à un module custom dans drupal 8.

Dans les extraits de code ci-dessous, le nom machine du module sera « shoutbox ».

Déclaration de la librairie

  1. #shoutbox.libraries.yml
  2.  
  3. # nom de la librairie
  4. shoutbox :
  5.   js:
  6. # chemin vers le fichier relatif au module
  7.   js/shoutbox.js: {}
  8.   css:
  9.   theme :
  10. # chemin vers le fichier relatif au module
  11.   css/administration.css : {}

Voici comment attacher cette librairies dans un bloc, un preprocess de template ou un controller

  1. // suivant l'endroit ooù l'on attache la librairie, cela peut être $build, $variables...
  2. // la partie avant le slash définie le nom du module qui défini la librairie
  3. // la partie après le slash est le nom de la librairie choisie dans le fichier shoutbox.libraries.yml
  4.  
  5. $variables['#attached']['library'][] = 'shoutbox/shoutbox';

 

Par Kgaut
Adhérent
Kevin Gautreau

Drupal 8 - Surcharger la classe de contrôle d'accès d'un type d'entité

Sous drupal 8, les types d'entités, comme les noeuds, viennent avec leur classe pour gérer le contrôle d'accès (création / modification / visualisation / suppression).

Il est possible de surcharger ces classes pour personnaliser plus finement ce contrôle.

Nous allons ici surcharger le contrôle d'accès pour un type d'entité « shoutbox », mais c'est le même principe pour les nodes.

  1. # mon_module.module
  2. function mon_module_entity_type_alter(array &$entity_types) {
  3. $entity_types['shoutbox']->setHandlerClass('access', \Drupal\mon_module\Entity\AccessControlHandler\CustomShoutboxAccessControlHandler::class);
  4. // Note : si on avait voulu surcharger le controle d'accès aux noeuds :
  5. // $entity_types['node']->setHandlerClass('access', \Drupal\mon_module\Entity\AccessControlHandler\CustomNodeAccessControlHandler::class);
  6. }

La classe en elle même, qui étant la classe de contrôle d'accès de base (définie dans l'annotation de notre type d'entité)

  1. # mon_module/src/Entity/AccessControlHandler/CustomShoutboxAccessControlHandler.php
  2.  
  3. namespace Drupal\mon_module\Entity\AccessControlHandler;
  4.  
  5. use Drupal\Core\Access\AccessResult;
  6. use Drupal\Core\Entity\EntityInterface;
  7. use Drupal\Core\Session\AccountInterface;
  8. use Drupal\shoutbox\Entity\AccessControlHandler\ShoutboxAccessControlHandler;
  9. use Drupal\shoutbox\Entity\Shoutbox;
  10. use Drupal\user\Entity\User;
  11.  
  12. class CustomShoutboxAccessControlHandler extends ShoutboxAccessControlHandler {
  13.  
  14. protected function checkAccess(EntityInterface $entity, $operation, AccountInterface $account) {
  15. /** @var Shoutbox $entity */
  16. if($operation === 'view' && $this->testPerso()) {
  17. if (!$entity->isPublished()) {
  18. return AccessResult::allowedIfHasPermission($account, 'administer shoutbox');
  19. }
  20. if ($this->autreTest()) {
  21. return AccessResult::allowed();
  22. }
  23. return AccessResult::forbidden('Shoutbox privée');
  24. }
  25. return parent::checkAccess($entity, $operation, $account);
  26. }
  27.  
  28. }

Ici je ne fais un contrôle d'accès que sur l'opération « view » pour la visualisation, je délègue tout le reste à la classe mère.

Par Kgaut
Adhérent
Kevin Gautreau

Intégrer Slack à son site drupal 8

Nous allons voir comment envoyer des messages sur un slack depuis un site.

Évidement, vous devez pour cela être administrateur du slack ou bien avoir des jetons d'intégration.

Installation du module d'API

Commençons par télécharger et activer le module slack qui fera le pont entre notre site et l'API de slack

  1. composer require drupal/slack
  2. drush en slack

Configuration

Rendez-vous sur la page de configuration du module : /admin/config/services/slack/config

Il nous faudra ici une « Webhook URL », qui s'obtient sur votre slack, dans la section Apps : https://MONSLACK.slack.com/apps, dans le recherche tapez « webhook » et dans l'auto-complétion selectionnez « Incoming WebHooks » :

Slack Incoming WebHooks

Sur l'écran suivant cliquez sur le bouton « Add Configuration »

Slack - add configuration

Sélectionnez ensuite le canal où les messages devront être postés :

Slack - Selection chan

Récupérez ensuite l'adresse « webhook URL » en renseignez-la sur votre site, sur l'écran de configuration de Slack, vous pouvez renseigner le nom et l'avatar qui apparaîtra pour chaque message :

slack - config

On teste si tout fonctionne bien via l'onglet « send test message »

Slack Test

On vérifie dans le slack :

slack test

\o/

Voila le module est configuré, on peut maintenant utiliser rules pour déclencher des actions. Mais on peut aussi le faire depuis le code.

Un exemple tout simple (qui aurait pu être fait via rules) : envoyer un message slack à chaque commentaire sur le site, j'ai utilisé pour cela le hook_comment_insert avec le service slack.slack_service :

  1. function kgaut_comment_insert(\Drupal\comment\Entity\Comment $comment) {
  2. /** @var \Drupal\slack\Slack $slack */
  3. $slack = \Drupal::service('slack.slack_service');
  4.  
  5. $node = $comment->getCommentedEntity();
  6. $author = $comment->getAuthorName();
  7. $email = $comment->getAuthorEmail();
  8. $body = strip_tags($comment->get('comment_body')->value);
  9. $description = t('*@username* (@email) vient de poster un commentaire sur *@post_title* : _@message_. @comment_url', [
  10. '@username' => $author,
  11. '@message' => $body,
  12. '@email' => $email,
  13. '@post_title' => $node->label(),
  14. '@comment_url' => $comment->toUrl('canonical', ['absolute' => TRUE])->toString(),
  15. ]);
  16. $slack->sendMessage($description);
  17. }

Et hop !

samarsh !

 

Par Kgaut
Adhérent
Kevin Gautreau

Drupal 8 - Utiliser les redirections de Redirect sur une page dépubliée

Dans le cas d'une page dé-publiée, si en tant qu'anonyme on tombe sur une erreur 403. On peut vouloir rediriger cette page temporairement vers une autre via le module redirect, mais nativement ça n'est pas pris en compte.

Voici un petit EventSubscriber qui répond sur les erreurs 403, qui teste si une redirection existe pour le nœud courant, et dans ce cas redirige l'utilisateur.

Note : Un administrateur ayant la permission pour voir le contenu dé-publié ne sera pas redirigé, car aucune erreur 403 ne sera lancée et donc l'event subscriber ne sera pas appelé.

Note 2 : C'est un bout de code qui semble fonctionnel, fonctionne avec le multilingue mais qui est certainement perfectible. N'hésitez-pas à me faire vos remarques.

1 - Déclaration de l'event subscriber :

  1. #mon_module.services.yml
  2.  
  3.   mon_module.redirector:
  4.   class: Drupal\mon_module\EventSubscriber\Redirector
  5.   tags:
  6.   - { name: event_subscriber }

2 - Définition de l'event subscriber 

  1. # web/modules/custom/mon_module/src/EventSubscriber/Redirector.php
  2.  
  3. namespace Drupal\mon_module\EventSubscriber;
  4.  
  5. use Drupal\Core\EventSubscriber\HttpExceptionSubscriberBase;
  6. use Drupal\redirect\RedirectRepository;
  7. use Drupal\node\Entity\Node;
  8. use Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent;
  9. use Symfony\Component\HttpFoundation\RedirectResponse;
  10.  
  11. class Redirector extends HttpExceptionSubscriberBase {
  12.  
  13. /**
  14.   * {@inheritdoc}
  15.   */
  16. protected function getHandledFormats() {
  17. return ['html'];
  18. }
  19.  
  20. public function on403(GetResponseForExceptionEvent $event) {
  21. if ($event->getRequest()->attributes->get('node') !== NULL) {
  22. $nid = \Drupal::routeMatch()->getRawParameter('node');
  23. $langcode = \Drupal::languageManager()->getCurrentLanguage()->getId();
  24. /** @var RedirectRepository $redirectRepository */
  25. $redirectRepository = \Drupal::service('redirect.repository');
  26. $node = Node::load($nid);
  27. if ($node !== NULL && $node->hasTranslation($langcode) && $translation = $node->getTranslation($langcode)) {
  28. if (!$translation->isPublished()) {
  29. $alias = \Drupal::service('path.alias_manager')->getAliasByPath('/node/' . $nid);
  30. $redirection = $redirectRepository->findMatchingRedirect($alias, [], $langcode);
  31. if($redirection) {
  32. $event->setResponse(new RedirectResponse($redirection->getRedirectUrl()->toString(), $redirection->getStatusCode()));
  33. }
  34. }
  35. }
  36. }
  37. }
  38.  
  39. }

 

Par Kgaut
Adhérent
Kevin Gautreau

Drupal 8 - Surcharger la classe de formulaire d'un terme de taxonomie

Hier, nous avons vu comment surcharger le formulaire de création / modification d'un nœud, voici aujourd'hui comment faire la même chose mais pour un terme de taxonomie.

Cela se passe encore en deux étapes.

1 - Altération du type d'entité

  1. # mon_module.module
  2. function mon_module_entity_type_alter(array &$entity_types) {
  3. $entity_types['taxonomy_term']->setFormClass('default', Drupal\mon_module\Entity\Form\CustomTermForm::class);
  4. }

2 - Classe du formulaire

  1. # web/modules/mon_module/src/Entity/Form/CustomTermForm.php
  2.  
  3. namespace Drupal\mon_module\Entity\Form;
  4.  
  5. use Drupal\Core\Form\FormStateInterface;
  6. use Drupal\taxonomy\TermForm;
  7.  
  8. class CustomTermForm extends TermForm {
  9. public function form(array $form, FormStateInterface $form_state) {
  10. $form = parent::form($form, $form_state);
  11. /** @var \Drupal\taxonomy\Entity\Term $term */
  12. $term = $this->entity;
  13. if($term->getVocabularyId() === 'mon_vocabulaire') {
  14. // À vous de jouer
  15. }
  16. return $form;
  17. }
  18.  
  19. }

 

Par Kgaut
Adhérent
Kevin Gautreau

Drupal 8 - Surcharger la classe de formulaire d'un nœud

Pour modifier le formulaire de création d'un nœud sous drupal 8, on peut utiliser le bon vieux HOOK_form_alter(), mais on peut aussi faire quelque chose de plus « propre » en altérant le type d'entité pour redéfinir son formulaire.

Cela se passe en deux étapes.

1 - Altération du type d'entité

  1. # mon_module.module
  2. function mon_module_entity_type_alter(array &$entity_types) {
  3. $entity_types['node']->setFormClass('default', \Drupal\mon_module\Entity\Form\NodeCustomForm::class);
  4. $entity_types['node']->setFormClass('edit', \Drupal\mon_module\Entity\Form\NodeCustomForm::class);
  5. }

2 - Classe du formulaire

  1. # web/modules/mon_module/src/Entity/Form/NodeCustomForm.php
  2.  
  3. namespace Drupal\mon_module\Entity\Form;
  4.  
  5. use Drupal\Core\Form\FormStateInterface;
  6. use Drupal\node\NodeForm;
  7.  
  8. class NodeCustomForm extends NodeForm {
  9.  
  10. public function form(array $form, FormStateInterface $form_state) {
  11. $form = parent::form($form, $form_state);
  12. // Faite votre magie ici
  13. /** @var \Drupal\node\Entity\Node $node */
  14. $node = $this->entity;
  15. return $form;
  16. }
  17.  
  18. }

Cette classe étant la classe normale, nous avons donc juste à appliquer nos modifications à l'intérieur.

Le problème de cette solution : on ne peut pas avoir deux modules qui surchargent la classe, à moins d'étendre la première dans la seconde.

Par GoZ
Adhérent
Fabien CLEMENT

Ajouter un formulaire à une entité existante

Ajouter un formulaire à une entité existante

Problématique

Dans notre Drupal, nous avons une entité composée de plusieurs champs mais ne souhaitons pas qu'ils soient tous renseignés via le même formulaire ? 2 solutions s'offrent à nous :

GoZ
lun 24/06/2019 - 13:44

Par lequipe.tech
L'Équipe.tech

Ajouter un formulaire à une entité existante

Problématique

Dans notre Drupal, nous avons une entité composée de plusieurs champs mais ne souhaitons pas qu'ils soient tous renseignés via le même formulaire ? 2 solutions s'offrent à nous :

La première est de créer notre controller, créer notre formulaire et gérer le chargement et l'enregistrement des données.
La seconde est d'altérer la définition de l'entité pour rajouter notre formulaire.

Nous conviendrons rapidement que la première méthode n'est pas la plus appropriée eu égard aux bonnes pratiques Drupal. De même, l'effort à fournir par le second cas sera moindre par rapport au premier. Pourquoi tout reconstruire alors que l'on peut utiliser les mécanismes existants ?

Voyons comment réaliser cela via un cas pratique : nous avons une entité 'user' pour laquelle nous souhaitons avoir un formulaire d'édition générale (e-mail / mot de passe) et un formulaire pour qu'il renseigne ses informations personnelles (nom / prénom / adresse).

Création du nouvel affichage de formulaire

Dans un premier temps, allons créer un nouvel affichage de formulaire.

Aller sur la page d'administration de l'affichage de notre type d'utilisateur /admin/config/people/accounts/form-display.
Ajouter un affichage de formulaire 'personal'.
N'y placer que les champs (que nous aurons préalablement créés) nom, prénom, adresse.
Dans l'affichage du formulaire par défaut, retirer ces 3 champs de l'affichage.

Nous avons maintenant un nouvel affichage de formulaire, sauf que celui-ci n'est utilisé nulle part.

Nous allons donc créer une nouvelle définition de route pour y accéder.

Accéder au nouvel affichage de formulaire

Dans le fichier de routing de notre module custom (MONMODULE) : MONMODULE.routing.yml, ajouter une nouvelle route :

MONMODULE.user.personal_form:
path: '/user/{user}/personal_form'
defaults:
_entity_form: user.personal
_title: Personal infromations
requirements:
_entity_access: user.update
user: \d+
options:
_admin_route: FALSE

 

Voyons en détail à quoi servent ces lignes :

# Nom de la route.
MONMODULE.user.personal_form:
# Chemin vers la route. On reprend le chemin d'un user, {user} permet de définir que l'on souhaite utiliser un jeton correspondant à notre entité user.
path: '/user/{user}/personal'
defaults:
# Cette route pointe vers un formulaire d'entité de l'entité user avec l'affichage de formulaire que nous venons de créer : personal.
_entity_form: user.personal
_title: Personal infromations
requirements:
# Par mesure de sécurité, l'utilisateur doit avoir les droits d'accès de l'entité user.update (identique à l'édition normale d'une entité user).
_entity_access: user.update
# Définition des règles de validation de notre token user.
user: \d+
options:
# Cette route n'est pas une route admin (FALSE par défaut).
_admin_route: FALSE

 

On vide les caches, et nous pouvons maintenant accéder à notre formulaire qui ne contiendra que les champs voulus.

Modifier le formulaire

Si l'on souhaite modifier le formulaire existant pour par exemple y ajouter le rendu de notre utilisateur avant les champs d'édition et ajouter un message informatif, nous allons modifier la définition de l'entité user pour y ajouter une nouvelle classe de gestion de notre formulaire.

Dans le fichier MONMODULE.module, créer la méthode MONMODULE_entity_type_alter() ou y ajouter la ligne suivante :

/**
* Implements hook_entity_type_alter().
*/
function MONMODULE_entity_type_alter(array &$entity_types) {
$entity_types['user']->setFormClass('personal', 'Drupal\MONMODULE\Form\UserPersonalForm');
}

 

et créons dans src/Form/UserPersonalForm notre nouvelle classe qui hérite de AccountForm.

namespace Drupal\MONMODULE\Form;

use Drupal\Core\Form\FormStateInterface;
use Drupal\user\AccountForm;

/**
* Class UserPersonalForm.
*
* @package Drupal\MONMODULE\Form
*/
class UserPersonalForm extends AccountForm {

/**
* {@inheritdoc}
*/
public function form(array $form, FormStateInterface $form_state) {
// Chargement de l'entité en cours pour pouvoir générer son affichage.
$user = $this->getEntity();

$user_view = $this->entityTypeManager->getViewBuilder('user')->view($user, 'default');
$user_view['#attributes'] = [
'class' => ['user-default-infos'],
];
$form['user_view'] = $user_view;

$form = parent::form($form, $form_state);

// Nous pouvons ici modifier le formulaire comme bon nous semble.

return $form;
}

/**
* {@inheritdoc}
*/
public function validateForm(array &$form, FormStateInterface $form_state) {
parent::validateForm($form, $form_state);
// Nous pouvons faire ici nos propres validations.
}

/**
* {@inheritdoc}
*/
public function submitForm(array &$form, FormStateInterface $form_state) {
parent::submitForm($form, $form_state);
// Nous pouvons faire ici des actions à la suite de la soumission.
}

/**
* {@inheritdoc}
*/
protected function actions(array $form, FormStateInterface $form_state) {
$element = parent::actions($form, $form_state);

// Nous pouvons ici modifier les éléments d'action (boutons).

return $element;
}

}

 

Ajouter un template de lien

Il y a une définition d'entité très pratique et simple à utiliser pour gérer des liens d'entités, il s'agit des templates de lien. On les retrouve par exemple dans l'annotation de notre entité user :

* links = {
* "canonical" = "/user/{user}",
* "edit-form" = "/user/{user}/edit",
* "cancel-form" = "/user/{user}/cancel",
* "collection" = "/admin/people",
* },

 

L'avantage de ces templates de liens est de pouvoir générer un lien à partir de l'entité plutôt que de devoir instancier le générateur de route, et de devoir lui passer tous les paramètres.

// Via le générateur de route.
$url = \Drupal::service('url_generator')->generateFromRoute('entity.user.edit_form', ['user' => $user]);
// Via le template de lien.
/** @var \Drupal\user\Entity\User $user */
$url = $user->url('edit-form');

 

Vu que nous avons ajouté notre formulaire personal, nous pouvons également définir un template de lien pour celui-ci.

Dans notre fichier MONMODULE.module, ajouter la ligne suivante au hook MONMODULE_entity_type_alter().

/**
* Implements hook_entity_type_build().
*/
function MONMODULE_entity_type_alter(array &$entity_types) {
$entity_types['user']->setFormClass('personal', 'Drupal\MONMODULE\Form\UserPersonalForm');
$entity_types['user']->setLinkTemplate('personal-form', '/user/{user}/personal');
}

 

Ce qui nous permettra également de générer nos liens de la sorte :

/** @var \Drupal\user\Entity\User $user */
$url = $user->url('personal-form');

Par lequipe.tech
L'Équipe.tech

Ajouter un formulaire à une entité existante

Problématique

Dans notre Drupal, nous avons une entité composée de plusieurs champs mais ne souhaitons pas qu'ils soient tous renseignés via le même formulaire ? 2 solutions s'offrent à nous :

La première est de créer notre controller, créer notre formulaire et gérer le chargement et l'enregistrement des données.
La seconde est d'altérer la définition de l'entité pour rajouter notre formulaire.

Nous conviendrons rapidement que la première méthode n'est pas la plus appropriée eu égard aux bonnes pratiques Drupal. De même, l'effort à fournir par le second cas sera moindre par rapport au premier. Pourquoi tout reconstruire alors que l'on peut utiliser les mécanismes existants ?

Voyons comment réaliser cela via un cas pratique : nous avons une entité 'user' pour laquelle nous souhaitons avoir un formulaire d'édition générale (e-mail / mot de passe) et un formulaire pour qu'il renseigne ses informations personnelles (nom / prénom / adresse).

Création du nouvel affichage de formulaire

Dans un premier temps, allons créer un nouvel affichage de formulaire.

Aller sur la page d'administration de l'affichage de notre type d'utilisateur /admin/config/people/accounts/form-display.
Ajouter un affichage de formulaire 'personal'.
N'y placer que les champs (que nous aurons préalablement créés) nom, prénom, adresse.
Dans l'affichage du formulaire par défaut, retirer ces 3 champs de l'affichage.

Nous avons maintenant un nouvel affichage de formulaire, sauf que celui-ci n'est utilisé nulle part.

Nous allons donc créer une nouvelle définition de route pour y accéder.

Accéder au nouvel affichage de formulaire

Dans le fichier de routing de notre module custom (MONMODULE) : MONMODULE.routing.yml, ajouter une nouvelle route :

MONMODULE.user.personal_form:
path: '/user/{user}/personal_form'
defaults:
_entity_form: user.personal
_title: Personal infromations
requirements:
_entity_access: user.update
user: \d+
options:
_admin_route: FALSE

 

Voyons en détail à quoi servent ces lignes :

# Nom de la route.
MONMODULE.user.personal_form:
# Chemin vers la route. On reprend le chemin d'un user, {user} permet de définir que l'on souhaite utiliser un jeton correspondant à notre entité user.
path: '/user/{user}/personal'
defaults:
# Cette route pointe vers un formulaire d'entité de l'entité user avec l'affichage de formulaire que nous venons de créer : personal.
_entity_form: user.personal
_title: Personal infromations
requirements:
# Par mesure de sécurité, l'utilisateur doit avoir les droits d'accès de l'entité user.update (identique à l'édition normale d'une entité user).
_entity_access: user.update
# Définition des règles de validation de notre token user.
user: \d+
options:
# Cette route n'est pas une route admin (FALSE par défaut).
_admin_route: FALSE

 

On vide les caches, et nous pouvons maintenant accéder à notre formulaire qui ne contiendra que les champs voulus.

Modifier le formulaire

Si l'on souhaite modifier le formulaire existant pour par exemple y ajouter le rendu de notre utilisateur avant les champs d'édition et ajouter un message informatif, nous allons modifier la définition de l'entité user pour y ajouter une nouvelle classe de gestion de notre formulaire.

Dans le fichier MONMODULE.module, créer la méthode MONMODULE_entity_type_alter() ou y ajouter la ligne suivante :

/**
* Implements hook_entity_type_alter().
*/
function MONMODULE_entity_type_alter(array &$entity_types) {
$entity_types['user']->setFormClass('personal', 'Drupal\MONMODULE\Form\UserPersonalForm');
}

 

et créons dans src/Form/UserPersonalForm notre nouvelle classe qui hérite de AccountForm.

namespace Drupal\MONMODULE\Form;

use Drupal\Core\Form\FormStateInterface;
use Drupal\user\AccountForm;

/**
* Class UserPersonalForm.
*
* @package Drupal\MONMODULE\Form
*/
class UserPersonalForm extends AccountForm {

/**
* {@inheritdoc}
*/
public function form(array $form, FormStateInterface $form_state) {
// Chargement de l'entité en cours pour pouvoir générer son affichage.
$user = $this->getEntity();

$user_view = $this->entityTypeManager->getViewBuilder('user')->view($user, 'default');
$user_view['#attributes'] = [
'class' => ['user-default-infos'],
];
$form['user_view'] = $user_view;

$form = parent::form($form, $form_state);

// Nous pouvons ici modifier le formulaire comme bon nous semble.

return $form;
}

/**
* {@inheritdoc}
*/
public function validateForm(array &$form, FormStateInterface $form_state) {
parent::validateForm($form, $form_state);
// Nous pouvons faire ici nos propres validations.
}

/**
* {@inheritdoc}
*/
public function submitForm(array &$form, FormStateInterface $form_state) {
parent::submitForm($form, $form_state);
// Nous pouvons faire ici des actions à la suite de la soumission.
}

/**
* {@inheritdoc}
*/
protected function actions(array $form, FormStateInterface $form_state) {
$element = parent::actions($form, $form_state);

// Nous pouvons ici modifier les éléments d'action (boutons).

return $element;
}

}

 

Ajouter un template de lien

Il y a une définition d'entité très pratique et simple à utiliser pour gérer des liens d'entités, il s'agit des templates de lien. On les retrouve par exemple dans l'annotation de notre entité user :

* links = {
* "canonical" = "/user/{user}",
* "edit-form" = "/user/{user}/edit",
* "cancel-form" = "/user/{user}/cancel",
* "collection" = "/admin/people",
* },

 

L'avantage de ces templates de liens est de pouvoir générer un lien à partir de l'entité plutôt que de devoir instancier le générateur de route, et de devoir lui passer tous les paramètres.

// Via le générateur de route.
$url = \Drupal::service('url_generator')->generateFromRoute('entity.user.edit_form', ['user' => $user]);
// Via le template de lien.
/** @var \Drupal\user\Entity\User $user */
$url = $user->url('edit-form');

 

Vu que nous avons ajouté notre formulaire personal, nous pouvons également définir un template de lien pour celui-ci.

Dans notre fichier MONMODULE.module, ajouter la ligne suivante au hook MONMODULE_entity_type_alter().

/**
* Implements hook_entity_type_build().
*/
function MONMODULE_entity_type_alter(array &$entity_types) {
$entity_types['user']->setFormClass('personal', 'Drupal\MONMODULE\Form\UserPersonalForm');
$entity_types['user']->setLinkTemplate('personal-form', '/user/{user}/personal');
}

 

Ce qui nous permettra également de générer nos liens de la sorte :

/** @var \Drupal\user\Entity\User $user */
$url = $user->url('personal-form');

Par Kgaut
Adhérent
Kevin Gautreau

Drupal 8 - rendre un formulaire dans un template

La form api de drupal est très puissante, mais pour jouer avec le markup html avec les #prefix et #suffix peut s'avérer rapidement complexe en plus d'être un peu sale au niveau du code.

Dans drupal 8 il est possible de facilement utiliser un template pour un formulaire. Pour cela il faut se baser sur le nom machine du formulaire.

Cela fonctionne pour nos formulaires custom, mais aussi pour les formulaires des modules tiers ou du core. Je vais ici utiliser un template pour le formulaire user_form qui correspond au formulaire de modification du compte utilisateur. Le nom machine de ce formulaire est user_form.

Définition du template :

Fichier : mon_module.module

  1. function mon_module_theme() {
  2. $theme = [];
  3. $theme['user_form'] = [
  4. 'render element' => 'form',
  5. ];
  6. return $theme;
  7. }

J'utilise comme clé de thème le nom machine du formulaire.

Je peux ensuite créer dans le dossier templates de mon thème le fichier user_form.html.twig :

  1. Test

  2. {{ form }}
  3. On peut rendre des champs « manuellement », mais il ne faut pas oublier de rendre le formulaire form à la fin : 

    1. Test

    2. {{ form.mon_champ_1 }}
  4. {{ form.mon_champ_2 }}
  • {{ form | without('mon_champ_1', 'mon_champ_2') }}
  •  

  • Par Kgaut
    Adhérent
    Kevin Gautreau

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

    Dans Drupal 8, le principe des hooks a été remplacé par un système d'évènement qui est lancé et peut être intercepté, cela se passe en 3 étapes :

    1. Création de l'évènement (classe étendant la classe Event)
    2. Lancer l'évènement
    3. Interception de l'évènement (Classe étendant l'interface EventSubscriberInterface)

    Pour cette évènement, nous allons prendre le contexte de mon site de pronostics sportifs. Je veux lancer un évènement quand un utilisateur fait ses pronostics

    Création de l'évènement

    Fichier : mon_module/src/Event/UserBetEvent.php

    1.  
    2. namespace Drupal\mon_module\Event;
    3.  
    4. use Drupal\mespronos\Entity\Day;
    5. use Drupal\user\UserInterface;
    6. use Symfony\Component\EventDispatcher\Event;
    7.  
    8. class UserBetEvent extends Event {
    9.  
    10. const EVENT_NAME = 'mespronos_user_bet';
    11.  
    12. /**
    13.   * The user account.
    14.   *
    15.   * @var \Drupal\user\UserInterface
    16.   */
    17. public $account;
    18.  
    19. /**
    20.   * The Day the user has bet on
    21.   *
    22.   * @var Day
    23.   */
    24. public $day;
    25.  
    26. public function __construct(UserInterface $account, Day $day) {
    27. $this->account = $account;
    28. $this->day = $day;
    29. }
    30.  
    31. }

    Cette classe est relativement simple, on défini les attributs que l'on veut rendre disponibles lors de l'interception de cet évènement, ici, l'objet User de l'utilisateur qui aura pronostiqué et la journée ($day) de compétition sur laquelle il aura fait ses pronostics.

    Dispatch de l'évènement

    Le code suivant est à placer là où vous souhaiter lancer l'évènement, dans mon cas il s'agit de la méthode submit de mon formulaire de pronostics :

    1. $event = new UserBetEvent($user, $day);
    2. $event_dispatcher = \Drupal::service('event_dispatcher');
    3. $event_dispatcher->dispatch(UserBetEvent::EVENT_NAME, $event);

    Évidement, il ne faut pas oublier de passer les paramètres que l'on a défini dans le constructeur de notre évènement (ici $user et $day)

    Interception de l'évènement

    Définition du subscriber

    Fichier : mon_autre_module/mon_autre_module.services.yml

    1. mon_autre_module.mespronos_user_bet:
    2.   class: 'Drupal\mon_autre_module\EventSubscriber\UserBetSubscriber'
    3.   tags:
    4.   - { name: 'event_subscriber' }

    Code du subscriber

    Fichier : mon_autre_module/src/EventSubscriber/UserBetSubscriber.php

    1.  
    2. namespace Drupal\mon_autre_module\EventSubscriber;
    3.  
    4. use Drupal\mespronos\Event\UserBetEvent;
    5. use Symfony\Component\EventDispatcher\EventSubscriberInterface;
    6.  
    7. class UserBetSubscriber implements EventSubscriberInterface {
    8.  
    9. public function onBet(UserBetEvent $event) {
    10. // On peut récuperer les attributs de l'évènement
    11. $user = $event->account;
    12. $day = $event->day;
    13.  
    14. // À vous de faire ce que vous voulez ici
    15. }
    16.  
    17. public static function getSubscribedEvents() {
    18. // Définition du ou des évènements que l'on écoute et méthode à executer
    19. return [
    20. UserBetEvent::EVENT_NAME => 'onBet',
    21. ];
    22. }
    23.  
    24. }

     

    Par Kgaut
    Adhérent
    Kevin Gautreau

    Drupal 8 - rejouer une fonction d'update

    Drupal tient un registre des versions des modules installés, ces versions correspondent au dernier numéro du hook_update exécuté du module.

    Si par exemple vous venez de lancer le hook 8301 du module field_group et que vous souhaitez le relancer, alors il faudra passer le module en version 8300.

    Voila comment faire avec drush :

    1. drush ev "drupal_set_installed_schema_version('field_group', 8300)"

     

    Par Kgaut
    Adhérent
    Kevin Gautreau

    Drupal 8 - Exemple d'utilisation simple du cache

    Drupal 8 propose un système de cache très puissant et à plusieurs niveaux.

    Ici nous allons voir comment stocker simplement le résultat d'une requête en cache afin de ne pas avoir à la lancer la requête SQL à chaque appel.

    Commençons par définir notre « conteneur » de cache dans le fichier mon_module.services.yml :

    1. cache.mon_module:
    2.   class: Drupal\Core\Cache\CacheBackendInterface
    3.   tags:
    4.   - { name: cache.bin }
    5.   factory: cache_factory:get
    6.   arguments: [mon_module]

    mon_module sera le nom de notre conteneur de cache.

    Cela permettra de distinguer les données que nous mettrons dedans et de ne pas écraser d'autres caches d'autres modules. Si vous utilisez le cache en base de données (par défaut) vous verrez qu'une nouvelle table cache_mon_module a été créée.

    Ensuite voici un exemple de lecture du cache, et d'écriture si la donnée n'est pas présente :

    1. public function getVersion() {
    2. // On teste si la clé « database.version » est présente dans le conteneur de cache « mon_module »
    3. if ($results = \Drupal::cache('mon_module')->get('database.version')) {
    4. // Si c'est le cas, les données stockées sont dans l'attribut « data »
    5. return $results->data;
    6. }
    7. // Sinon on effectue la requête désirée
    8. $version = $this->connection->select('version', 'v')->fields('v', ['version'])->execute()->fetch();
    9. // Et on met la valeur en cache
    10. \Drupal::cache('mon_module')->set('database.version', $version->version);
    11.  
    12. return $version->version;
    13. }

    Il est possible aussi de donner date d'expiration afin que cette clé de cache ne soit plus valable une fois cette date passée :

    1. // cache valable 1 h (3600 secondes)
    2. \Drupal::cache('mon_module')->set('database.version', $version->version, date('U') + 3600);

     

    Par Kgaut
    Adhérent
    Kevin Gautreau

    Drupal - Drush - Appeler un script php et lui passer un argument

    Il est possible via drush d’exécuter un script php et de profiter de toute l'API de drupal pour effectuer des traitements (création / suppression de contenu, modification, import de traductions...)

    On utilise pour cela la commande drush php-script en lui passant le chemin vers le script relatif à la racine de drupal :

    1. # Exemple d'appel d'un script
    2. drush @alias php-script ../scripts/process/import-translations.php

    Mais il est aussi possible de passer des arguments à ce script :

    1. #Je passe ici le chemin vers le fichier à importer
    2. drush @alias php-script ../scripts/process/import-translations.php --file=../files/translations/imports/2019-05-14-translations.csv

    Et voici comment le récupérer dans notre script drush :

    1. # Récupération du paramètre file
    2. $file = drush_get_option('file');

    À noter que l'on peut aussi fournir une valeur par défaut :

    1. # ici, si --lang n'est pas passé lors de l'appel du script
    2. # alors $lang prendra la valeur « en »
    3.  
    4. $lang = drush_get_option('lang', 'en');

     

    Par Kgaut
    Adhérent
    Kevin Gautreau

    Drupal 8 - Se connecter à une base de données tierce

    Outre la base de données « classique » de drupal, il est aussi possible de se connecter à une autre base de données.

    Pour cela dans le fichier de settings il faut définir les identifiants :

    1. $databases['seconde_db'] = $databases['default'];
    2. $databases['seconde_db']['default']['host'] = 'HOST_SECONDE_DB';
    3. $databases['seconde_db']['default']['database'] = 'SECONDE_DB';
    4. $databases['seconde_db']['default']['username'] = 'USER_SECONDE_DB';
    5. $databases['seconde_db']['default']['password'] = 'PASSWORD_SECONDE_DB';

    Ensuite dans le code de notre drupal on peut sélectionner cette seconde base de données :

    1. # On sélectionne la base secondaire
    2. Database::setActiveConnection('seconde_db');

    Pour ensuite effectuer les requêtes que l'on souhaite, via la database API de drupal.

    Attention à la fin ne pas oublier de rebasculer sur la base de données par défaut afin de ne pas casser tout le drupal :

    1. # On bascule sur la base de données par défaut
    2. Database::setActiveConnection();

     

    Par Mixalis44
    Adhérent
    Mickael Zafiriou
    Développeur Drupal depuis 2013.

    Créer des liens de menus dynamiquement

    L'élément, selon moi, le plus important d'un site web est la qualité de ses menus. Comme il est possible d'arriver par n'importe quelle page sur un site, il est donc important que l'internaute puisse y naviguer de façon simple et fluide. Voici comment gérer une partie de vos menus dynamiquement sous Drupal 8.

    Pages