Planète

Par Artusamak
Julien Dubois

21ème séminaire technique Accessiweb

21ème séminaire technique Accessiweb
ven, 26/06/2015 - 11:00
DuaelFr

Le 25 juin, l'amphithéâtre Painlevé de la Cité des Sciences et de l'Industrie à Paris a accueilli le 21ème séminaire technique Accessiweb. Cette édition était dédiée à l'accessibilité des CMS et c'est en la qualité d'expert Drupal que j'y ai été convié pour participer à l'atelier technique visant à comparer 4 des plus grands CMS du marché.

Logo d'AccessiWebLa journée a commencé par une rapide introduction du sujet et des actualités de l'association BrailleNet, éditrice de la recommandation Accessiweb. Outre leur déménagement, j'ai donc pu apprendre que la recommandation Accessiweb avait été refondue dans le référentiel RGAA 3.0 qui a récemment été ratifié par décret et inauguré officiellement ce matin même. Les marchés publics devront donc désormais suivre cette nouvelle norme dans la réalisation de leurs sites et applications. Le diplôme "Expert Accessibilité en Évaluation" sera quant à lui adapté dans les prochains mois pour suivre ces nouvelles dispositions et une remise à niveau sera proposée par l'association BrailleNet pour les personnes le souhaitant.

Présentation d'ATAG2, les recommandations du W3C pour l'accessibilité des CMS par Jean-Pierre VILLAIN (Access 42)

La première intervention s'est trouvée riche en surprises. La norme ATAG2 s'ajoute en effet aux recommandations WCAG pour diriger la création des outils de gestion de contenus incitant à la production de contenus accessibles.

Jean-Pierre Villain a filtré et détaillé quelques uns des points les plus intéressants à chacun des niveaux de la norme et je vais vous en restituer quelques uns. La norme ATAG2 complète concernant à la fois les outils web et les logiciels en client lourd, elle est particulièrement complexe et nécessitera d'être découpée afin de la rendre plus accessible. Comme la norme WCAG, celle-ci est découpée en trois niveaux (A, AA et AAA) qui ne suivent toutefois pas la même logique d'organisation.

Au niveau des interfaces, ATAG2 exige tout d'abord que toutes soient conformes à la norme WCAG. Le niveau A recommandera de documenter les fonctions liées à l'accessibilité alors que le niveau AA recommandera la documentation de toutes les fonctionnalités du CMS. De la même manière, toutes les actions devront demander une confirmation à l'utilisateur pour le niveau A alors que le niveau AAA recommande de fournir un historique complet des actions à l'utilisateur pour lui permettre de revenir en arrière facilement. On retrouve le même schéma pour la personnalisation de l'interface qui doit aller de la simple activation ou désactivation de certains messages (A) à la personnalisation de tous les raccourcis claviers (AAA).

Le second volet d'ATAG2 concerne la création de contenu accessible. La plupart des recommandations exposées concerne le fait de pouvoir modifier ou supprimer le contenu ou les alternatives qui auraient été générées par le système. Toutefois, dès le niveau A il est demandé de garantir la conformité des contenus à la norme WCAG ou, d'avertir explicitement le rédacteur que ce n'est pas le cas. On retrouve ce système d'alertes dans la plupart des demandes notamment lors de la conversion de contenu d'un format à un autre (par exemple lors d'une édition d'un contenu web en PDF). Le niveau AAA pose des exigences inhabituelles comme le fait d'utiliser le même contenu alternatif pour un média quelle que soit la page dans laquelle il apparaît ou encore l'obligation de proposer des tutoriels pour la création de contenus accessibles.

Cette intervention très riche s'est terminée par la démonstration des capacités de validation de l'éditeur CKEditor qui est certes imparfaite mais qui pose les bases d'un système qui pourrait devenir vraiment décisif dans la rédaction de contenus accessibles pour le web. 

Photo d'une personne annotant un contrat

Adapter un CMS pour répondre au besoin - retour d'expérience avec EzPublish, par Christophe CARON (Telmedia)

La deuxième intervention de la journée était un retour d'expérience concernant la refonte du site pasdecalais.fr sous EzPublish 5 par la société Telmedia.

