Planète

Par Artusamak
Julien Dubois

Porter son module en D8 - #1 Rendre le module installable

Porter son module en D8 - #1 Rendre le module installable
lun, 18/05/2015 - 22:00
DuaelFr

Dans la communauté française, nombreux sont les développeurs à avoir créé, au moins une fois, un module contribué. Qu'il dispose d'une version stable ou qu'il soit encore en sandbox, il va être temps de le porter sur Drupal 8 si l'on veut que cette nouvelle version majeure ait un taux de pénétration plus important que Drupal 7 à sa sortie.

Cette série, qui débute par l'article que vous êtes en train de lire, suivra étape par étape la conversion d'un module contribué, Multiple E-mail Addresses, de Drupal 7 vers Drupal 8.

Définition d'un module

Jusqu'à Drupal 7, un module était identifié par le cœur à la condition que l'on trouve, au sein du même répertoire, au moins un fichier <modulename>.info et un fichier <modulename>.module. Le fichier info contient les métadonnées du module : son nom, sa description, sa version, ses dépendances, les fichiers à charger automatiquement (autoload), etc. Le fichier module quant à lui contient les fonctions PHP de base permettant au module de fonctionner et est chargé automatiquement par Drupal si le module est actif.

Depuis le 17 mars 2015, la définition d'un module a légèrement changé dans Drupal 8. Désormais, seul un fichier <modulename>.info.yml est obligatoire. Si un fichier <modulename>.module existe, il sera toujours chargé automatiquement, mais il n'est plus obligatoire pour que le cœur de Drupal reconnaisse l'existence du module. Ce changement est dû au fait que la plupart du code qui se trouvait auparavant obligatoirement dans le fichier <modulename>.module est réparti dans d'autres fichiers source, chargés automatiquement grâce à la spécification PSR-4 de PHP, ou dans des fichiers de configuration séparés.

Initialisation du répertoire

La bonne pratique pour mettre à jour votre module d'une version majeure à une autre consiste à partie des sources de la dernier version disponible et de remplacer les fichiers et le code au fur et à mesure que l'on rencontre des erreurs. Ces erreurs peuvent survenir lors de l'exécution du module ou, dans le meilleure des cas, lors de l'exécution des tests. Nous reviendrons, au fil des articles de cette série, sur les erreurs que vous risquez de rencontrer et nosu tenterons de vous aider à comprendre ce qui se cache derrière et comment les résoudre.

De plus, si la branche principale de votre module évolue avant que vous n'ayez terminé votre portage, vous pourrez profiter de la puissance de git pour récupérer les nouvelles fonctionnalités facilement dans votre nouvelle version.

Nous débutons donc par un :

$ git clone --branch 7.x-1.x <pseudo>@git.drupal.org:project/multiple_email.git
$ git branch -b 8.x-1.x

Le fichier info

Comme dit précédemment, tout ce dont nous avons besoin pour pouvoir installer notre module est un fichier <modulename>.info.yml valide. Ce fichier est l'équivalent de l'ancien fichier <modulename>.info mais dans un format différent, le format YAML. Je passerai rapidement sur ce format étant donné qu'il existe de la documentation un peu partout sur Internet et même en français. En quelques mots il s'agit d'un format de sérialisation de données simple, standard et compréhensible par l'humain.

Le cas de Multiple E-mail Addresses étant trop simple pour servir d'exemple, voyons un cas générique qui recense les principales entrées que l'on trouve habituellement dans un fichier info.

Avant : <modulename>.info

name = "Nom du module"
description = "Description du module"
core = 7.x
package = Other
dependencies[] = entity
dependencies[] = entityreference
files[] = modulename.test
files[] = views/modulename_handler.inc
configure = admin/configure/modulename

Après : <modulename>.info.yml

name: 'Nom du module'
description: 'Description du module'
core: 8.x
type: module
package: Other
dependencies:
 - entity
 - entityreference
