Articles de l'utilisateur

Par Kgaut
Adhérent
Kevin Gautreau

PHP, Git, MySQL, configuration et environnements

Un point qui revient souvent lors du développement est la gestion des paramètres de configuration (MySQL par exemple) sur les différents environnements (production, préproduction, local…) et entre différents développeurs d'une même équipe.

Si l’on est tout seul à travailler sur un projet avec un seul environnement (la production) alors la question ne se pose pas, on met les paramètres dans le fichier de configuration (wp-config.php pour wordpress, settings.php pour drupal…) et ça fonctionne.

Le problème du versioning de la configuration

Mais si l’on utilise un système de gestion de version (git avec gitlab / github par exemple) alors cela veut dire que nos identifiants de connexion à la base de données de notre site en production sont stockés sur d’autres serveurs que l’unique sur lequel il devrait être...

Github et Gitlab sont des solutions éprouvées, mais on est jamais à l’abri d’une fuite ou d’un piratage, ou tout bêtement de l’oubli de désactiver l’accès au dépôt à un ancien collaborateur avec qui l’histoire s’est mal terminée et qui a une éthique pro douteuse.

Le problème du travail en équipe

Autre potentiel problème, imaginons une équipe de deux personnes (A et B) qui travaillent en local sur un site en développement.

A travaille sous windows avec wamp, par défaut l’identifiant de connexion à la base de données sous wamp est «root», il n’y a pas de mot de passe.

B travaille sous macos avec mamp, par défaut l’identifiant de connexion à la base de données sous mamp est «root», le mot de passe est lui «root».

On voit vite le jeu que cela va être à chaque commit, A et B s'écrasant mutuellement le fichier de configuration de l’autre.

En plus, notre sysadmin étant moins drôle, il refuse de définir le mot de passe de mysql en production sur «root», encore moins marrant, il refuse de ne pas en définir… Donc on se retrouve avec un troisième jeu d'identifiants que l’on devra (re)mettre à chaque mise à jour du site en production…

Note : évidement utiliser "root" comme idenfiant ou mot de passe, ailleurs qu'en local est évidement à éviter impérativement ! Il faut créer un utilisateur qui n'a la main que sur la (ou les) base(s) de données du site. Bonne pratique à utiliser aussi en local, même si c'est moins «dangereux».

Le problème des environnements

En plus des différences d’identifiants de base de données, il existe souvent d’autres divergences entre deux environnements d’un même site.

Généralement notre site ne fonctionne pas exactement pareil en local, sur notre serveur de développement, sur notre préproduction et sur notre serveur de production.

Par exemple, si l'on travail sur un site d'e-commerce, on aura pas forcément la même brique de paiement, ou il faudra lui passer des paramètres différents pour activer le mode test.

Autres exemples : l'affichage des messages d'erreurs, la désactivation du cache en local pour éviter d’avoir à le vider manuellement à chaque modification...

Enfin, On peut (doit ?) aussi désactiver ou intercepter les envois de mail sur les autres serveurs que celui de production.

Les solutions

Avertissement

Les solutions décrites ici sont des solutions que j'ai trouvées, expérimentées, modifiées... Je n'en réclame ni la paternité ni leur supériorité sur une autre solution, d'ailleurs, si vous faites autrement, n'hésitez-pas à en parler.

Se baser sur le HTTP_HOST

Un première possibilité serait, au sein même du fichier de configuration, d’ajouter des conditions en fonction de l’url par exemple.

Ainsi si l’url du site est “monsite.dev” on sait que l’on est en local, si c’est "monsite.com" alors on est en production.

Exemple de code :

//Paramètres par défaut = production
$databases = array (
  'default' => 
  array (
    'default' => 
    array (
      'database' => 'monsite.com',
      'username' => 'monsite',
      'password' => 'loremipsum',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => '',
    ),
  ),
);
$conf['site_env'] = 'PROD';

// Si l'url se termine par .mapreprod.monentreprise.com"
// par exemple monsite.mapreprod.monentreprise.com
// alors on est en préproduction
if(preg_match('`\.mapreprod.monentreprise.com$`',$_SERVER['HTTP_HOST'])) {
  $conf['site_env'] = 'PREPROD';
  $databases['default']['default']['database'] = 'monsite.com';
  $databases['default']['default']['username'] = 'monsite_preprod';
  $databases['default']['default']['password'] = '123456789';
}

// Si l'url se termine par .dev"
// par exemple monsite.dev
// alors on est en local
if(preg_match('`\.dev$`',$_SERVER['HTTP_HOST'])) {
  $conf['site_env'] = 'DEV';
  $conf['theme_debug'] = true;
  $conf['hybridauth_debug'] = 1;
  $databases['default']['default']['database'] = 'monsite.com';
  $databases['default']['default']['username'] = 'root';
  $databases['default']['default']['password'] = 'mysql';
}