Le site pasdecalais.fr c'est en fait une galaxie de 10 sites satellites gérés par une vingtaine de rédacteurs et administrateurs et qui comptent environ 4000 pages. La partie concernant l'accessibilité de cette refonte était grandement portée par l'un des responsables côté client. Le projet a nécessité environ 150 jours de travail dont 20 ont été dédiés à la prise en compte des retours de la société Temesis concernant l'accessibilité.

Parmi les détails intéressants de ce retour d'expérience, j'ai appris que l'éditeur WYSIWYG de EzPublish était dérivé de TinyMCE et qu'il n'enregistrait en base qu'une structure XML qui est ensuite retraitée par des préprocesseurs pour fournir la sortie HTML souhaitée. C'est notamment ce qui a permis à Telmedia de modifier très simple toutes les balises accronym en abbr suite à leur retrait de HTML5.

Logo eZ Publish

Le site disposant également d'une WebTV, un effort a été fourni pour permettre aux rédacteurs de proposer des vidéos disposant d'une piste d'audio-description et de sous-titres. À la manière de Drupal (selon Christophe), EzPublish propose un système de gestion des champs de saisie sur lequel Telmedia s'est appuyé pour développer cette fonctionnalité.
C'est le player MFP Player, dérivé de MediaElement.js qui a été retenu pour jouer les vidéos. En plus de prendre en charge l'audio-description et les sous-titres, celui-ci est navigable au clavier et permet à l'utilisateur un grand degré de personnalisation notamment dans le style d'affichage des sous-titres. 

Pendant l'inauguration de la norme RGAA 3.0, le site pasdecalais.fr a d'ailleurs été récompensé et a reçu l'une des plus hautes labellisation possible du point de vue de l'accessibilité.

L'accessibilité via les thèmes enfants, par Gaël POUPART (Kosmos)

Cette troisième intervention concernait notamment une des fonctionnalité peu utilisée de WordPress qui consiste à permettre d'étendre un thème de base grâce à des thèmes enfants. Gaël, designer de formation devenu intégrateur puis développeur WordPress par la force des choses nous a décrit la façon dont ces thèmes enfants fonctionnent et en quoi ils permettent de capitaliser sur des développements dont certains peuvent concerner l'accessibilité.

Contrairement à Drupal, un thème doit être conçu de façon spécifique afin de permettre son extension par des thèmes enfants. En effet, les thèmes enfants étant appelés avant le thème parent, si ce dernier ne dispose pas des contrôles nécessaires, il sera impossible de redéfinir certaines de ses fonctionnalités pour les adapter au besoin que le thème enfant cherche à remplir. Parmi les très nombreux thèmes disponibles gratuitement ou commercialement, très peu intègrent d'ailleurs cette possibilité. 

En complément aux thèmes enfants, WordPress dispose d'un système d'extensions obligatoires qui permettent d'enrichir les fonctionnalités de l'interface de rédaction. L'aspect obligatoire de ces extensions permet de garantir que l'utilisateur ne pourra pas les désactiver ce qui risquerait au mieux de dégrader l'expérience des visiteurs et au pire de rendre le site totalement inaccessible.

Thèmes comme extensions peuvent désormais bénéficier d'un tag "Accessbility Ready" dans l'annuaire du site officiel. À ce jour, seule une quinzaine des 3000 thèmes référencés disposent de ce tag dont l'attribution répond à un petit ensemble de critères ne couvrant pas tous les besoins des personnes en situation de handicap.

Logo de Wordpress

Intégrer l'exigence d'accessibilité au développement d'un CMS : l'exemple de WordPress, par Olivier NOURRY (BrailleNet)

La dernière session avant la pause déjeuner était reprise d'une conférence donnée par Joe Dolson, responsable de l'accessibilité dans l'équipe de développement du cœur de WordPress, donnée lors d'un WordCamp. Elle a été traduite et présentée par Olivier de l'association BrailleNet.

J'ai pu y découvrir, sans surprise, que l'organisation de la contribution dans le cœur de WordPress est relativement similaire à celle de Drupal bien que les décisions finales semblent plus verrouillées côté WordPress. La dernière version majeure du cœur a réuni presque 300 contributeurs, chiffre en constante progression ce qui illustre bien le regain d'intérêt de la communauté des développeurs pour cet outil.

