Planète

Voici comment supprimer le basefield « mon_champ_a_suppr » de mon type d'entité personnalisé « mon_type_entite ».

/** * Delete basefield mon_type_entite.mon_champ_a_suppr */function monmodule_update_8020() {  $update_manager = Drupal::service('entity.definition_update_manager');  $definition = $update_manager->getFieldStorageDefinition('mon_champ_a_suppr', 'mon_type_entite');  $update_manager->uninstallFieldStorageDefinition($definition);  return t('mon_type_entite : mon_champ_a_suppr was uninstalled');}

Lancez les mises à jours de base de données de drupal (drush updb par exemple) et hop, votre champ sera supprimé de votre base de données, évidement si votre type d'entité avait des enregistrements, les données concernants le champ supprimé seront perdues.

Certains diront qu'il est possible d'utiliser la commande drush entup, mais le mécanisme n'est plus présent depuis drupal 8.7. (mais si vraiment vous en avez besoin, vous pouvez regarder du côté du module Devel Entity Updates, à n'installer qu'en connaissance de cause !

La DrupalCon est un événement organisé par la communauté Drupal qui regroupe des présentations selon différents axes :

Commerce et Marketing
DevOps et Infrastructure
Drupal et Backend

Drupal et Frontend
La Communauté Drupal et Être humain
Entreprise

Après une courte absence, relayée par la Drupal Europe en 2018, c'est le retour des DrupalCon en Europe. Pour sa reprise, la DrupalCon aura lieu à Amsterdam du 28 au 31 octobre 2019.

La DrupalCon est un événement organisé par la communauté Drupal qui regroupe des présentations selon différents axes :

Commerce et Marketing
DevOps et Infrastructure
Drupal et Backend

Drupal et Frontend
La Communauté Drupal et Être humain
Entreprise

Après une courte absence, relayée par la Drupal Europe en 2018, c'est le retour des DrupalCon en Europe. Pour sa reprise, la DrupalCon aura lieu à Amsterdam du 28 au 31 octobre 2019.

Pour un type d'entité personnalisé, les alias peuvent se gérer à l'aide de motifs via le module pathauto.

Mais à l'instar des nœuds, parfois nous voulons pouvoir avoir la main sur l'alias directement.

Pour cela on peut ajouter un computed field à notre type d'entité afin de laisser la main au créateur du contenu de décider de l'alias.

Dans la méthode baseFieldDefinitions de notre type d'entité :

$fields['path'] = BaseFieldDefinition::create('path')  ->setLabel(t('URL alias'))  ->setDisplayConfigurable('form', TRUE)  ->setComputed(TRUE);

Ensuite il faut aller configurer l'affichage du formulaire afin d'ajouter ce champ :

Mise en place du recueil des consentements des utilisateurs via EU Cookie Compliance puis transmission à Google Tag Manager

Lorsque l'on utilise l'Ajax API de Drupal 8, on peut être amené à modifier/remplacer le loader qui s'affiche lorsqu'une requête est en cours d'exécution. Pour personnaliser cette barre de progression, cette article présentera les étapes et les différents bouts de codes nécessaires à cette fonctionnalité.

Sur un site drupal 8, j'ai pour habitude de créer un élément de menu spécifique dans la barre d'administration qui comprend toutes les parties un peu métier du site.

La plupart du temps cette route renvoie vers une méthode « dashboard » d'un AdminController qui au mieux affiche quelques informations.

Voici comment transformer cette route, en listes des sous-menus, à la manière de la page « Configuration ».

Dans mon_module.routing.yml :

mon_module.admin.dashboard:  path: '/admin/mon_module/dashboard'  defaults:    _controller: '\Drupal\system\Controller\SystemController::overview'    link_id: 'mon_module.admin.dashboard'    _title: 'dashboard'  requirements:    _permission: 'access mon_module dashboard'

et voila le résultat :

Pour information, voici comment ajouter cette route à la barre d'administration (dans mon cas en première place) :

dans le fichier mon_module.links.menu.yml :

mon_module.admin.dashboard:  title: 'Mon Module'  route_name: mon_module.admin.dashboard  description: 'Mon Module dashboard'  parent: system.admin  weight: -20

Sur des projets j'ai depuis quelques jours, lors d'un composer install, l'erreur suivante arrive :

Package type "drupal-console-library" is not supported

Pas encore eu le temps de creuser la cause, mais une solution que j'ai trouvé est d'ajouter la gestion des « drupal-console-library » dans la section installer-paths de mon fichier composer.json en ajoutant la ligne suivante :

"vendor/drupal/{$name}": ["type:drupal-console-library"],

Voici la section en entier :

        "installer-paths": {
            "web/core": ["type:drupal-core"],
            "vendor/drupal/{$name}": ["type:drupal-console-library"],
            "web/libraries/{$name}": ["type:drupal-library"],
            "web/modules/_contrib/{$name}": ["type:drupal-module"],
            "web/profiles/_contrib/{$name}": ["type:drupal-profile"],
            "web/themes/_contrib/{$name}": ["type:drupal-theme"],
            "drush/_contrib/{$name}": ["type:drupal-drush"]
        }

Si quelqu'un a une idée de la raison, je suis preneur !