Par défaut, je définis les paramètres de production de mon site, ensuite, je me base sur le HTTP_HOST (l'adresse de notre site) pour déterminer l'environnement (ici préproduction ou local).

Et en fonction j'ajuste à la fois ma configuration mysql ainsi que différents paramètres de configuration pour mon site.

À noter, je définis aussi une variable qui contient l'environnement dans lequel je suis (ici : $conf['site_env']) ce qui peut être utile dans notre code pour savoir si l'on doit par exemple envoyer mail, sms, notification...

Quelques inconvénients à cette solution :

  • Les identifiants de notre prod et de nos autres environnement sont versionnés.
  • Si un nouveau développeur arrive sur le projet et qu'il a un fonctionnement différent, alors le fichier de config sera sans cesse écrasé.

La config différentielle dans un fichier non versionné

C'est la solution que j'utilise maintenant, on se base non plus sur l'url mais sur un fichier supplémentaire, qui défini la configuration spécifique et écrase potentiellement la configuration selon l'environnement.

Exemple :

Le fichier de configuration commun et versionné :

// La configuration de la base de donnée n'est pas définie car elle
// spécifique à chaque environnement
 $databases = array();

// On inclue le fichier settings.local.php s'il existe
if (file_exists(__DIR__ . '/settings.local.php')) {
  include __DIR__ . '/settings.local.php';
}

Le fichier de configuration settings.local.php en production (lui non versionné) :

<?php
  $conf['site_env'] = 'PROD';
  $databases['default']['default']['database'] = 'monsite.com';
  $databases['default']['default']['username'] = 'monsite';
  $databases['default']['default']['password'] = 'loremipsum';

Le fichier de configuration settings.local.php en local (lui non versionné non plus) :

<?php
  $conf['site_env'] = 'DEV';
  $conf['theme_debug'] = true;
  $conf['hybridauth_debug'] = 1;
  $databases['default']['default']['database'] = 'monsite.com';
  $databases['default']['default']['username'] = 'root';
  $databases['default']['default']['password'] = 'mysql';

Les fichiers settings.local.php ne sont pas versionnés grâce au fichier .gitignore et cette ligne (ici pour un drupal, mais à adapter en fonction de votre configuration) :

web/sites/*/settings.local.php

Avantages de cette solution :

  • Une fois configuré, le fichier de configuration de base ne bouge pas, il contient la configuration commune du site.
  • Pas de risque de s'écraser mutuellement la configuration entre développeurs.
  • Les fichiers settings.local.php ne sont pas versionné et donc aucun identifiant ne se retrouve sur github ou gitlab.

Je vois un inconvénient principal : quand un nouveau développeur arrive sur le projet, il faut qu'il comprenne cette organisation, c'est pourquoi généralement je crée un fichier settings.local.example.php qui lui est versionné et j'ajoute les lignes suivantes au readme du projet :

Pour ne pas risquer d'altérer la configuration de la base de données en production,
les identifiants de base de données doivent être renseignés dans un fichier `sites/default/settings.local.php`,
vous pouvez copier le fichier `sites/default/settings.local.example.php` en le renommant pour avoir un exemple
de fichier local.

Le fichier settings.php ne doit jamais être modifié directement, sauf cas très particulier.

Conclusion

La solution décrite juste au-dessus me convient bien, et semble bien marcher aussi pour les personnes avec qui je travaille. Néanmoins, ça n'est évidemment pas la solution universelle et vous avez peut-être mieux, si c'est le cas, n'hésitez-pas à venir en discuter dans les commentaires !

Par Kgaut
Adhérent
Kevin Gautreau

Module Drupal 8 - Email Registration pour utiliser l'email comme identifiant

Un besoin classique sur un site avec gestion de membre est d'utiliser l'email comme identifiant. De base drupal utiliser la notion de "pseudo" et demande un email en plus.

Si l'on souhaite n'utiliser que l'email et supprimer complètement la notion de pseudo, on peut utiliser le module "Email Registration".

Ainsi il cache complètement le champs "pseudo" du formulaire de création de compte. Pour des raisons techniques le "username" est quand même généré en fonction de l'adresse email et de l'id de l'utilisateur, mais le module propose un hook spécifique si l'on souhaite mettre en place notre propre règle de génération de pseudo (hook_email_registration_name).

Le pseudo peut quand même être utilisé et défini par l'utilisateur en ajustant les permissions, mais il n'est plus nécessaire pour s'inscrire. De même façon, lors de l'authentification, il est possible d'utiliser à la fois son email ou son pseudo s'il est définis.

Ce module existe en stable pour drupal 7 est est en alpha pour drupal 8 mais fonctionne déjà sans soucis.

Pour installer le module, soit via composer avec :

composer require drupal/email_registration

Soit en le téléchargeant directement sur la page du module sur drupal.org : https://www.drupal.org/project/email_registration

Par Kgaut
Adhérent
Kevin Gautreau

Module Drupal 8 - Admin Toolbar

Une présentation rapide d'un petit module d'administration qui ne révolutionne rien mais qui permet de gagner de précieuses secondes : Admin toolbar.

Il surcharge la barre d'administration et lui ajoute des menus déroulants :

Ce module, couplé à coffee, permet de fluidifier la navigation dans le backoffice drupal, qui peut souvent s’avérer laborieuse avec les arborescences à 57 niveaux...

Et le sous module "admin_toolbar_tools" ajoute des liens vers des fonctions bien pratiques pour l’administrateur d'un site drupal : vidage de cache, updates, cron...

Pour l’installer via composer :

composer require drupal/admin_toolbar

Ou bien en le téléchargeant directement sur la page du module : https://www.drupal.org/project/admin_toolbar

Par Kgaut
Adhérent
Kevin Gautreau

Module Drupal 8 - CKEditor Responsive Plugin

Un peu d'auto-promotion pour commencer cette année 2017, je vais vous parler d'un de mes petits modules : CKEditor Responsive Plugin.

Ce module comme son nom l'indique est un plug-in pour CKEditor, qui permet d'ajouter des zones responsives dans une textarea afin de remplacer les tableaux.

Au lieu d'insérer du markup type table, ce plugin va insérer des divs avec des classes de dimensionnement assez comunes. Par exemple pour deux zones 50% voici ce qui sera inséré :

<div class="ckeditor-col-container clearfix">
  <div class="grid-6 sixcol first-col"><p>lorem ipsum</p></div>
  <div class="grid-6 sixcol last-col"><p>lorem ipsum</p></div>
</div>

À vous ensuite d'ajouter les propriétés et définitions nécessaires dans votre feuille de style front si besoin. Vous pouvez prendre exemple sur la css intégré au module (qui est utilisé dans l'éditeur.

Voci le fonctionnement du module : clic sur le bouton dans l'éditeur :

Sélection du template voulu :

Voici le résultat dans l'éditeur :

Ce module n'a pas du tout vocation à remplacer un module type paragraphs, mais il permet de laisser au client la possibilité de faire des mise en page avancées sans qu'il n'ai besoin de connaître le HTML ou de risquer de casser la mise en page.

Il est disponible pour Drupal 7 et Drupal 8.

Pour l'installation via composer :

composer require drupal/ckeditor_responsive_plugin

Ou bien en le téléchargeant directement sur la page du module : https://www.drupal.org/project/ckeditor_responsive_plugin

Par Kgaut
Adhérent
Kevin Gautreau

Module Drupal 8 - Geolocation Field

Geolocation field est un module Drupal 7 et 8 qui, comme son nom l'indique, permet d'ajouter un champs à ses types de contenus de type "Position GPS".

En backoffice on peut proposer une google map avec champ de recherche et l'administrateur pourra ainsi placer le pointeur précisement :

En front, différentes options d'affichage sont possibles :

Il est aussi possible de ne pas utiliser la google map fournie pour le front mais d'utiliser les données en brut et retourner du json par exemple si on a un ensemble de points à afficher sur une carte.

Pour l'installation, en passant par composer :

composer require drupal/geolocation

Ou bien en le téléchargeant directement sur la page du module : https://www.drupal.org/project/geolocation

Par Kgaut
Adhérent
Kevin Gautreau

Module Drupal 8 - Weight pour trier les contenus

Le module weight permet d'ajouter un attribut de "poids" au contenu qui peut être utilisé dans les listing pour les ordonner comme l'on veut.

La version 8 s'intègre très bien avec views et permet d'avoir un réordonnancent en backoffice sur un listing de contenu. (ce qui pouvait être obtenu sous drupal 7 avec la combinaison weight + draggable views)

Installation du module

"À l'ancienne" en téléchargeant la dernière version sur drupal.org : https://www.drupal.org/project/weight

ou via composer avec composer require drupal/weight.

La version 8.x-3.0 du module est sortie, mais à ce jour elle nécessite 3 patches pour fonctionner correctement :

Si vous utilisez composer pour gérer vos modules, voici la section à ajouter à votre fichier composer.json pour patcher le module automatiquement :

  // Dans la section "extra"      
  "patches": {
            "drupal/weight": {
                "Strict warning: Non-static method ": "https://www.drupal.org/files/issues/weight-non-static-method-2671844-3.patch",
                "Views widget assumes that weight field name is named 'field_weight'": "https://www.drupal.org/files/issues/weight-views-field-name-2687953-0.patch",
                "Weight selector missing": "https://www.drupal.org/files/issues/weight-show-selector-2671840-4.patch"
            }
        }

Plus d'informations sur la gestion des patchs via composer ici.

Configuration du tri

Première chose à faire, ajouter un champ de type "Poids" au type de contenu / entité que l'on souhaite trier :

Vous pourrez ensuite configurer le range qui par défaut est de 20 (donc possibilité de trier de -20 à +20) vous pouvez l'augmenter si vous avez beaucoup de contenu.

Maintenant nous allons utiliser créer une vue d'administration pour pouvoir "drag'n'droper" les contenus pour en changer le poids.

Il faut utiliser le format "Tableau" et bien penser à limiter au type de contenu que l'on souhaite trier :

Ajoutons aux champs, le champs "poids" que nous avons créé, afin d'avoir la petite flèche multidimensionnelle pour réordonner. Attention il faut bien prendre l'élément "Selector" si l'on sélectionne l'autre, alors on aura juste une cellule dans le tableau nous indiquant le poids du contenu, ce n'est pas ce que l'on veut ici :

Deuxième chose à faire, ajouter un critère de tri sur ce champ :

Évidement il faudra trier par poids croissant (un contenu avec un poids de -10 doit être placé avant celui qui a un poids de 10).

Réordonnez les critères de tri pour mettre le tri par poids en premier :

Enregistrez votre vue et rendez-vous sur la page crée, vous pouvez maintenant réordonner vos contenus comme vous le souhaiter, en pensant bien à enregistrer.

Enfin, pensez bien à modifier vos vues front pour prendre en compte le critère de tri maintenant existant (de la même façon que nous l'avons créé dans la vue backoffice.)

Par Kgaut
Adhérent
Kevin Gautreau

Drupal 8 - Définir un fil d'Ariane personnalisé

Drupal 8 améliore grandement la manière de gérer le fil d'Ariane (ou breadcrumbs en Anglais). Dans ce post nous allons voir comment définir un fil d'Ariane pour les contenus d'un type particulier.

Ici nous considérerons que :

  • Le type de contenu s'appellera "Témoignage", son nom machine sera "temoignage"
  • Mon module s'apelle "temoignages_module"
  • J'ai une page de listing définie par un controller dont la route sera temoignages.page_listing.

Ces éléments seront à adapter en fonction de vos besoins.

Définitions du service

S'il n'existe pas, créer le fichier temoignages_module.services.yml et ajouter le contenu suivant :

services:
  temoignages_module.breadcrumb.temoignage:
    class: Drupal\temoignages_module\Breadcrumb\TemoignagesBreadcrumb
    tags:
      - { name: breadcrumb_builder, priority: 100 }

Implémentation du service

Toujours dans le module, créer le fichier "TemoignagesBreadcrumb.php" dans le dossier : src/Breadcrumb du module temoignages_module, et y coller le contenu suivant :

<?php

namespace Drupal\temoignages_module\Breadcrumb;

use Drupal\Core\Breadcrumb\BreadcrumbBuilderInterface;
use Drupal\Core\Routing\RouteMatchInterface;
use Drupal\Core\Link;
use Drupal\Core\Breadcrumb\Breadcrumb;

class TemoignagesBreadcrumb implements BreadcrumbBuilderInterface {

  public function applies(RouteMatchInterface $route_match) {
    if ($route_match->getCurrentRouteMatch()->getRouteName() == 'entity.node.canonical') {
      $node = $route_match->getParameter('node');
      if ($node->getType() == 'temoignage') {
        return TRUE;
      }
    }
    return FALSE;
  }

  public function build(RouteMatchInterface $route_match) {
    $breadcrumb = new Breadcrumb();
    $breadcrumb->addCacheContexts(['route']);
    $links = [];
    $links[] = Link::createFromRoute(t('Home'), '<front>');
    $links[] = Link::createFromRoute(t('Tous les témoignages'), 'temoignages_module.page_listing');
    return $breadcrumb->setLinks($links);
  }
}

En détails

La première méthode applies doit retourner TRUE ou FALSE en fonction de si on est dans un cas ou notre breadcrumb personnalisé doit être appliqué.

Je vérifie pour commencer que je suis en train de visualiser une node :

$route_match->getCurrentRouteMatch()->getRouteName() == 'entity.node.canonical'

Si c'est le cas, je récupère cette node et si elle est bien du type "temoignage" je retourne TRUE

      $node = $route_match->getParameter('node');
      if ($node->getType() == 'temoignage') {
        return TRUE;
      }

Sinon je retourne FALSE.

Enfin, la méthode build, comme son nom l'indique construit le fil d'Ariane, qui consiste en fait en un tableau de liens.

Je commence par mettre un tag de cache à mon fil d'Ariane en lui disant qu'il dépend de la route.

$breadcrumb->addCacheContexts(['route']);

Je construis ensuite mon tableau de liens, qui en sera constitué de deux, le premier vers la page d'accueil et le second vers ma page de listing :

    $links = [];
    $links[] = Link::createFromRoute(t('Home'), '<front>');
    $links[] = Link::createFromRoute(t('Tous les témoignages'), 'temoignages_module.page_listing');
    return $breadcrumb->setLinks($links);

Et... c'est tout, plus qu'à reconstruire le cache et vous pourrez vérifier que votre fil d'Ariane fonctionne bien

Vous trouverez plus d'exemple dans les sources de mon module de pronostics : https://github.com/mespronos/mespronos/tree/8.x-1.x/src/Breadcrumb, pour la définitions des services liés, c'est ici : https://github.com/mespronos/mespronos/blob/8.x-1.x/mespronos.services.yml.

Par Kgaut
Adhérent
Kevin Gautreau

Créer un thème personnalisé pour Drupal 8

Quand l'on travaille avec Drupal, on a rapidement besoin d'avoir un thème personnalisé ne serai-ce que pour y stocker ses templates custom et ses feuilles de styles.

Personnellement, j'ai l'habitude de faire un thème "front" et un thème "back" car j'ai souvent besoin de personnaliser le rendu de l'interface d'administration pour qu'elle convienne au mieux à mes clients.

Drupal 8 comme Drupal 7 utilise la notion de thème "parent", c'est à dire que si mon thème custom a comme parent (comme base_theme) le thème bartik, alors il reprendra toutes ses propriétés (templates, css, js...), et l'on pourra surcharger ce qui nous intéresse.

Il existe des thèmes "starter kit", on peut citer Zen (https://www.drupal.org/project/zen) par exemple qui est un des plus connu. Il s'agit en fait d'un thème parent qui propose un thème starterkit tout configuré que l'on peut ensuite personnaliser en fonction de nos besoins.

On peut aussi évidement faire ses propres thèmes custom. À noter que si vous ne prenez pas comme thème parent Bartik ou Zen, il faudra quand même prendre le thème "classy" comme parent.

Comment créer son theme ?

On va partir sur le nom de theme suivant "Mon Site Front" : on va commencer par créer le dossier mon_site_front dans le dossier /themes/custom (on pourrait le mettre directement dans /themes, mais comme pour les modules c'est une bonne pratique de différentier les élément personnalisé (custom) des éléments téléchargés (qui seront eux dans un sous-dossier "contrib").

La définition d'un thème passe, comme pour un module par un fichier mon_site_front.info.yml, en voici son contenu :

name: Mon Site Front
type: theme
description: Mon theme de demonstration
package: MonSite
core: 8.x
base theme: bartik

On doit aussi créer un fichier mon_site_front.theme, vide, qui pourra contenir plus tard nos fonction de preprocess et différents hooks.

J'ai ici pris comme thème de base "Bartik".

Une fois cela fait on passe dans le menu d'administration "Apparence" pour activer notre thème et le définir comme thème par défaut :

Pour faire un thème d'administration custom cette fois on va prendre comme base thème "Seven" :

name: Mon Site Back
type: theme
description: Mon theme de demonstration Backoffice
package: MonSite
core: 8.x
base theme: seven

Cette fois dans le menu Apparence, on devra installer le thème puis le définir comme thème d'administration :

Un thème d’administration que je trouve très sympa et qui me sert de thème parent est Adminimal (https://www.drupal.org/project/adminimal_theme).

Drupal Console permet aussi de générer des thème, via la commande drupal generate:theme, et il demande de quel thème parent notre thème custom doit hériter.

Vous pouvez retrouver les maigres sources de ce post sur github :

Par Kgaut
Adhérent
Kevin Gautreau

Module Drupal 8 - Field Group

Avec un contenu personnalisé dans drupal, on peut rapidement se retrouver avec des dizaines et des dizaines de champs dans le formulaire de création de contenu. Field Group est un module drupal 7 et 8 qui permet de les réorganiser, via l'interface d'administration en "groupes", qui peuvent être au choix, des fieldset, des onglets, des acordéons... et ainsi avoir un formulaire plus propre et plus clair pour celui qui devra ensuite créer/modifier les contenus.

Ainsi, dans l'exemple suivant, j'ai créé un groupe qui sera le conteneur de mes deux onglets (il y en a trois en réalité mais je ne voulais pas faire un screenshot de 15km de haut)

 

Et voici le rendu sur le formulaire de création de contenu :

et quand on sélectionne un autre onglet :

Bref, un module indispensable quand l'on veut faire des formulaires bien propres ! Mais il permet aussi de faire des groupes de champs pour l'affichage en front.

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

Installation avec composer :

composer require drupal/field_group

 

Par Kgaut
Adhérent
Kevin Gautreau

Les suggestions de templates dans Drupal 8

Ça n'est pas une nouveauté de Drupal 8, toute partie d'une page d'une page est rendue avec un template.

Il existe un paquet de templates de base :

  • html.html.twig qui s'occupe de rendre le doctype, le contenu de la balise <head> et qui ouvre et ferme la balise <body>
  • page.html.twig lui commence là où html.html.twig s'arrête, c'est a dire l'intérieur de la balise body
  • region.html.twig pour le contenu d'une région (header, footer, content... bref les régions définie dans notre theme)
  • node.html.twig pour le contenu d'une node
  • field.html.twig pour un champ défini dans un type de contenu ou une entité
  • block.html.twig pour les blocks...

Si on prend comme exemple le template node.html.twig qui est donc utilisé pour afficher l'ensemble des noeuds (page, article...)

On peut rendre ces templates plus spécifiques, si on veut par exemple un template spécial pour les noeuds de type "article" on peut copier le fichier node.html.twig en node--article.html.twig.

Il existe aussi d'autres suggestions :

  • node--NID.html.twig en substituant NID par l'id du noeud en question
  • node--VIEW_MODE.html.twig pour utiliser un template différent si on affiche le noeud en mode "teaser" ou "full"
  • ...

On peut connaitre facilement les noms de de template possible pour un élément en activant le debug de twig et en regardant le code html de notre page :

Les suggestions de templates dans le code html

Les éléments préfixés par * sont les noms de template possible, celui préfixé par x est celui effectivement utilisé, ce sont les suggestions de template (ou template suggestions). Il en existe un paquet de base qui suffisent dans la plupart des cas, mais on peut aussi vouloir définir un template plus spécifique.

Définir sa propre suggestion de template

Pour drupal 7 on utilisait pour ça le HOOK_preprocess_HOOK, dans drupal 8 deux hooks ont étés créés : HOOK_theme_suggestions_HOOK et HOOK_theme_suggestions_HOOK_alter.

Le premier "HOOK" doit être remplacé par le nom de notre module qui implémente le hook, le second par le nom de l'élément pour lequel on veut ajouter une suggestion.

Si on a un module qui s'appelle "mon_module" et que l'on veut ajouter une suggestion de template pour les noeuds (node) alors on définira la fonction suivante :

function mon_module_theme_suggestions_node_alter(array &$suggestions, array $variables) {
  //...
}

cette fonction devra ajouter au tableau "suggestions" les nouvelles possibilités, par exemple :

function mon_module_theme_suggestions_node_alter(array &$suggestions, array $variables) {
  $suggestions[] = 'node__montemplate';
}

Note : quand on définit une suggestion de template dans le code il faut bien remplacer les "--" par des "__"

ainsi :

Le HOOK_theme_suggestions_HOOK ne fonctionne pas pour les nodes (pour une raison que j'ignore et je suis prenneur d'une explication, mais qui fonctionne pour les autres éléments.

Si on veut un template html spécifique pour le type de contenu :

function monmodule_theme_suggestions_html(array $variables) {
  $path_args = explode('/', Url::fromRoute('<current>')->getInternalPath());
  $suggestions = [];
  if(count($path_args) >=2 && $path_args[0] == 'node' && $node = Node::load($path_args[1])) {
    $suggestions[] = 'html__' .$node->getType();
  }
  return $suggestions;
}

La même chose pour "page" :

function slides_core_theme_suggestions_page(array $variables) {
  $path_args = explode('/', Url::fromRoute('<current>')->getInternalPath());
  $suggestions = [];
  if(count($path_args) >=2 && $path_args[0] == 'node' && $node = Node::load($path_args[1])) {
    $suggestions[] = 'page__' .$node->getType();
  }
  return $suggestions;
}

et pour "region" :

function slides_core_theme_suggestions_region(array $variables) {
  $path_args = explode('/', Url::fromRoute('<current>')->getInternalPath());
  $suggestions = [];
  if(count($path_args) >=2 && $path_args[0] == 'node' && $node = Node::load($path_args[1])) {
    $suggestions[] = $variables['theme_hook_original'].'__'.$variables['elements']['#region'].'__' .$node->getType();
  }
  return $suggestions;
}

note : j'ai ici utilisé la variable $variables['theme_hook_original'] qui contient le prefixe que l'on doit utiliser pour chaque template (ici "region"), la variable $variables['elements']['#region'] contient elle le nom de la région.

Voici les templates disponibles ainsi pour la région "header" quand on visualise un contenu de type "article" :

Évidement il est possible d'ajouter plusieurs suggestions pour un même élément.

 

Par Kgaut
Adhérent
Kevin Gautreau

Drupal - Script drush pour changer d'environement (développement / production)

Quand on fait des modifications sur un site Drupal on doit parfois récupérer une base de production afin d'avoir toute la configuration ainsi que les contenus à jour.

Ensuite généralement on désactive le cache, active le module devel...

Mettant en pratique l'adage comme quoi un développeur préfère passer deux heures à automatiser une tache qui ne lui prendrait que 30 secondes s'il l'effectuait manuellement, j'ai fais un script drush en ce sens.

Ce script propose deux nouvelles fonctions à appeler directement avec drush :

  • deprod : pour passer un site en mode "développement" : activation de devel, stage_file_proxy, désactivation de l’agrégation des fichiers css et js, désactivation des caches, affichage des message d'erreurs, désactivation des modules google analytics et piwik
  • reprod : pour passer un site en mode "production" : exactement l'inverse de plus haut

Ce script est interactif, pour chaque action, il vous demandera s'il doit l'effectuer ou non :

Drush deprod

Vous pouvez aussi activer le mode "YOLO" avec le paramètre -y pour effectuer toutes les actions :

Ce script est sur github : https://github.com/kgaut/drupal-snippets/blob/7.x-1.x/Drush/deprod.drush.inc.

Pour l'installer, il faut copier le fichier directement dans votre dossier .drush qui doit être dans votre dossier "home" (ou documents sous windows).

Ensuite pour l'utiliser :

drush @alias deprod

// ou

drush @alias reprod

// pour tout activer / désactiver : 

drush @alias deprod -y

// ou

drush @alias reprod -y

Ce script pour l'instant fonctionne plus avec Drupal 7, je vais l'améliorer pour qu'il puisse interagir correctement avec Drupal 8.

Je suis prenneur de toute suggestion ou idée d'amélioration.

Par Kgaut
Adhérent
Kevin Gautreau

Module Drupal 7 : CKEditor Responsive Plugin

Mon premier module drupal officiellement publié sur drupal.org !

Il s'agit du module CKEditor Responsive Plugin, qui comme son nom l'indique est un plugin pour CKEditor qui permet d'insérer des zones responsives dans une zone WYSIWYG.

Le module injecte en fait du markup HTML qui ressemble à ça :

<div class="ckeditor-col-container clearfix">
  <div class="grid-6 sixcol first-col"><p>lorem ipsum</p></div>
  <div class="grid-6 sixcol last-col"><p>lorem ipsum</p></div>
</div>

Ce qui permet à des néophytes de facilement mettre en place des architectures de contenu avancées sans passer par des tableaux, et sans avoir de templates pré-définis (comme avec paragraphs par exemple).

Le module est disponible sur sa page drupal à l'adresse suivante : https://www.drupal.org/project/ckeditor_responsive_plugin

Vous pouvez proposer des améliorations ou des idées soit en créant un ticket sur la page du module du site drupal.org ou bien encore sur github : https://github.com/kgaut/drupal-ckeditor-responsive-plugin

Le module est pour l'instant uniquement pour Drupal 7, mais je compte le porter sur Drupal 8 rapidement.

Par Kgaut
Adhérent
Kevin Gautreau

Drupal 8 - Utiliser la Batch API dans un controller

La batch API dans Drupal permet de faire des traitements lourds et/ou long, sans risque d'avoir un temps d’exécution dépassé de la part de son serveur.

Ici, dans le cadre de mon site de pronostics, je voulais faire un traitement permettant de recalculer les points sur l'ensemble des matchs d'une compétitions.

J'ai donc une route définie qui appelle la méthode statique "updateBetsForLeague" de mon controller.

Fonction de qui prépare le batch à traiter :

  public static function updateBetsForLeague(League $league) {
    $games = $league->getGames(); //Je récupère l'ensemble des matchs à traiter
    //Définition du batch
    $batch = [
      'title' => t('Recount League Points'), // Titre de l'opération
      'operations' => [], // tableaux qui contiendra l'ensemble des traitements à effectuer
      'finished' => '\Drupal\mespronos\Controller\BetController::updateBetsForLeagueOver', // méthode qui sera appelé à la fin du traitement 
    ];
    //Définition des opérations 
    // Pour chaque match ($game) on appelle la méthode "updateBetsFromGame" et on lui passe en paramètre le match en question
    foreach ($games as $game) {
      $batch['operations'][] = ['\Drupal\mespronos\Controller\BetController::updateBetsFromGame',[$game]];
    }
    // on paramètre le batch
    batch_set($batch);
    //et on le lance (en lui passant une url de redirection pour la fin du traitement, ici la liste des compétitions
    return batch_process(\Drupal::url('entity.league.collection'));
  }

 

Voici la méthode statique appelée à la fin du batch

  public static function updateBetsForLeagueOver($success, $results, $operations) {
    if ($success) {
      $message = t('Ranking recalculated');
    }
    else {
      $message = t('Finished with an error.');
    }
    drupal_set_message($message);
    return new RedirectResponse(\Drupal::url('entity.league.collection'));
  }

Rien de bien compliqué donc, un seul piège dans lequel je suis tombé, lorsque l'on définie une opération, il faut bien donner le namespace complet de la classe, en effet $batch['operations'][] = ['BetController::updateBetsFromGame',[$game]]; ne fonctionnera pas, mais ne retournera même pas d'erreur...

Par Kgaut
Adhérent
Kevin Gautreau

Drupal 8 & Composer - Appliquer un patch dans le fichier composer.json

Si vous utilisez composer pour gérer votre instance de Drupal 8, vous avez parfois besoin d'appliquer un patch (de votre conception ou depuis drupal.org) que ce soit pour un module tiers ou pour le core.

Si on est "à l'ancienne" on a le core et les module sous gestionnaire de version (git par exemple), cela reste simple, vous appliquez le patch et commitez le tout.

En utilisant composer, nous avons uniquement le "cutom" qui est versionné, avec les fichiers composer.json et composer.lock qui contiennent la liste des modules utilisés et leurs version spécifique. Donc pas possible d'appliquer un patch comme plus haut.

Par contre on peut à l'aide d'un dépendance spécifier les patchs que l'on veut utiliser directement dans le fichier composer.json, regardez si ça ce trouve le module est déjà installé; il s'agit de cweagans/composer-patches.

s'il n'est pas présent : 

composer require cweagans/composer-patches

ensuite pour appliquer un patch, on doit ajouter les éléments suivants dans la partie "extra" du fichier composer.json :

"patches": {
  "package": {
    "description libre": "Url du patch"
  }
}

exemple pour un patch pour mimemail :

"patches": {
  "drupal/mimemail": {
    "Fix mimemail error on admin form": "https://www.drupal.org/files/issues/mime-mail-error-message-on-admin-form-with-webprorfiler-2719981-3.patch"
  }
}

si vous avez plusieurs patchs pour un même module, séparez-les par une virgule :

"patches": {
  "drupal/mimemail": {
    "Fix mimemail error on admin form": "https://www.drupal.org/files/issues/mime-mail-error-message-on-admin-form-with-webprorfiler-2719981-3.patch",
    "patch 2": "https://www.drupal.org/files/issues/mime-mail-error-message-on-admin-form-with-webprorfiler-2719981-3qdqsdqsd.patch"
  },
  "drupal/monautremodule": {
    "ma description du patch": "https://www.drupal.org/files/issues/mimhfhmin-form-with-webprorfiler-2719981-3.patch",
  }
}

si vous avez plusieurs modules à patcher, même principe :

"patches": {
  "drupal/mimemail": {
    "Fix mimemail error on admin form": "https://www.drupal.org/files/issues/mime-mail-error-message-on-admin-form-with-webprorfiler-2719981-3.patch",
    "patch 2": "https://www.drupal.org/files/issues/mime-mail-error-message-on-admin-form-with-webprorfiler-2719981-3qdqsdqsd.patch"
  }
}

enfin update et install pour que le(s) modules patchés soient supprimés, re-téléchargés et enfin patchés.

composer update
composer install

 

Par Kgaut
Adhérent
Kevin Gautreau

Première alpha de mon module de pronostics sous drupal 8 : MesPronos

Je travaille depuis quelques années sur un module de pronostics (à un rythme loin d'être soutenu comme tout bon side-project). Il a connu un début de version en Drupal 7, puis en Ruby on Rails, puis sur Symfony, puis enfin sur Drupal 8, il m'a permis de tester Drupal 8 à l'aube des premières versions alpha.

Entièrement open-source, le module est hébergé sur Github : https://github.com/mespronos/mespronos.

Depuis ce week-end, j'ai mis en production le module sur le site https://mespronos.net/ afin de pouvoir le tester en conditions réelles et récupérer suffisamment de données afin de continuer à travailler sur les templates et fonctionnalités à venir (classements...). Pour l'instant les pronostics sont possible sur la ligue 1 Française et le tournois des VI nations.

N'hésitez-pas à tester et me donner vos retours, tout en gardant à l'esprit que c'est une version alpha, et que le thème n'est pour l'instant pas du tout travailler (c'est celui de base de Drupal 8).

Pour suivre l'avancement, vous pouvez-vous rendre sur la page facebook dédiée : https://www.facebook.com/mespronos/.

 

Par Kgaut
Adhérent
Kevin Gautreau

Drupal 8 - Prise en main de Drupal Console, installation et configuration

Drupal 8 est là est avec lui de nombreux outils commencent à arriver, parmi eux : Drupal Console, qui est vise à intégrer l'outil console de Symfony avec Drupal.

La console ne remplace pas (encore?) drush, mais propose un paquet de fonction permettant par exemple de générer des modules, des blocs, des entités, des types de contenus...

Le développement autour de cet outil est très actif et vous pouvez suivre ou participer à son développement sur la page Github du projet : https://github.com/hechoendrupal/DrupalConsole.

Installation de Drupal Console

Pour l'instant la Drupal Console ne fonctionne pas sous les système windows. Sous linux et Mac Os voila comment l'installer (à lancer dans un terminal)

# Téléchargement de l'outil
curl https://drupalconsole.com/installer -L -o drupal.phar

# On le déplace dans un dossier de binaires afin de pouvoir 
# le lancer depuis n'importe où 
# (à noter : on exécute la commande en tant qu'administrateur)
sudo mv drupal.phar /usr/local/bin/drupal

# Attention, c'est la ligne suivante qui défini le nom de la 
# commande que l'on utilisera : "drupal" par défaut
# Si vous souhaitez un autre nom, comme par exemple 
# "drupal-console", lancez à la place :
# sudo mv drupal.phar /usr/local/bin/drupal-console

# On le rend exécutable : 
# (à noter : on exécute aussi la commande en tant qu'administrateur)
sudo chmod +x /usr/local/bin/drupal

Pour vérifier que l'outil est bien disponible, lancez la commande "drupal" depuis un terminal, et vous devriez avoir quelque chose comme ça :

Configuration initiale

Via la commande

drupal init

Drupal console va stocker dans votre répertoire personnel des informations de configuration.

Cette partie n'est absolument pas obligatoire, mais elle vous permettra de modifier un peu son comportement, de passer l'outil en Français par exemple, mais aussi d'avoir de l'auto-complétion.

Dans mon cas la configuration se trouvera dans le fichier /home/kgaut/.console/config.yml dont voici le contenu :

application:
  environment: 'prod'
  language: en
  editor: vim
  temp: /tmp
  remote:
    user: root
    port: 22
    console: /usr/local/bin/drupal
    options: --ansi
    arguments:
    keys:
      public: ~/.ssh/id_rsa.pub
      private: ~/.ssh/id_rsa
      passphrase: ~/.ssh/passphrase.txt
  disable:
    modules:
#      - module_name
#      - module_name
  default:
    commands:
      generate:
        controller:
          options:
#            module: module_name

Si vous souhaitez passer l'outil en Français, changez la ligne 3 de

  language: en

à

  language: fr

Si vous souhaitez bénéficier de l'auto-complétion suivez les retours de la commande et en fonction de votre interpréteur de terminal :

Bash or Zsh: Ajouter la ligne suivante à votre fichier .bashrc ou .zshrc :

source "$HOME/.console/console.rc" 2>/dev/null

Fish: Créez un lien symbolique

ln -s ~/.console/drupal.fish ~/.config/fish/completions/drupal.fish

La configuration est terminée, bravo vous allez pouvoir passer aux choses sérieuses !

Drupal Console & Drupal 8

L'objectif de Drupal Console est donc d’interagir avec un site / une application sous Drupal 8. Dans un terminal, déplacez-vous dans le dossier contenant votre instance du CMS.

Si vous n'avez pas encore installé de site Drupal, vous pouvez utiliser composer comme indiqué dans ce post.

À noter vous devrez être dans le dossier contenant les sources de drupal (exemple le dossier "Web" si vous avez installé Drupal via composer)

Maintenant si vous relancer la commande "drupal" vous devriez avoir un résultat un peu différent :

Pour voir la liste des commandes disponibles avec une explication lancez :

drupal list

Vous vous rendrez rapidement compte que la traduction en Français est loin d'être complète, n'hésitez-pas à participer sur la page du projet.

Génération d'un module

Le mieux étant d’expérimenter, essayez de générer un module :

la commande est drupal generate:module, mais vous pouvez aussi jouer avec l'auto-complétion :

Lancez la commande et laissez-vous guider :

drupal generate:module  

 // Bienvenue sur le générateur de modules Drupal

 Entrez le nom du nouveau module:
 > Mon Module

 Entrez le nom de la machine du module [mon_module]:
 > 

 Entrez le chemin du module [/modules/custom]:
 > 

 Entrez la description du module [My Awesome Module]:
 > Mon super module de test 

 Entrez le nom du paquet [Other]:
 > Kgaut

 Entrez la version core Drupal [8.x]:
 > 

 Définir le module comme une fonctionnalité <em>feature</em> (yes/no) [no]:
 > no

 Voulez-vous ajouter un fichier composer.json file à votre module (yes/no) [yes]:
 > yes

 Voulez-vous ajouter des dépendances à votre module (yes/no) [no]:
 > no


 Confirmez-vous la génération (yes/no) [yes]:
 > yes

Fichiers générés ou mis à jour
 Chemin du site: /media/vhosts/drupal8-test.dev/web
 1 - modules/custom/mon_module/mon_module.info.yml
 2 - modules/custom/mon_module/mon_module.module
 3 - modules/custom/mon_module/composer.json

Et maintenant vous verrez effectivement le module généré dans votre dossier modules/custom/ :

Les modules ne sont pas les seules choses que vous puissiez générer à l'aide de Drupal Console : Types de contenu, Thèmes, Type d'entités...

Vous pouvez aussi générer du contenu factice pour populer vos types de contenus ou vocabulaires.

Mise à jour de Drupal Console

Le développement de Drupal Console est très actif, pour mettre à jour l'outil lancez la commande :

sudo drupal self-update

 

Par Kgaut
Adhérent
Kevin Gautreau

Générateur de squelette de site Drupal 7

J'ai mis sur github un scaffolder de site drupal 7.

En une commande, cela télécharge la dernière version de Drupal 7 ainsi qu'une liste de module (qualifié subjectivement par moi-même comme indispensables).

L'ensemble du core et des modules sont gérés par composer, le gestionnaire de dépendances PHP.

Le fichier .gitignore est personnalisé afin de ne pas versionner le core et les modules mais que les thèmes et modules customs le soient.

Un script bash est exécuté à la fin pour copier le fichier default.settings.php en settings.php, créer les dossiers files et tmp...

C'est un peu une preuve de concept que j'aimerai utiliser sur mes prochains projets Drupal 7 et qui évoluera donc surement.

Si c'est concluant une version Drupal 8 viendra aussi.

Je suis preneur d'idées et de retours, n'hésitez-pas à ouvrir des issues ou faire des push requests sur la page github du projet.

Plus d'informations et comment s'en servir sur le readme de la page github du projet :

https://github.com/kgaut/drupal-site-scaffolder

 

Par Kgaut
Adhérent
Kevin Gautreau

Installer Drupal 8 avec composer

Il est maintenant possible de gérer son installation de Drupal directement avec composer, installation, ajout de module, update...

Prérequis

Pour cela évidement, il faut avoir composer d'installé, sous Debian/Ubuntu :

curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer

Il aussi est nécessaire d'avoir l'extension php CURL, toujours sous Debian et dérivés installez-la avec :

sudo apt-get install php5-curl

Téléchargement

Placez-vous dans le dossier où vous souhaitez installer drupal 8 (il doit être vide) et lancez la commande suivante :

composer create-project drupal-composer/drupal-project:8.x-dev ./ --stability dev -vv 

Il se peut que vous obteniez un message de ce genre :

Could not fetch *************, please create a GitHub OAuth token to go over the API rate limit
Head to https://github.com/settings/tokens/new?scopes=repo&description=****************
to retrieve a token. It will be stored in "/home/********/.composer/auth.json" for future use by Composer.

C'est une protection mise en place par github pour éviter de se faire aspirer trop de contenu, il faut que vous généreriez un jeton chez eux, pour cela rendez-vous à l'adresse donnée et cliquez sur generate token :

Votre jeton se trouve à la page suivante :

Copiez-collez-le dans le terminal et faite Enter.

L'installation devrait se terminer correctement.

Structure

Votre dossier devrait maintenant ressembler à ça :

La racine de votre site est le dossier web, c'est sur lui que devra pointer votre virtual host.

Si vous allez dans le dossier web/sites/default vous vous rendrez compte que composer à déjà préparer l'installation du site avec le dossier files et les fichiers services.yml et settings.php, vous n'avez alors plus qu'a lancer votre navigateur sur l'adresse de votre virtual host afin de commencer l'installation de drupal en tant que tel.

Installation de modules contrib

Si vous souhaitez ajouter un module tiers, vous pouvez le faire, toujours avec composer via la commande suivante :

#téléchargement du module devel
composer require drupal/devel:8.*

#téléchargement du module token
composer require drupal/token:8.*

#téléchargement du module examples
composer require drupal/examples:8.*

Versionning et déploiment

Si vous observez le contenu du fichier .gitignore, vous verez qu'il demande à ne pas versionner les dossiers du core de drupal, les dépendances tierces ainsi que les modules contrib :

# Ignore directories generated by Composer
drush/contrib
vendor
web/core
web/modules/contrib
web/themes/contrib
web/profiles/contrib

# Ignore Drupal's file directory
web/sites/default/files

# Ignore files generated by PhpStorm
.idea

Pourquoi ? Car toutes la gestion de dépendance passe maintenant par composer et il n'y a donc aucun intérêt à stocker sous git ces éléments tiers. Le fichier composer.lock contient l'ensemble des dépendances avec la version précise nécessaire pour votre application.

Si vous clonez votre dépôt depuis un autre poste, il suffira de faire un composer install pour récupérer l'ensemble des dépendances dans leurs bonnes versions. Pareil pour le déploiement en prod qui doit ressembler à peu de chose prêt à ça :

#Récupération des dernières modifications
git pull origin master

#Téléchargement des éventuelles nouveaux modules ou encore mises à jours
composer install

#Reconstruction du cache (équivalent de cache-clear sous drupal 7)
drush cache-rebuild

#Migration de la base de données
drush update-db

Mise à jour core et modules

Pour mettre à jour le core et les modules, toujours avec composer :

composer update

Si vous vous rendez-compte que quelque chose c'est mal passé, faite un revert sur le fichier composer.lock puis composer install pour retourner dans l'état précédent.

 

Plus d'informations sur la page github de drupal-composer : https://github.com/drupal-composer/drupal-project.

Par Kgaut
Adhérent
Kevin Gautreau

Drupal 8 version finale disponible

Après quelques années de gestations, Drupal 8 est depuis aujourd'hui disponible en version stable (8.0.0 pour être exact.)

C'est une nouvelle version majeur, une mise à jour de votre site en Drupal 7 ne sera pas forcément aisé. Avant de migrer il faudra attendre que les modules tiers que vous utilisez soient portés en version 8 et si vous avez des modules customs, il faudra certainement les réécrire en grande partie.

Au niveau administration, une grosse refonte de l'interface utilisateur à été faite, des modules quasiment indispensables en dans drupal 7 sont maintenant dans le cœur de Drupal 8 (Views, CKeditor...) La gestion des langues est grandement améliorée.

Au niveau du code, Drupal 8 intègre maintenant des briques venant de Symfony 2, il nécessite au minimum PHP 5.5 et est compatible avec PHP7.

Beaucoup de modules restent encore à porter, mais la communauté a beaucoup travaillé pour que la transition soit plus rapide que celle en 2011 entre Drupal 6 et Drupal 7.

Pour le tester, je vous invite à soit le télécharger directement depuis cette page ou bien à utiliser composer via à l'aide de drupal-composer (https://github.com/drupal-composer/drupal-project.)

Si vous avez envie de jouer et d'apprendre le développement de module avec Drupal 8 je vous invite à tester Drupal Console (ceux qui ont déjà utilisé la console de Symfony ne seront pas perdu) qui permet depuis un terminal de générer des modules, des types d’entité, des types de contenu, des blocs...

À noter enfin, pas d'inquiétudes pour vos sites sur Drupal 7 au niveau de la sécurité, la communauté Drupal maintient toujours 2 versions en parallèle, donc le support de Drupal 7 sera toujours assuré jusqu'à la sortie de Drupal 9, nous avons donc quelques années devant nous...

Tags: 

Par Kgaut
Adhérent
Kevin Gautreau

À la découverte de Drupal 8 - #4 - Kint, ou le var_dump sous stéroides !

Si vous êtes développeur Drupal 7, vous connaissez certainement la librairie Krumo, qui permet d'afficher le contenu d'une variable de manière beaucoup plus pratique que le traditionnel var_dump, cette fonction n'étant pas native, mais fournie par le module Devel.

[scald=18:sdl_editor_representation]

Rendu de Krumo

La librairie krumo n'étant plus maintenue, il a été proposé de la remplacer pour Drupal 8 par Kint.

Kint fonctionne de la même manière que krumo, mais propose de nouvelles fonctionnalitées bien utiles.

Il est toujours compris dans le module devel, au sein du sous-module "kint".

Une fois le module activé, on appelle la fonction en lui passant en paramètre la variable dont on veut afficher le contenu :

kint($form);

Voici ce que cela donne :

[scald=19:sdl_editor_representation]

Et c'est pas fini! kint propose aussi la documentation des objets instanciés que l'on croise ainsi que leurs méthodes :

[scald=20:sdl_editor_representation]

Bref, un outil bien utile pour le développement !

Tags: 

Par Kgaut
Adhérent
Kevin Gautreau

À la découverte de Drupal 8 - #4 - Kint, ou le var_dump sous stéroides !

Si vous êtes développeur Drupal 7, vous connaissez certainement la librairie Krumo, qui permet d'afficher le contenu d'une variable de manière beaucoup plus pratique que le traditionnel var_dump, cette fonction n'étant pas native, mais fournie par le module Devel.

Rendu de Krumo

Rendu de Krumo

La librairie krumo n'étant plus maintenue, il a été proposé de la remplacer pour Drupal 8 par Kint.

Kint fonctionne de la même manière que krumo, mais propose de nouvelles fonctionnalitées bien utiles.

Il est toujours compris dans le module devel, au sein du sous-module "kint".

Une fois le module activé, on appelle la fonction en lui passant en paramètre la variable dont on veut afficher le contenu :

kint($form);

Voici ce que cela donne :

Rendu de kint

Et c'est pas fini! kint propose aussi la documentation des objets instanciés que l'on croise ainsi que leurs méthodes :

Affichage d'informations sur l'objet

Bref, un outil bien utile pour le développement !

Tags: 

Par Kgaut
Adhérent
Kevin Gautreau

À la découverte de Drupal 8 - #3 - Populer une entitée lors de l'installation

Le HOOK_install existe encore dans drupal 8, et il est donc possible d'en profiter pour populer automatiquement notre type d'entité lorsque l'on install le module qui la contient.

Toujours dans mon projet de site de pronostics, j'ai un type d'entité "Sport" qui contiendra l'ensemble des sports qui pourront caractériser une compétition.

Sachant que ces sports ne varient pas vraiment, je peux les créer dès l'installation.

Pour cela dans mon module mespronos_sports, je crée un fichier mespronos_sports.install avec à l'intérieur :

function mespronos_sports_install() {
  $entity = entity_create('sport', array(
    'created' => time(),
    'changed' => time(),
    'user_id' => 1,
    'name' => 'Football'
  ));
  $entity->save();

  $entity = entity_create('sport', array(
    'created' => time(),
    'changed' => time(),
    'user_id' => 1,
    'name' => 'Rugby'
  ));
  $entity->save();
}

On donne le nom du type d'entité que l'on veut créer et ensuite on passe un tableau avec l'ensemble des attributs de l'entité que l'on veut créer.

Et une fois le module installé :

[scald=17:sdl_editor_representation]

Les sports sont créés !

Ainsi, plus besoin à chaque réinstallation de module, de re-créer les contenu, ce qui peut rapidement devenir long en cours de développement.

L'ensemble du code de mes modules est sur Github : https://github.com/kgaut/mespronos, le module ici en question est directement accessible là : https://github.com/kgaut/mespronos/tree/master/mespronos/custom/mesprono....

Résumé des épisodes précédents :

Tags: 

Par Kgaut
Adhérent
Kevin Gautreau

À la découverte de Drupal 8 - #3 - Populer une entitée lors de l'installation

Le HOOK_install existe encore dans drupal 8, et il est donc possible d'en profiter pour populer automatiquement notre type d'entité lorsque l'on install le module qui la contient.

Toujours dans mon projet de site de pronostics, j'ai un type d'entité "Sport" qui contiendra l'ensemble des sports qui pourront caractériser une compétition.

Sachant que ces sports ne varient pas vraiment, je peux les créer dès l'installation.

Pour cela dans mon module mespronos_sports, je crée un fichier mespronos_sports.install avec à l'intérieur :

function mespronos_sports_install() {
  $entity = entity_create('sport', array(
    'created' => time(),
    'changed' => time(),
    'user_id' => 1,
    'name' => 'Football'
  ));
  $entity->save();

  $entity = entity_create('sport', array(
    'created' => time(),
    'changed' => time(),
    'user_id' => 1,
    'name' => 'Rugby'
  ));
  $entity->save();
}

On donne le nom du type d'entité que l'on veut créer et ensuite on passe un tableau avec l'ensemble des attributs de l'entité que l'on veut créer.

Et une fois le module installé :

Les sports sont créés !

Les sports sont créés !

Ainsi, plus besoin à chaque réinstallation de module, de re-créer les contenu, ce qui peut rapidement devenir long en cours de développement.

L'ensemble du code de mes modules est sur Github : https://github.com/kgaut/mespronos, le module ici en question est directement accessible là : https://github.com/kgaut/mespronos/tree/master/mespronos/custom/mesprono....

Résumé des épisodes précédents :

Tags: 

Par Kgaut
Adhérent
Kevin Gautreau

À la découverte de Drupal 8 - #2 : Création d'une entité avec fields

Suite de l'episode 1 : À la découverte de drupal 8 - #1 : Ma première entité

Aujourd'hui, nous continuons notre découverte de Drupal 8. Le but du jeu aujourd'hui est de créer une entité avec un champ personnalisé qui sera créé automatiquement lors de l'installation, via une grande nouveauté de Drupal 8, la gestion de la configuration.

Je continue mon site de pronostics pour l'occasion, c'est que l'euro 2016 arrive à grands pas ! Après l'entité League de l'épisode 1, nous allons cette fois gérer les équipes.Pourquoi je définie une équipe comme une entité et non pas un type de contenu ? Bonne question, pas vraiment de bonne réponse, c'est surtout car j'ai envie de jouer avec les entités !

Alors, comment est structurée une équipe ?

  • Id => La clé primaire
  • name => Le nom de l'équipe
  • logo => Le logo du club

Rien de bien compliqué pour les deux premiers attributs, ce seront des propriétés de base de mon entité. Le logo sera quand à lui un field, semblable à celui que l'on peut créer via l'interface d'administration, dans un type de contenu.

Création de l'entité

Comme dans l'épisode précédent, on va utiliser Console pour générer le module et l'entité.

On commence d'abord par vérifier s'il n'y a pas de mise à jours pour Console, on utilise pour ça composer. Via un terminal, à la racine de l'installation de Drupal :

composer update drupal/console
[scald=12:sdl_editor_representation]

Mise à jour de console via composer

On génère maintenant le module mespronos_teams qui contiendra l'entité

bin/console generate:module
  • Nom du module : Mespronos Teams
  • Nom machine : mespronos_teams
  • Description : Gestion des équipes
  • Pas de contrôleur (on verra ça plus tard)

On génère maintenant l'entité

bin/console generate:entity:content
  • Nom de l'entité : Team
  • Nom machine : team

On active le module via l'administration.

[scald=13:sdl_editor_representation]

Activation du module

Création du Champs

On peut maintenant ajouter des champs à notre entité via la field API (anciennement CCK dans Drupal 6, et dans le core depuis Drupal 7)

Via Gérer > Structure > Team Settings > Gérér les champs on créer un champ de type « image » dont le nom machine sera field_logo.

[scald=14:sdl_editor_representation]

Field logo dans l'administration

La configuration (CMI en action)

C'est super, on peut maintenant créer des équipes et leur affecter un logo. Par contre le soucis ici, c'est que si jamais je désactive mon module, je perds le champs que je viens de créer. Aussi, je ne peux pas en versionner la configuration, si jamais je viens la modifier plus tard. Mais heureusement pour nous l'initiative CMI « Configuration Management Initiative » a pensé à nous dans Drupal 8.

L'objectif de cette initiative est donc de pouvoir exporter toute la partie « configuration » de Drupal dans des fichiers YAML.

Via le fichier settings.php, on peut définir là où l'on veut stocker l'ensemble des fichiers YAML qui contiendront la configuration de drupal. Par défaut c'est dans un dossier dont le nom est généré aléatoirement dans le dossier /sites/monsites. Personnellement je préfère que ces éléments ne soient pas accessible sur internet, même si normalement le risque est minime. Pour cela à la fin du fichier settings.php je dé-commente et modifie les lignes suivantes :

$config_directories['active'] = '../config/active';
$config_directories['staging'] = '../config/staging';

On peut exporter d'un coup l'ensemble de la configuration de notre site via drush avec la commande config-export :

drush @monsite config-export

[scald=15:sdl_editor_representation]

Fichiers de configuration

Revenons à nos moutons, nous allons donc chercher la configuration de notre field et l'intégré à notre module. Afin que lors de l'installation du module, le field soit automatiquement créé. La configuration du champs est répartie dans deux champs :

field.field.team.team.field_logo.yml
field.storage.team.field_logo.yml

Pour que ces fichiers soient pris en compte lors de l'installation il faut les placer dans un dossier config/install dans notre module :

[scald=16:sdl_editor_representation]

Structure du module

On test en désinstallant notre module et le réinstallant, c'est ok, notre champs existe !

[scald=14:sdl_editor_representation]
Youpi Youhou !

C'est fini pour aujourd'hui, comme la dernière fois vous pouvez trouver l'ensemble de mes modules sur github à l'adresse suivante : https://github.com/kgaut/mespronos

N'hésitez-pas si vous avez des remarques ou des questions !

Tags: 

Par Kgaut
Adhérent
Kevin Gautreau

À la découverte de Drupal 8 - #2 : Création d'une entité avec fields

Suite de l'episode 1 : À la découverte de drupal 8 - #1 : Ma première entité

Aujourd'hui, nous continuons notre découverte de Drupal 8. Le but du jeu aujourd'hui est de créer une entité avec un champ personnalisé qui sera créé automatiquement lors de l'installation, via une grande nouveauté de Drupal 8, la gestion de la configuration.

Je continue mon site de pronostics pour l'occasion, c'est que l'euro 2016 arrive à grands pas ! Après l'entité League de l'épisode 1, nous allons cette fois gérer les équipes.Pourquoi je définie une équipe comme une entité et non pas un type de contenu ? Bonne question, pas vraiment de bonne réponse, c'est surtout car j'ai envie de jouer avec les entités !

Alors, comment est structurée une équipe ?

  • Id => La clé primaire
  • name => Le nom de l'équipe
  • logo => Le logo du club

Rien de bien compliqué pour les deux premiers attributs, ce seront des propriétés de base de mon entité. Le logo sera quand à lui un field, semblable à celui que l'on peut créer via l'interface d'administration, dans un type de contenu.

Création de l'entité

Comme dans l'épisode précédent, on va utiliser Console pour générer le module et l'entité.

On commence d'abord par vérifier s'il n'y a pas de mise à jours pour Console, on utilise pour ça composer. Via un terminal, à la racine de l'installation de Drupal :

composer update drupal/console
Mise à jour de console via composer

Mise à jour de console via composer

On génère maintenant le module mespronos_teams qui contiendra l'entité

bin/console generate:module
  • Nom du module : Mespronos Teams
  • Nom machine : mespronos_teams
  • Description : Gestion des équipes
  • Pas de contrôleur (on verra ça plus tard)

On génère maintenant l'entité

bin/console generate:entity:content
  • Nom de l'entité : Team
  • Nom machine : team

On active le module via l'administration.

Activation du module

Activation du module

Création du Champs

On peut maintenant ajouter des champs à notre entité via la field API (anciennement CCK dans Drupal 6, et dans le core depuis Drupal 7)

Via Gérer > Structure > Team Settings > Gérér les champs on créer un champ de type « image » dont le nom machine sera field_logo.

Field logo dans l'administration

Field logo dans l'administration

La configuration (CMI en action)

C'est super, on peut maintenant créer des équipes et leur affecter un logo. Par contre le soucis ici, c'est que si jamais je désactive mon module, je perds le champs que je viens de créer. Aussi, je ne peux pas en versionner la configuration, si jamais je viens la modifier plus tard. Mais heureusement pour nous l'initiative CMI « Configuration Management Initiative » a pensé à nous dans Drupal 8.

L'objectif de cette initiative est donc de pouvoir exporter toute la partie « configuration » de Drupal dans des fichiers YAML.

Via le fichier settings.php, on peut définir là où l'on veut stocker l'ensemble des fichiers YAML qui contiendront la configuration de drupal. Par défaut c'est dans un dossier dont le nom est généré aléatoirement dans le dossier /sites/monsites. Personnellement je préfère que ces éléments ne soient pas accessible sur internet, même si normalement le risque est minime. Pour cela à la fin du fichier settings.php je dé-commente et modifie les lignes suivantes :

$config_directories['active'] = '../config/active';
$config_directories['staging'] = '../config/staging';

On peut exporter d'un coup l'ensemble de la configuration de notre site via drush avec la commande config-export :

drush @monsite config-export

Fichiers de configuration

Fichiers de configuration

Revenons à nos moutons, nous allons donc chercher la configuration de notre field et l'intégré à notre module. Afin que lors de l'installation du module, le field soit automatiquement créé. La configuration du champs est répartie dans deux champs :

field.field.team.team.field_logo.yml
field.storage.team.field_logo.yml

Pour que ces fichiers soient pris en compte lors de l'installation il faut les placer dans un dossier config/install dans notre module :

Structure du module

Structure du module

On test en désinstallant notre module et le réinstallant, c'est ok, notre champs existe !

Field logo dans l'administration
Youpi Youhou !

C'est fini pour aujourd'hui, comme la dernière fois vous pouvez trouver l'ensemble de mes modules sur github à l'adresse suivante : https://github.com/kgaut/mespronos

N'hésitez-pas si vous avez des remarques ou des questions !

Tags: 

Par Kgaut
Adhérent
Kevin Gautreau

Installer drush sous linux via composer

Drush est un outil indispensable pour développer sous drupal, il permet de contrôler son instance de site via le terminal pour les taches quotidiennes sur un site : téléchargement, activation de modules, vidage de cache, mise à jours de modules ou du core... Une fois que l'on y a goûté, on ne peut plus s'en passer.

Il existe un tas de méthode pour installer drush et il est parfois difficile de s'y retrouver : via les dépôts, PEAR, installation manuelle... Mais maintenant le moyen de plus simple est d'utiliser composer.

Si vous n'avez pas composer d'installé :

curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer

Ensuite on peut installer Drush :

Pour la version 6 (compatible avec drupal 6 et 7) :

composer global require drush/drush:6.*

Pour la version 7-dev (compatible avec drupal 6, 7 et 8, mais en cours de développement) :

composer global require drush/drush:dev-master

Personnellement j'utilise la version 7 de drush (vu que je commence à faire mumuse avec la version 8 de drupal)

Quelques liens sur drush que je vous conseille :

Tags: 

Par Kgaut
Adhérent
Kevin Gautreau

Installer drush sous linux via composer

Drush est un outil indispensable pour développer sous drupal, il permet de contrôler son instance de site via le terminal pour les taches quotidiennes sur un site : téléchargement, activation de modules, vidage de cache, mise à jours de modules ou du core... Une fois que l'on y a goûté, on ne peut plus s'en passer.

Il existe un tas de méthode pour installer drush et il est parfois difficile de s'y retrouver : via les dépôts, PEAR, installation manuelle... Mais maintenant le moyen de plus simple est d'utiliser composer.

Si vous n'avez pas composer d'installé :

curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer

Ensuite on peut installer Drush :

Pour la version 6 (compatible avec drupal 6 et 7) :

composer global require drush/drush:6.*

Pour la version 7-dev (compatible avec drupal 6, 7 et 8, mais en cours de développement) :

composer global require drush/drush:dev-master

Personnellement j'utilise la version 7 de drush (vu que je commence à faire mumuse avec la version 8 de drupal)

Quelques liens sur drush que je vous conseille :

Tags: 

Par Kgaut
Adhérent
Kevin Gautreau

À la découverte de drupal 8 - #1 : Ma première entité

Ayant l'envie de tester Drupal 8, sans prendre trop de risques, je me suis décidé à prendre comme prétexte la création d'un site de pronostics pour l'euro 2016 (oui je m'y prends tôt).