L'information la plus marquante de cette session est que, selon Joe Dolson, le CMS le plus accessible à ce jour est Drupal, bien qu'ils travaillent activement à rattraper le retard. Cette compétition pour l'accessibilité est un enjeu important pour tous les CMS qui se destinent aux sites institutionnels et elle ne pourra être que bénéfique à la communauté des personnes en situation de handicap et, plus généralement, à tous les utilisateurs de ces solutions.

Atelier : 4 CMS sur le grill, Wordpress, Drupal, SPIP et Joomla!

De retour d'un déjeuner très attendu, nous avons pu attaquer la plus grosse session de la journée. Il s'agissait d'un atelier de deux heures, présenté par Olivier NOURRY et faisant intervenir quatre experts, dont moi-même, pour évaluer les différences entre les CMS dans la possibilité de produire du contenu accessible. Cet atelier avait été préparé en amont pour que chacun puisse faire les recherches nécessaires pour répondre au mieux au besoin.

Pour ma part, j'ai profité de cette occasion pour comparer les résultats de Drupal 7 et Drupal 8 et j'ai finalement décidé de présenter ceux de Drupal 8 pour mettre en avant les progrès importants du cœur. Durant cet exercice, j'ai été confronté à certaines problématiques qui m'ont permis de proposer des améliorations ou de lancer des discussions en espérant pouvoir encore intervenir avant la sortie officielle.

Globalement, les résultats de Drupal sont plutôt bons et la plupart des exigences pouvaient être validées à partir des fonctionnalités disponibles dans le cœur. La comparaison aux trois autres CMS n'est pas évidente étant donné que le score de chacun n'était pas basé sur des critères totalement objectifs. Cependant, à l'annonce des points de blocage et des méthodes de résolution avancées par les autres, Drupal répond quasi toujours de manière plus simple.

Cet exercice, bien que chronophage, a été plutôt profitable à tous les intervenants qui ont pu proposer des solutions à des problèmes récurrents dans le domaine de l'accessibilité. Certains ont eu le temps de proposer un site de démonstration qui pourra servir de base de documentation pour de futurs contributeurs. Pour ma part, je n'ai pas pu terminer cette partie mais je compte bien m'y atteler dans un futur proche. 

Logo de Drupal 8

L'accessibilité dans la culture de Drupal par Mike GRIFFORD (OpenConcept)

La journée a été clôturée par une intervention à distance de Mike GRIFFORD qui est le référent accessibilité du cœur de Drupal. 

Il a à la fois présenté Drupal, sa communauté et ces processus de développement. En un peu plus de 30 minutes il a su montrer le dynamisme et la rigueur de notre CMS et a abordé la place de l'accessibilité dans les développements en cours.

Pour entrer un peu dans le détail, il a évoqué quelques avancées récentes de Drupal concernant l'accessibilité notamment la refonte des messages d'erreur des formulaires pour être conforme aux normes et totalement fonctionnels pour les personnes en situation de handicap. Il a également mis l'accent sur le fait que l'accessibilité pour Drupal n'était pas uniquement destinée à rendre le front des sites accessible mais aussi le backoffice afin de permettre à tous de contribuer au contenu. À titre d'illustration, il a abordé le travail conjoint réalisé avec l'équipe de développement de jQuery UI ou de CKEditor pour rendre ces outils compatibles avec la navigation au clavier et les lecteurs d'écrans.

Ayant déjà croisé Mike dans les commentaires de l'issue queue de Drupal, le fait d'assister à cette présentation, et plus généralement à cette journée de conférences, m'a donné envie d'apporter mon soutien à cette équipe qui travaille dans l'ombre pour livrer des évolutions souvent invisibles pour le commun des mortels mais absolument essentielles pour les personnes en situation de handicap.

En conclusion, je remercie grandement Olivier pour avoir fait appel à nous et nous avoir fait confiance. Cette journée était à la fois intéressante et motivante et j'y participerai à nouveau avec plaisir.

 

Crédit illustration principale : Jil Wright

Par Artusamak
Julien Dubois

Assister au webinar « la migration vers Drupal 8 » le 30 juin 2015.

Assister au webinar « la migration vers Drupal 8 » le 30 juin 2015.
mar, 23/06/2015 - 09:29
Bès

Kaliop et Happyculture organisent un webinar le 30 juin 2015 au cours duquel Julien Fabre (@julienfabre) et moi-même aborderons le cas de la migration sous Drupal 8.