configure: modulename.admin.settings

Pour entrer dans le détail vous remarquerez tout d'abord que la plupart des entrées sont identiques ; les symboles "=" ont simplement été remplacés par des symboles ":" à la manière du format JSON.

De plus, vous noterez l'apparition d'une nouvelle entrée obligatoire qui n'existait pas dans les versions précédentes et qui permet de définir le type de projet dont il s'agit : module, theme ou profile. Cette entrée a été créée pour permettre le changement autorisant un module ou un profil d'installation à n'être défini que par son fichier <modulename>.info.yml. Auparavant, c'était la présence d'un fichier <modulename>.module ou <modulename>.profile qui permettait à Drupal de faire la différence.

Ensuite, les dépendances suivent le format des collections YAML en passant sous la forme d'une liste préfixée d'un tiret. Elles auraient également pu être décrites sur une ligne entre crochets et séparées par des virgules comme suit : 

dependencies: [entity, entityreference]

Les entrées files ont quant à elles simplement disparu. En effet, comme dit précédemment, Drupal 8 suit la spécification d'auto-chargement PSR-4 et il n'est donc plus nécessaire de déclarer les fichiers qu'il faudra charger puisqu'ils seront inclus automatiquement lors de l'appel à leur contenu.

Enfin, l'entrée configure, qui permet d'afficher un lien vers l'URL de votre choix directement depuis la liste des modules, est réécrite en utilisant le nouveau système de routes dont nous reparlerons dans le troisième volet de cette série d'articles. Cette entrée est optionnelle donc je vous recommande de l'omettre pour commencer et de vous laisser une note pour la rajouter plus tard.

Si vous voulez voir un autre exemple, Nicolas a déjà rédigé un billet sur ce blog qui se base sur le fichier info du thème Seven présent dans le cœur de Drupal.

Le résultat sur multiple_email.info.yml

name: 'Multiple E-mail Addresses'
type: module
description: 'Allows users to have more than one registered e-mail address.'
core: 8.x
# @TODO add configure route

Le fichier install

La plupart des modules existants incluent un fichier <modulename>.install contenant des implémentations de hooks joués lors de l'installation ou de l'activation du module. Drupal 8 a vu de nombreux changements opérés au sein de ce fichier. Certains concepts et les hooks associés ont disparu comme l'activation et son hook_enable ainsi que la désactivation et son hook_disable. D'autres n'ont pas vraiment changé comme les hook_schema, hook_install et hook_uninstall bien que leur contenu puisse être différent.

Étant donné que nous avons copié la totalité des fichiers de la version 7.x du module, il est probable qu'un fichier <modulename>.install existe dans votre répertoire, ce qui risque de poser des problèmes pour activer le module. Par exemple, lorsque l'on tente d'activer le module multiple_email, nous obtenons l'erreur suivante : 

$ drush en -y multiple_email
The following extensions will be enabled: multiple_email
Do you really want to continue? (y/n): y
exception 'PDOException' with message 'SQLSTATE[42S22]: Column not found: 1054 Unknown column 'mail' in    [error]
'field list'' in /[...]/core/lib/Drupal/Core/Database/Statement.php:61
[... Stack trace ...]

Next exception 'Drupal\Core\Database\DatabaseExceptionWrapper' with message 'SQLSTATE[42S22]: Column not
found: 1054 Unknown column 'mail' in 'field list': 
    INSERT INTO {multiple_email}
      (uid, email, time_registered, confirmed)
    SELECT
      uid,
      mail,
      created,
      1
    FROM {users}
    WHERE uid != 0
    AND mail != ''
    GROUP BY mail
  ; Array
(
)
' in /[...]/core/lib/Drupal/Core/Database/Connection.php:609
[... Stack trace ...]