Un petit coup de modélisation de mon schéma de données, et hop c'est parti.

Pour info, je vais tenter de faire plusieurs notes comme celle là, et autant en faire profiter tout le monde, mon code sera sur Github, au fur et à mesure, car cela évitera d'avoir des posts de 4km de long, l'adresse du projet sur Github : https://github.com/kgaut/mespronos

Le contexte

Installation du Drupal, je suis parti sur la beta 2.

Petites modifications dans le fichier settings.php pour sortir les dossiers de configurations de Drupal en dehors du docroot (donc non accessible via le web) :

$config_directories['active'] = '../config/active';
$config_directories['staging'] = '../config/staging';

Ensuite on rentre dans le vif du sujet avec la création de ma première entité drupal 8.

Je vous présente l'entité "League" qui contiendra les différentes compétitions de sport sur lesquelles des concours de pronostics seront organisés.

  • lid : Clé primaire
  • name : le nom de la compétition. Ex : "Ligue 1 2014-2015"
  • classement : doit-on calculer le classement pour ce concours ? (oui pour un championnat, non pour un mondial ou un euro)
  • status : archivé, en cours, terminé...

Mon entité sera contenue dans un module qui s’appellera "mespronos_leagues", car j'aime bien avoir un module par fonctionnalité.

Let's generate !