Nous évoquerons rapidement les nouveautés de Drupal 8 ainsi que la philosophie avec laquelle il a été développé, puis nous verrons les enjeux d'une migration vers Drupal 8 et comment s'y préparer au mieux.

La présentation n'entrera pas dans les détails techniques d'une migration, mais vous fournira les moyens clés utiles à la prise de décision.

Le webinar durera environ 45 minutes et sera disponible pendant 7 jours après diffusion alors n'hésitez pas à vous inscrire, nous répondrons aussi à vos questions à la fin de la présentation.

 

Crédit image : Jamie McCaffrey

Catégorie
Par Artusamak
Julien Dubois

Drupal et Scrum depuis les tranchées - La démo du sprint

Drupal et Scrum depuis les tranchées - La démo du sprint
lun, 08/06/2015 - 17:16
Artusamak

Tous les développements réalisés par l'équipe ont vocation à finir en production. Le travail est fait pour l'utilisateur final, pas pour la simple gloire d'écrire du code. C'est en gardant cet objectif à l'esprit que les jours de développement s'enchaînent au cours d'un sprint et se concrétisent par une démonstration pour présenter les progrès accomplis à la fin d'une itération.

Qu'on se le dise, la démo doit être vécue comme une célébration, chacun(e) doit venir fièrement montrer les avancées qu'il/elle a réalisé. Mais avant d'ouvrir le champagne, une démonstration se prépare.

La démonstration a généralement lieu en fin de dernière semaine d'une itération, disons le jeudi et dure 1h à 2h au maximum. Scrum nous encourage à livrer des incréments de logiciel fonctionnels, la conséquence directe de cela est que l'on ne commence pas de grosse fonctionnalité le dernier jour du sprint, on se concentre plutôt sur la préparation de la démo. On ne pousse pas non plus un gros patch à l'arrache susceptible de casser le travail des petits copains.
L'équipe se rassemble pour identifier un scénario des fonctionnalités terminées à présenter. Chaque membre de l'équipe vient présenter son travail, il est important que chacun(e) s'exprime et montre ce qu'il/elle a fait. Une fois le scénario établi, on prépare un environnement de test pour le client pour qu'il puisse, une fois la démo passée, retrouver ce qui a été fait et tester par lui même le puzzle assemblé au cours du sprint. Bien souvent vous aurez besoin de créer des contenus / utilisateurs, préparer des fichiers à uploader et tomberez sur des bugs de dernière minute. Profitez de ce temps de préparation pour identifier et corriger cela pour que votre démonstration soit réussie.

On le sait, bien souvent les développeurs ne sont pas les meilleurs communiquants du monde. Cela ne veut pas dire qu'il ne savent pas parler, bien au contraire, ils aiment en général parler de ce qu'ils aiment. Faites donc travailler ceux qui en ont besoin. En faisant une démo du projet vous racontez une histoire, rendez cela le plus fluide possible en apprenant à meubler dans les temps faibles et en rendant la présentation intéractive.

Sont conviés à la démonstration toutes les parties prenantes, l'équipe projet, le scrum master, le product owner mais peuvent aussi participer les utilisateurs finaux, la direction, etc. C'est un moment adapté pour collecter les avis et potentiellement ajuster le comportement des fonctionnalités par la suite si des sujets importants sont soulevés. Attention cependant à veiller à ce que tout le monde sache se tenir pendant la réunion.
C'est pendant la démo que Drupal est un produit intéressant. Une conversation sur une demande du product owner peut vite arriver à identifier des évolutions simples à mettre en oeuvre. "Serait-il possible de trier par...", "pourriez-vous réordonner les blocs...", "que se passe-t-il si on inverse l'ordre des champs...". Ces exemples de questions peuvent souvent être démontrés tout de suite grâce à la flexibilité de Drupal, vous donnant ainsi la possibilité de décider rapidement de changement à adopter ou non. Appuyez-vous au maximum sur les modules contribués pour valider les critères d'acceptation des stories et échanger pendant une démo avec le product owner sur les possibilités supplémentaires données par les modules pour donner suite à des changements ou non.

La première fois que vous ferez un sprint avec votre équipe nouvellement agile, il se pourra que vous n'ayez fermé aucune story et donc n'ayez rien à montrer... cela fait partie du jeu, l'équipe comprendra alors qu'il ne faut pas reproduire cette expérience et veillera à avoir des choses à démontrer lors de l'itération suivante.