L'erreur étant survenue lors de l'installation du module, il est probable qu'elle provienne du hook_install. Vérification faîte, c'est bien ce hook qui tente d'exécuter la requête SQL incriminée. En y regardant de plus près, l'erreur dit qu'il n'y a pas de colonne mail dans la table cible. Un coup d'œil dans la base de données nous montera qu'en effet, la table users ne contient plus de colonne mail.

En attendant que nous abordions la migration de ces hooks en détail dans un chapitre prochain, je vous recommande de commenter la totalité du code de ce fichier afin d'éviter les erreurs à l'installation et à la désinstallation du module.

Conclusion

Maintenant que vous avez commenté votre fichier <modulename>.install et converti votre fichier <modulename>.info, vous n'avez plus qu'à activer votre module dans Drupal pour vérifier qu'aucun morceau de code resté dans le fichier <modulename>.module n'entre en conflit avec le cœur de Drupal 8.

La prochaine étape, couverte dans le deuxième article de la série, sera de transformer les tests de votre module pour qu'ils puissent être exécutés dans Drupal 8. Cela vous permettra de simplfiier le travail de mise à jour du module tout en évitant les régressions.

Par Artusamak
Julien Dubois

Drupal et Scrum depuis les tranchées - Le scrum quotidien

Drupal et Scrum depuis les tranchées - Le scrum quotidien
ven, 15/05/2015 - 15:46
Artusamak

Le rituel qui se répétera le plus tout au long de vos projets sera le scrum quotidien. Certains l'appelleront la mêlée, le stand-up, le scrum. Tous ces termes représentent la même chose, un moment particulier durant lequel l'équipe se rassemble devant le tableau d'avancement pour faire le point.

Les règles du scrum

  1. La première règle du scrum est que le scrum commence à l'heure. Pas d'excuse pour les retardataires, leur conscience et l'équipe finiront par les rattraper pour qu'ils arrivent à l'heure. C'est une question de respect - j'ajouterai que cela colle bien avec l'esprit agile où l'on doit livrer comme promis et qu'il faut adapter le contenu.
  2. La seconde règle du scrum est que la durée du scrum est limitée. La durée recommandée est 15 minutes. Si cela dure moins longtemps et bien c'est autant de temps de code en plus. Si cela doit prendre plus de temps, c'est sûrement que vous faites mal quelque chose (des explications plus bas ;-)).
  3. La troisième règle du scrum est qu'une seule personne a le droit de parler à la fois. Pas de conversations croisées, on écoute son interlocuteur puisqu'on doit réagir à ce qu'il se dit. C'est de l'écoute active. Le détenteur de la parole peut se matérialiser par un totem / bâton de parole, si vous ne l'avez pas entre les mains et bien... vous ne pouvez pas parler. Cela permet d'éviter que l'on vous coupe la parole.
  4. La quatrième règle du scrum est que le scrum se fait debout. Cela stimule les interlocuteurs et aide à faire en sorte que le point dure moins longtemps. Évidemment on ne lit pas ses emails ou ne joue pas à Candy Crush pendant le point quotidien.

De quoi parle-t-on pendant le scrum ?

L'équipe se tient devant le tableau d'avancement et chaque équipier répond aux trois questions suivantes : qu'ai-je fait hier, que vais-je fait aujourd'hui et quels sont les problèmes que j'ai rencontré. Chacun répond à ces questions en s'adressant aux autres, pas en s'adressant au scrum master. Le fait de faire le point devant le tableau d'avancement permet aussi de voir les stories qui avancent, c'est très gratifiant !

L'intérêt principal du scrum est que tout le monde soit au courant de ce qu'il se passe et que si une personne travaille sur un sujet potentiellement déjà couvert par une autre personne, elle sache qui aller voir pour se mettre tout de suite dans le bain. C'est un gain de temps significatif pour l'équipe.