Pour la génération du module ainsi que de l'entité j'ai utilisé le super projet "console", que j'ai installé via composer. Je vous invite à découvrir l'installation et l'utilisation de ce module via ce tutoriel à l'adresse suivante : Créer un module Drupal 8 en 30 secondes | Flocon de toile.

J'ai donc crée mon module à l'aide de la commande suivantes

bin/console generate:module

une fois le module généré, il est temps de créer l'entité, toujours avec console, via la commande suivante : 

bin/console generate:entity:content

et là c'est magique, le contrôleur, les routes, l'entité, l'arborescence des dossiers... tout est généré automatiquement :

Encore une fois, sur la génération d'entités, tout est encore superbement expliqué sur ce site : Créer une entité Drupal 8 en 10 secondes top chrono | Flocon de toile

[scald=9:sdl_editor_representation]
 

il ne reste plus qu'à personnaliser selon nos besoins.

Ajout de propriétés

Une entité est "fieldable" c'est à dire que l'on peut très bien lui ajouter des champs via l'interface d'administration, comme l'on ferai avec un type de contenu. Mais comme vous le savez sûrement l'ajout d'un champ entraîne la création de deux tables (une pour la valeur, et une pour les révisions) ainsi une baisse de performance lors de l'affichage de notre contenu car cela génère forcement des jointures.