Par Artusamak
Julien Dubois

Porter son module en D8 - #3 Encore les tests

Porter son module en D8 - #3 Encore les tests
lun, 08/06/2015 - 12:00
DuaelFr

Dans le précédent article de cette série qui suit, étape par étape, la conversion d'un module contribué, Multiple E-mail Addresses, de Drupal 7 vers Drupal 8, nous avons commencé à convertir les tests fonctionnels afin d'être certains de ne pas introduire de régression. Maintenant que nos tests peuvent être exécutés par Drupal, nous allons aborder quelques unes des erreurs les plus courantes qu'il faudra corriger avant même de s'attaquer au côté fonctionnel de votre portage.

Badge "Don't panic"
© Jim Linwood

Les dépendances

Cette première erreur est très souvent assez insidieuse. Les tests ayant pour objectif de valider le fonctionnement d'un ou plusieurs modules dans un contexte donné, ils ont presque toujours besoin de définir ces derniers en dépendances qui seront auromatiquement activées au lancement du test. Or, ce système de déclaration des dépendances a légérement changé et il n'est pas forcément évident de s'en rendre compte en se basant uniquement sur les erreurs remontées par Simpletest.

Par exemple, en exécutant la classe de tests UserTest à nouveau, nous obtenons une erreur "Fatal error:  Call to a member function getUsername() on boolean in /core/modules/simpletest/src/WebTestBase.php on line 553". Celle-ci se produisant au sein même du code de Simpletest, lui même très bien testé, nous devons supposer que l'erreur est en réalité issue de notre code. Selon le message d'erreur, cette dernière a lieu au sein de la méthode drupalLogin() de la classe WebTestBase. Que ce soit à l'aide d'un debugger ou par le biais de méthodes plus artisanales (un var_dump() du retour de la fonction debug_backtrace() par exemple), nous constatons que l'erreur est soulevée à partir de l'appel à la méthode drupalLogin() contenu dans notre méthode setUp(). Cela suffit pour nous donner des clefs pour faire une recherche dans les Change records avec le mot clef "setUp" et pour trouver une référence au fait que la méthode pour indiquer les dépendances d'un module a changé.

Le Change record nous indique qu'il faut désormais indiquer les dépendances dans une propriété statique $modules de la classe au lieu de les passer à la méthode setUp() de la classe parente. On remplace donc 

function setUp() {
  // Enable the Multiple User module
  parent::setUp('multiple_email');

  // Create a user allowed to have multiple emails.
  $this->user = $this->drupalCreateUser(array('use multiple emails'));
  $this->drupalLogin($this->user);
}

par

/**
 * Modules to enable.
 *
 * @var array
 */
public static $modules = array('multiple_email');

function setUp() {
  // Set up basic Drupal install.
  parent::setUp();

  // Create a user allowed to have multiple emails.
  $this->user = $this->drupalCreateUser(array('use multiple emails'));
  $this->drupalLogin($this->user);
}

Malheureusement, cela ne suffira pas à corriger notre erreur. Cette dernière est dûe au fait que la permission que nous souhaitons attribuer à l'utilisateur n'existe pas car elle est censée être déclarée par notre module et que nous n'avons pas encore converti le hook_permission(). Afin d'avancer dans la conversion de nos tests, nous allons donc retirer cette permission et nous laisser un commentaire pour penser à la réintégrer lorsque nous commencerons à travailler sur cette partie du module. De toute manière, cette permission sera nécessaire pour faire passer les tests lorsque le module sera de nouveau fonctionnel avec tous ses contrôles d'accès.

function setUp() {
  // Set up basic Drupal install.
  parent::setUp();

  // Create a user allowed to have multiple emails.
  // @todo add 'use multiple emails' permission to $this->user ASAP.
  $this->user = $this->drupalCreateUser();
  $this->drupalLogin($this->user);
}

Autres erreurs bloquantes courantes

Les erreurs bloquantes sont celles qui interrompent le test et qui renvoient vers une erreur avant même d'afficher le rapport de test. Cette erreur étant renvoyée par le batch, le message n'est pas toujours très clair car le HTML qu'il contient est restitué en texte simple.

randomName()