Le second intérêt du scrum est la prise de conscience collective, chacun doit être à l'écoute des autres. En soulevant ses problèmes, un équipier lance une invitation à ce que l'on vienne l'aider. À quoi bon perdre du temps à chercher une solution si quelqu'un peut lui donner des pistes pour résoudre son problème ou mieux encore, s'asseoir à ses côtés pour résoudre son problème ensemble.
Si chaque matin une personne indique qu'elle travaille sur le même sujet sans pour autant remonter de problème, il faut se rendre compte qu'il y a un problème. Soit la personne décrit de façon trop macro ses problématiques, soit elle ne se rend pas compte qu'elle n'avance pas et doit demander de l'aide. Il est alors de la responsabilité de l'équipe de s'en rendre compte et de proposer des solutions pour régler cela. De la même façon, si vous ne comprenez pas de quoi vous parle un équipier, prenez 5 minutes avec lui après la réunion pour qu'il vous explique un peu mieux plutôt que de vous désintéresser de son travail.

Gardez à l'esprit que vous devez livrer à la fin du sprint un logiciel fonctionnel avec le maximum de valeur ajoutée. Si des stories n'arrivent pas à être fermées pendant plusieurs jours, rediscutez leur priorité pour savoir s'il ne faudrait pas plutôt se concentrer sur autre chose avec plus de valeur. Il peut être plus sage de sortir les stories du sprint et de les réintégrer plus tard, peut être de façon redécoupée.

Photo d'un paysage de bord de mer.

Et si la conversation doit prendre plus de temps ?

Parfois il vous sera nécessaire d'approfondir les échanges, notamment lorsque vous parlerez des problèmes. Le scrum n'est pas là pour résoudre les problèmes mais pour les faire remonter. Lorsque ce cas de figure se présente : identifiez que vous êtes entrain de débattre d'une piste de résolution ; interrompez la conversation ; donnez vous rendez-vous dans la journée (immédiatement après le scrum par exemple) ; laissez le scrum reprendre son cours. Cela peut s'appliquer à d'autres sujets tels que de l'architecture ou des pistes d'implémentations. Dès qu'un débat se présente, retardez le, ne conviez que les personnes concernées par la discussion (ou volontaires pour apporter leur opinion). Le temps de chacun est précieux, respectez le. Cela évite également que les gens se désintéressent. Mieux encore, si vous vous désintéressez, demandez-vous pourquoi et mettez le sujet sur la table lors de la prochaine rétrospective.

Autres points

Le scrum n'est pas uniquement là pour parler des problèmes, il n'est pas interdit de dire aux autres que l'on a apprécié quelque chose. Au contraire, je vous encourage même à vous forcer à dire régulièrement à vos équipiers ce que vous avez apprécié dans leur travail récent. (NDLR : cela peut aussi s'appliquer à vos amis et votre famille ;-)).

Les clients ne sont en général pas conviés au scrum, il nous est arrivé sur certains projets de les impliquer pour qu'ils soient concernés. Cela permet de suivre leur avancement et de se synchroniser lorsqu'il y a des dépendances sur de la production de contenu par exemple.

Attention à la routine, les scrums ont lieu tous les jours alors soyez originaux de temps à autre. Veillez à ce que les gens ne parlent pas toujours dans le même ordre, changez de pièce à l'occasion, variez l'ordre des questions on ne répondez pas à la première ou seconde à l'occasion. Aléatoirement une personne peut résumer ce que les autres ont fait pour confirmer que tout le monde est attentif.
Bref, gardez le scrum dans un esprit le plus collégial et le plus bon enfant possible, il ne faut pas que ça soit une punition !

Par besky
Richard B.

Drupal : un CMS flexible et puissant

Découvrez le CMS Drupal, la solution la plus puissante et flexible pour la création d'applications web : site internet, intranet, extranet ou encore e-commerce.

Drupal un CMS flexible et puissant

Par ftorregrosa
Adhérent
Florent Torregrosa

Retour sur les Drupal Dev Days 2015