Une autre possibilité offerte par les entités est de définir des propriétés, c'est à dire des attributs qui seront présents directement dans la même table que notre entité.

Il faut pour cela modifier la méthode baseFieldDefinitions de notre entité (dans le fichier src/Entity/League.php)

Voici un exemple de code pour ajouter mon attribut "classement", qui est un booléen non affiché en front, mais présent sur le formulaire d'administration.

$fields['classement'] = BaseFieldDefinition::create('boolean')
  ->setLabel(t('Classement activé'))
  ->setDescription(t('Doit-on calculer le classement entre les équipes pour cette competitions'))
  ->setDisplayConfigurable('form', TRUE)
  ->setDisplayConfigurable('view', TRUE)
  ->setDefaultValue(TRUE)
  ->setDisplayOptions('form', array(
    'type' => 'boolean_checkbox',
    'settings' => array(
      'display_label' => TRUE,
    )
  ))
  ->setDisplayOptions('view', array(
    'type' => 'hidden',
  ));

Pour voir l'intégralité de mes modifications, vous pouvez consulter le fichier sur github : https://github.com/kgaut/mespronos/blob/master/modules/custom/mespronos_...

Personnalisation des routes et du menu

Dernier point que je souhaiter modifier, les routes et le menu. Dans drupal 8 le HOOK_menu n'existe plus, tout à été remplacé par de la configuration dans des fichiers YAML (welcome Symfony)