Maintenant que nous avons retiré les permissions issues du module de la création des utilisateurs, nous pouvons constater de nouvelles erreurs. Par exemple, "Fatal error: Call to undefined method Drupal\multiple_email\Tests\UserTest::randomName() in /modules/multiple_email/src/Tests/UserTest.php on line 45" nous donne une nouvelle fois un résultat pertinent dans les Change records. Nous remplaçons donc toutes les occurences de 

$this->randomName()

en

$this->randomMachineName()

Panneau "propriété privée"
© Alexandre Dulaunoy

Accès aux propriétés des entités

L'erreur suivante est plus difficilement lisible malgré le fait d'avoir désactivé le debugger. Il s'agit visiblement d'une erreur SQL soulevée lors d'une tentative d'injection de données. La requête semble attendre un simple id mais reçoit en fait un objet entier de type Drupal\Core\Field\Plugin\Field\FieldType\IntegerItem. Cette fois-ci, même si un Change record existe bel et bien pour expliquer la raison de cette erreur, il ne sera pas aisé de le trouver. L'erreur est dûe à deux changements fondamentaux de la gestion des entités par Drupal 8. Premièrement, toutes les données d'une entité sont désormais des champs (Fields) soit définis de manière structurelle par l'entité (Base fields) et que l'on appelait propriétés soit, comme avant, ajoutés en fonction des besoins (Configurable fields). De plus, le cœur intègre désormais un équivalent des Entity Metadata Wrappers du module Entity API de Drupal 7 directement. Aini, $node->nid ne retournera plus l'identifiant du nœud mais un objet de type IntegerItem qui permettra d'accéder à sa valeur de la même manière qu'on accède aux valeurs de tous les autres champs. Selon la documentation il existe donc deux manières d'accéder à cette valeur, la première, générique, est $node->nid->value. La seconde, spécifique aux identifiants et plus généralement aux champs disposant de getters est $node->id().

Dans notre cas, les coupables sont 

$this->loggedInUser->uid
$this->loggedInUser->mail

que l'on remplacera partout respectivement par 

$this->loggedInUser->id()
$this->loggedInUser->getEmail()

Autres erreur non-bloquantes courantes

Les erreurs non-bloquantes sont celles qui apparaissent dans le rapport de test mais qui n'ont pas l'air d'être en rapport avec le fait que les tests échouent mais plus avec le fait qu'il y a un problème dans la manière dont les tests sont écrits.

drupalPost()

L'une des erreurs non-bloquantes la plus courante est liée à la méthode drupalPost() auparavant énormémént utilisée pour simuler des soumissions de formulaire. Elle prend généralement la forme d'une simple notice : "Argument 3 passed to Drupal\simpletest\WebTestBase::drupalPost() must be of the type array, string given, called in /modules/multiple_email/src/Tests/UserTest.php on line 136". Comme dans la plupart des cas précédents, ce sont les Change records qui vont nous apporter la raison de cette erreur. En effet, du fait que Drupal 8 se comporte maintenant nativement comme un web service REST, les requêtes de type POST ne sont plus réservées aux soumissions de formulaires. La méthode drupalPost() a été renommée drupalPostForm() et une nouvelle méthode drupalPost() a été créée pour permettre de tester les fonctionnalités liées aux webservices.

Nous remplacerons donc tous nos 

$this->drupalPost()

en

$this->drupalPostForm()

Conclusion

À ce stade vous devriez avoir résolu la grande majorité des problèmes communs de vos tests et, dans le cas contraire, avoir compris que ce sont les change records qui vous donneront toutes les informations nécessaires pour faire tourner vos tests. Dans le prochain épisode, nous aborderons la Configuration Management Intiative par le biais de la conversion des variables Drupal en objets de configuration simple.

Par admin

Tout savoir sur Drupagora du 19 juin 2015

La cinquième édition de Drupagora se déroulera le 19 juin à UPMC dans le 5ème arrondissement de Paris.

Comme les années précédentes, l'association Drupal France et Francophonie sera partenaire de l'événement et nous vous donnons rendez-vous sur notre stand.

Le programme vient d'être publié et les sujets sont de qualité sur différentes thématiques :

  • Une conférence plénière sur Drupal 8, dont la sortie est imminente
  • Un cycle dédié aux chefs de projets
  • Un cycle dédié aux retours d'expérience
  • Des conférences dédiées aux bonnes pratiques, au eCommerce et à l'utilisation intensive de Drupal