Du 13 au 19 avril 2015 ce sont déroulés les Drupal Developer Days à Montpellier. Ça a été une expérience géniale et très enrichissante que ce soit en tant que co-organisateur ou en tant que participant.

Sprints

J'ai aidé à sortir la première version D8 du module Search API attachements, ainsi qu'à nettoyer l'issue queue des issues pour D7.

Il était aussi intéressant d'entendre la structure de la future facet API D8 se débattre juste à côté.

Tags: 
Par admin

Drupagora 2015 : Appel à communications

Drupagora est un rendez-vous incontournable, francophone sur Drupal dédié aux chefs de projets et DSI, de tout l’écosystème Drupal et attire chaque année plus de 350 professionnels, venus de toute la France.

Pour sa cinquième édition, Drupagora a changé le calendrier et le lieu de rendez-vous pour accueillir plus de participants dans des conditions optimales. C'est pourquoi, Drupagora se tiendra cette année le 19 juin et aura lieu à l'Université Pierre et Marie Curie (Paris 5ème)

Cette année, le fil rouge du programme est : « Drupal dans le contexte de l'Entreprise: plateformes digitales globales, applications eCommerce, applications métier jumelées et intégrées au SI (ERP, CRM, PIM, DAM…). »

Avec pour thématiques principales :

  • Comment Drupal s'intègre t-il avec d'autres applications métier?
  • Exemples réussis et témoignages d'applications Drupal d'envergure et de E-commerce
  • Les perspectives avec l'arrivée prochaine de Drupal 8

L'appel à communication est disponible jusqu'au 1er mai 2015.

Par ailleurs, à noter que les inscriptions à Drupagora sont ouvertes au tarif early bird, et ce, jusqu'à la clôture de l'appel à communications.

Informations complémentaires

  • Date, lieu et organisation

La conférence Drupagora se tient à l'Université Pierre et Marie Curie, Paris 5ème, le vendredi 19 juin de 9h à 18h.

  • Tarif / Inscription

40 euros jusqu'au 01/05/2015
75 euros jusqu'au 15/06/2015
100 euros en tarif normal

Liens

Tags : 
Par vincent59
Vincent Liefooghe

Installer Drush avec Composer

Depuis quelques temps déjà, Drush (DRUpal SHell) est disponible sur GitHub, et non plus sur http://drupal.org.

L'installation peut se faire via git ou via Composer. C'est cette méthode qui est nécessaire pour l'installation avec Drupal 8.

Installation des pré-requis sur la machine
Ces paquets sont utilisés pour récupérer les données via http et git. unzip est utilisé avec drush make pour dézipper certains fichiers.

apt-get install curl git unzip

Installation de Composer
L'installation de Composer est faite en global (pour tous les utilisateurs).

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

Installer Drush pour l'utilisateur courant

composer global require drush/drush:dev-master
ls -a .composer/vendor/bin
.  ..  boris  drush  drush.bat	drush.complete.sh  drush.php

Drush est installé dans le répertoire .composer/vendor/bin de l'utilisateur. Il faut ensuite ajouter ces lignes dans le .bashrc :

export PATH=$HOME/.composer/vendor/bin:$PATH

Installer Drush pour tous les utilisateurs
Si plusieurs utilisateurs ont accès à la machine, il est préférable d'avoir une installation globale :

git clone https://github.com/drush-ops/drush.git /usr/local/src/drush
cd /usr/local/src/drush
git checkout 
ln -s /usr/local/src/drush/drush /usr/bin/drush
composer install
drush --version
which drush

Voilà, on peut maintenant utiliser toute la richesse de drush pour installer / activer des modules, installer un site complet, etc.

  Références :http://www.drush.org/en/master/install/ 

Catégorie: 


Tag: 

Par admin

Drupal Developer Days c'est maintenant

Après de nombreux mois de préparations, l'événement Drupal Developer Days commence aujourd'hui, le 13 avril 2015 à Montpellier, en France.