Les routes sont les chemins d'accès, et sont défini dans le fichier mespronos_leagues.routing.yml.

Les éléments de menu sont eux dispatchés dans plusieurs fichiers suivant leur type :

[scald=10:sdl_editor_representation]

drupal7menutodrupal8.png, par https://www.drupal.org/node/2118147

Dans l'admin dans la partie contenu, je voulais un onglet menant à la liste de tous mes compétitions, comme cela :

[scald=11:sdl_editor_representation]
 

J'ai donc pour cela modifié le fichier mespronos_leagues.routing.yml et ajouté les lignes suivantes :

league.list:
  title: 'Compétitions'
  route_name: league.list
  description: 'Liste de toutes les compétitions'
  base_route: system.admin_content

C'est tout pour aujourd'hui, n'hésitez pas à consulter mon code sur github, j'ai mis l'intégralité de ce module, et j'ajouterai au fur et à mesure la suite. Si vous voyez des erreurs, des améliorations, n'hésitez-pas à me faire des push-request.

Le projet sur github : https://github.com/kgaut/mespronos

Quelques liens qui m'ont beaucoup servis :

Tags: 

Par Kgaut
Adhérent
Kevin Gautreau

À la découverte de drupal 8 - #1 : Ma première entité

Ayant l'envie de tester Drupal 8, sans prendre trop de risques, je me suis décidé à prendre comme prétexte la création d'un site de pronostics pour l'euro 2016 (oui je m'y prends tôt).