Par ailleurs, pour la première fois, vous découvrirez les « Drupagora d'or », permettant ainsi de voir de nombreux projets récompenser dans différentes catégories.

Enfin, comme nous sommes partenaire de l'événement, les membres de l'association peuvent bénéficier d'un tarif réduit à partir d'un code 'coupon' que nous possédons. Pour l'obtenir, vous devez nous contacter directement

Pour terminer, nous vous conseillons de vous inscrire rapidement car les places partent très vite

Tags : 
Par Artusamak
Julien Dubois

Porter son module en D8 - #2 Les tests

Porter son module en D8 - #2 Les tests
mar, 26/05/2015 - 08:00
DuaelFr

Dans un monde où l'on exige toujours plus de contrôle de la qualité des produits que nous utilisons au quotidien, il est normal que l'industrie logicielle ait dû se plier à la conception et la mise en œuvre de tests automatisés. Drupal n'échape pas à cette règle et c'est un gage de stabilité que de proposer des tests au sein de votre module.

Cet article est le deuxième de la série qui suit, étape par étape, la conversion d'un module contribué, Multiple E-mail Addresses, de Drupal 7 vers Drupal 8. Dans le premier article, nous avons évoqué les éléments à prendre en compte pour démarrer le portage et faire en sorte qu'il soit possible d'installer le module.

Contrôle qualité