Nous sommes très impatients de retrouver toutes les personnes inscrites car la semaine est très prometteuse et de qualité.

Même si vous ne pouvez pas être présent, vous pouvez consulter le site officiel de l'événement : Drupal Developer Days 2015

Par anavarre

Présentation meetup Drupal Lyon - L&#039;intégration continue pour tous

Au pied levé, j'ai préparé une présentation sur l'intégration continue pour Drupal Lyon. Plutôt que de parler CI d'entreprise et de rentrer dans les détails de Jenkins et du workflow typique d'un équipe de dév, pourquoi ne pas déjà aborder toutes les bonnes pratiques et méthodologies à employer pour soi-même créer un produit testé et fiable ? Bienvenue dans l'intégration continue pour tous !

Par vincent59
Vincent Liefooghe

Archivage de sites Wordpress / Drupal

J'ai récemment eu besoin d'archiver des sites initialement créés avec les CMS Drupal et Wordpress, de clients HebInWeb ayant arrêté leur activité (et donc également leur site).

Le nom de domaine n'a pas été renouvelé, et a été détruit.
 
Plutôt que de supprimer complètement les sites, j'ai décidé de les archiver, mais en utilisant un site 100% statique en html/css/js, plutôt que de rester sur les CMS initiaux.

Ceci a plusieurs avantages à mes yeux :

  • sites plus rapides (nginx est assez doué pour ça)
  • arrêt des  mises à jour à faire sur les CMS
  • suppression de PHP = moins de ressources mémoire consommée
  • suppression de la base de données = moins de ressources
  • pas de sauvegarde (j'ai une copie de l'archive en local sur mon PC et sur disque externe)

Sachant qu'on est bien dans un mode "archive", qui sera probablement très peu visité, je me voyais mal "gâcher" des ressources pour cela.

Après quelques recherches, je suis tombé sur un site : https://swsblog.stanford.edu/blog/creating-static-copy-website qui m'a orienté vers la création d'un script reposant sur wget afin de faire un miroir statique.

#!/bin/sh
#
echo -n "Destination directory : "
read DEST

echo -n "Site URL : "
read URL

wget -P $DEST -mpck --user-agent="" -e robots=off --wait 1 -E $URL

Les options utilisées ici sont :

  • -P : chemin (Path) complet pour sauvegarder le site
  • -m : mode miroir
  • -p : télécharge tous les éléments nécessaires (css, js, images)
  • -c : continue le téléchargement en cas d'erreur
  • -k : convertit les liens absolus en relatifs
  • --user-agent : ignore le user-agent
  • -e : exécute la commande
  • --wait 1 : attente d'une seconde entre chaque requête (optionnel)
  • -E : renomme les fichiers avec une extension .html
  • $URL : URL du site à convertir

La copie d'un site s'effectue de manière assez simple. On saisit le répertoire de destination, puis l'URL, et on attend que wget fasse le boulot...
Le paramètre "wait" ralentit un peu, si on s'en passe cela ne prend que quelques secondes.

Sur le site Wordpress, j'ai juste retouché la page de contact, qui s'est retrouvée avec une notation de type [contact xxx].

Pour le site sous Drupal, j'ai commencé par désactiver les modules "interactifs", tels que comment, contact, etc.

S'agissant d'une archive, j'ai également désactivé les modules tels que XMLsitemap (qui de toute manière ne renverra plus rien, car le site sera en HTML statique)

Autres options

Avec wget

Une alternative (http://stackoverflow.com/questions/66610/how-can-i-create-a-site-in-php-...) utilise la commande suivante :

wget -k -K -E -r -l 10 -p -N -F -nH $URL

Wordpress

Il semble exister quelques plugins qui réalisent cette conversion, mais je n'ai pas approfondi (voir dans les références ci-après)

Drupal

Il existe un module, Static, assez récent, qui effectue cette conversion

Références

Quelques références sur le sujet :

Catégorie: 


Tag: 

Pages