Un petit coup de modélisation de mon schéma de données, et hop c'est parti.

Pour info, je vais tenter de faire plusieurs notes comme celle là, et autant en faire profiter tout le monde, mon code sera sur Github, au fur et à mesure, car cela évitera d'avoir des posts de 4km de long, l'adresse du projet sur Github : https://github.com/kgaut/mespronos

Le contexte

Installation du Drupal, je suis parti sur la beta 2.

Petites modifications dans le fichier settings.php pour sortir les dossiers de configurations de Drupal en dehors du docroot (donc non accessible via le web) :

$config_directories['active'] = '../config/active';
$config_directories['staging'] = '../config/staging';

Ensuite on rentre dans le vif du sujet avec la création de ma première entité drupal 8.

Je vous présente l'entité "League" qui contiendra les différentes compétitions de sport sur lesquelles des concours de pronostics seront organisés.

  • lid : Clé primaire
  • name : le nom de la compétition. Ex : "Ligue 1 2014-2015"
  • classement : doit-on calculer le classement pour ce concours ? (oui pour un championnat, non pour un mondial ou un euro)
  • status : archivé, en cours, terminé...

Mon entité sera contenue dans un module qui s’appellera "mespronos_leagues", car j'aime bien avoir un module par fonctionnalité.

Let's generate !