Pyramide inversée des types de tests (unitaires, d'intégration et fonctionnels)Les tests logiciels sont catégorisés suivant plusieurs systèmes de classification différents. Personnellement, celle que j'utilise le plus est basée sur un concept de couches applicatives. Les tests unitiaires, au plus bas, assurent le bon fonctionnement des composants en testant, de manière isolée, que chaque sous partie du code produit le résultat escompté. Les tests d'intégration, plus rares, permettent de vérifier que les diverses parties de l'application communiquent correctement entre elles. Les tests fonctionnels ou tests de non-régression ont pour objectif de valider l'effectivité fonctionnelle de l'application et sont idéalement rédigés en collaboration avec le responsable fonctionnel (le client, dans le cadre d'une prestation de développement). Enfin, très rares encore aujourd'hui, les tests d'interface qui valident l'aspect et l'interactivité de l'interface graphique.

Drupal 7, de par son architecture, favorise l'utilisation de tests fonctionnels. En effet, le fait que le cœur de Drupal 7 soit encore très majoritairement procédural rend les tests unitaires très complexes car ils nécessitent de pouvoir isoler les composants à tester les uns des autres, ce qui est rendu plus facile par une architecture objet. Un exemple de test fonctionnel serait de vérifier qu'à la soumission d'un formulaire contenant des données erronées, un message d'erreur soit bien affiché.

La refonte complète du cœur de Drupal 8 a donc été pensée pour rendre l'écriture des tests fonctionnels plus simple car ils sont beaucoup plus rapides à exécuter et permettent un contrôle plus fin des composants qui pourraient avoir régressé. Le pincipe de ces tests est très simple. Il s'agit d'isoler au maximum un fragment du code, généralement contenu dans une méthode, et de l'exécuter avec des jeux de données couvrant tous les cas possibles en entrée et en contrôlant que les données en sortie sont conformes aux attentes. Pour réaliser ces tests, la communauté a choisi le moteur de test PHPUnit.

Dans le contexte du portage d'un module de Drupal 7 à Drupal 8 il est souhaitable de commencer par la conversion des tests. Ceci nous permettra au fil du travail de réécriture, d'identifier les points qui posent problème et de nous assurer que le fonctionnement existant ne soit pas altéré. Dans un second temps, si cela s'avère nécessaire, il sera toujours possible d'augmenter la couverture de tests en ajoutant, par exemple, des tests unitaires.

Anatomie d'un test fonctionnel

Dans la version 7 de Drupal, un module souhaitant implémenter des tests doit disposer d'un fichier <modulename>.test, référencé par une clef files[] du fichier <modulename>.info. Ce fichier peut contenir plusieurs classes PHP. Chacune correspond à une série de tests différents et chaque test représenté par une méthode dont le nom commence par "test" (ie. le fichier modules/block/block.test du cœur contient la classe BlockTestCase qui implémente la méthode testCustomBlock).
De plus, de nombreux modules ont besoin d'initialiser un environnement dans un état particulier pour que les tests soient effectifs. Pour y parvenir, ils proposent dans un répertoire "tests" un ou plusieurs modules dont le seul but est de mettre en place le contexte nécessaire aux tests décrits dans le fichier <modulename>.test. Par exemple, le module Field du cœur propose un module field_test définissant quelques permissions, un type d'entité, un type de champ, etc.

Dans la version 8 de Drupal, à l'heure actuelle (bêta 10), les fichiers <modulename>.test ont disparu au profit de fichiers respectant le standard PSR-4. On retrouve donc des classes de tests, une par fichier, dans les répertoires src/Tests, pour les tests fonctionnels, et tests/src/Unit, pour les tests unitaires. Comme pour Drupal 7, certains modules proposent des sous modules destinés à configurer un environnement de tests.

Convertir les tests

Le but de cet article n'est pas de faire en sorte que tous les anciens tests passent au vert car cela voudrait dire, en théorie, avoir terminé le portage. Nous allons nous concentrer sur le fait de rendre les tests exécutables par Drupal 8 et nous nous baserons ensuite sur les résultats pour faire progresser notre travail.

Astuce : un debugger comme xdebug peut être très utile dans cette phase du développement mais il faut savoir que le fait qu'il soit activé sur votre environnement va grandement augmenter le temps d'exécution de vos tests et potentiellement rendre les messages d'erreur plus confus. Il est donc recommandé de désactiver votre débugger à moins que vous en ayez absolument besoin.

Image du répertoire src/Tests

Diviser pour mieux régner

Comme indiqué précédemment, les tests dans D8 sont séparés dans des fichiers chargés automatiquement selon la norme PSR-4. Nous allons donc séparer toutes les classes présentes dans notre fichier <modulename>.test en autant de fichiers dans src/Tests.

Le module Multiple E-mail Addresses contient 4 classes de tests dans le fichier multiple_email.test : MultipleEmailAdminUserTestCase, MultipleEmailBasicUserTestCase, MultipleEmailUserTestCase et MultipleEmailLateInstallTestCase. Nous allons donc créer 4 fichiers contenant chacun une de ces classes que nous renommerons plus simplement.
La convention veut que le nom de la classe termine par "Test" pour différencier les classes de tests des classes fonctionnelles plus facilement dans les IDE proposant l'autocomplétion.

Nous obtenons donc 4 fichiers nommés respectivement AdminUserTest.php, BasicUserTest.php, UserTest.php et LateInstallTest.php. Chacun contient une classe PHP du même nom, déclarée dans le namespace Drupal\multiple_email\Tests.

Exemple :

class MultipleEmailUserTestCase extends DrupalWebTestCase {
  ...
}

devient

namespace Drupal\multiple_email\Tests;

class UserTest extends DrupalWebTestCase {
  ...
}

Une fois la séparation terminée, vous devriez voir apparaître vos tests dans l'interface de Simpletest (admin/config/development/testing) et vous devriez donc être en mesure de les exécuter. C'est d'ailleurs en essayant de les faire tourner que nous allons pouvoir détecter les prochaines corrections à y apporter.

La classe parente

À l'exécution de la classe UserTest nous obtenons immédiatement une erreur fatale PHP "Fatal error: Class 'Drupal\multiple_email\Tests\DrupalWebTestCase' not found in /modules/multiple_email/src/Tests/UserTest.php on line 17".

Comme souvent à partir de maintenant, la réponse se trouvera dans les Change records de Drupal 8 qui, avec une recherche sur le nom de la classe en erreur DrupalWebTestCase, nous donnera plusieurs résultats intéressants dont un qui traite précisément du renommage des classes de test.

On applique donc la recette trouvée dans le Change record et on renomme la classe parente de nos tests en WebTestBase, en important son namespace à l'aide d'une clause "use". 

namespace Drupal\multiple_email\Tests;

use Drupal\simpletest\WebTestBase;

class UserTest extends WebTestBase {
  ...
}

 

Maintenant que les erreurs structurelles ont été corrigées, les tests peuvent s'exécuter et nous allons devoir composer avec des erreurs pas forcément aussi directes. Le prochain article s'attardera sur certaines des erreurs les plus courantes rencontrées lors du portage des tests à Drupal 8 et vous donnera des pistes pour résoudre vos propres erreurs.

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: 

Pages