Pour la génération du module ainsi que de l'entité j'ai utilisé le super projet "console", que j'ai installé via composer. Je vous invite à découvrir l'installation et l'utilisation de ce module via ce tutoriel à l'adresse suivante : Créer un module Drupal 8 en 30 secondes | Flocon de toile.

J'ai donc crée mon module à l'aide de la commande suivantes

bin/console generate:module

une fois le module généré, il est temps de créer l'entité, toujours avec console, via la commande suivante : 

bin/console generate:entity:content

et là c'est magique, le contrôleur, les routes, l'entité, l'arborescence des dossiers... tout est généré automatiquement :

Encore une fois, sur la génération d'entités, tout est encore superbement expliqué sur ce site : Créer une entité Drupal 8 en 10 secondes top chrono | Flocon de toile

arborescence-entite-drupal8.png
 

il ne reste plus qu'à personnaliser selon nos besoins.

Ajout de propriétés

Une entité est "fieldable" c'est à dire que l'on peut très bien lui ajouter des champs via l'interface d'administration, comme l'on ferai avec un type de contenu. Mais comme vous le savez sûrement l'ajout d'un champ entraîne la création de deux tables (une pour la valeur, et une pour les révisions) ainsi une baisse de performance lors de l'affichage de notre contenu car cela génère forcement des jointures.

Une autre possibilité offerte par les entités est de définir des propriétés, c'est à dire des attributs qui seront présents directement dans la même table que notre entité.

Il faut pour cela modifier la méthode baseFieldDefinitions de notre entité (dans le fichier src/Entity/League.php)

Voici un exemple de code pour ajouter mon attribut "classement", qui est un booléen non affiché en front, mais présent sur le formulaire d'administration.

$fields['classement'] = BaseFieldDefinition::create('boolean')
  ->setLabel(t('Classement activé'))
  ->setDescription(t('Doit-on calculer le classement entre les équipes pour cette competitions'))
  ->setDisplayConfigurable('form', TRUE)
  ->setDisplayConfigurable('view', TRUE)
  ->setDefaultValue(TRUE)
  ->setDisplayOptions('form', array(
    'type' => 'boolean_checkbox',
    'settings' => array(
      'display_label' => TRUE,
    )
  ))
  ->setDisplayOptions('view', array(
    'type' => 'hidden',
  ));

Pour voir l'intégralité de mes modifications, vous pouvez consulter le fichier sur github : https://github.com/kgaut/mespronos/blob/master/modules/custom/mespronos_...

Personnalisation des routes et du menu

Dernier point que je souhaiter modifier, les routes et le menu. Dans drupal 8 le HOOK_menu n'existe plus, tout à été remplacé par de la configuration dans des fichiers YAML (welcome Symfony)

Les routes sont les chemins d'accès, et sont défini dans le fichier mespronos_leagues.routing.yml.

Les éléments de menu sont eux dispatchés dans plusieurs fichiers suivant leur type :

drupal7menutodrupal8.png

drupal7menutodrupal8.png, par https://www.drupal.org/node/2118147

Dans l'admin dans la partie contenu, je voulais un onglet menant à la liste de tous mes compétitions, comme cela :

Onglet dans drupal 8
 

J'ai donc pour cela modifié le fichier mespronos_leagues.routing.yml et ajouté les lignes suivantes :

league.list:
  title: 'Compétitions'
  route_name: league.list
  description: 'Liste de toutes les compétitions'
  base_route: system.admin_content

C'est tout pour aujourd'hui, n'hésitez pas à consulter mon code sur github, j'ai mis l'intégralité de ce module, et j'ajouterai au fur et à mesure la suite. Si vous voyez des erreurs, des améliorations, n'hésitez-pas à me faire des push-request.

Le projet sur github : https://github.com/kgaut/mespronos

Quelques liens qui m'ont beaucoup servis :

Tags: 

Pages