Planète

Par Mantalo Conseil
Benjamin Grapeloux
Agence web, Agence de Communication et Marketing en Dordogne (Aquitaine)

Nouveau site vitrine pour La Chanteracoise

La Chanteracoise passe la vitesse supérieure

Pour Sylvain Boucher aussi, les sites Internet formatés par les sociétés commerciales du Web ont démontré leur limite. Enfermée dans un contrat de service qui ne lui laissait d'autres choix que celui d'attendre son terme, La Chanteracoise attendait patiemment le moment de pouvoir se libérer... c'est chose faite :

  • Le nouveau site est en ligne,
  • Il permet une gestion autonome du contenu,
  • L'investissement consacré au développement du site étant réalisé, le seul coût annuel sera désormais celui de l'hébergement !

Dans la continuité de notre accompagnement marketing

L'ensemble des missions parallèlement consacrées à la stratégie marketing pour permettre à La Chanteracoise de développer son activité, a été mis à profit dans la structure du nouveau site.

La segmentation des gammes et des différents circuits de distribution qui référencent la marque a pu contribuer à la structure très cohérente du contenu. Les univers graphiques des gammes cohabitent également en parfaite harmonie pour porter la pertinence des packaging et des visuels produits.

Une formation à la gestion du contenu

L'équipe commerciale est désormais formée à toutes les interventions récurrentes qui permettront à La Chanteracoise d'enrichir et d'actualiser les pages de son site Internet. À partir d'une arborescence préalablement posée et des vocabulaires de taxonomie précisément définis par l'agence pour optimiser la navigation sur le site, le service marketing de La Chanteracoise a pu intégrer très simplement ses textes de présentation et d'information.

Pour renforcer le positionnement de la marque

Site web de la Biscotterie La Chanteracoise, adaptable pour tout support mobile et fixeComme très souvent lors de la création ou de la refonte du site Internet d'une entreprise commerciale, l'objectif est multiple :

  • toucher sur la toile les publics que cherche à prospecter la marque,
  • impacter le marché par l'attractivité et l'amplitude des gammes de produits,
  • lier une relation professionnelle avec les réseaux de distribution et centrale de référencement,
  • communiquer ses valeurs et son engagement auprès des clients finaux,
  • contribuer au développement des ventes et des parts de marché.

Convaincu par les résultats très significatifs constatés à la suite des premières actions préconisées par notre agence, Sylvain nous a naturellement confié son projet Web en connaissance de cause.

Drupal pour voir plus loin

À celles et ceux qui imaginent que la puissance de Drupal implique un back office très complexe, la facilité et la rapidité avec lesquelles l'équipe de La Chanteracoise s'est appropriée les outils de publication démontrent qu'il n'en est rien ! Il appartient à l'agence de se mettre un minimum à la place de son client pour :

  • configurer un espace d'administration qui soit à la fois fonctionnel et agréable,
  • faire en sorte que la gestion du contenu soit un plaisir,
  • adapter les accès, les rôles et les droits des utilisateurs aux besoins avérés d'interventions récurrentes sur le contenu.

Côté public, la richesse et la diversité de Drupal et de ses nombreux modules ouvrent la voie toute grande à une ergonomie très favorable pour l'interactivité entre les contenus, l'accessiblité et la navigation mobile.

Bon, assez parlé de communication ! Envie de faire croustiller vos petits déjeuners et vos goûters gourmands ? Direction la-chanteracoise.fr !

Par juliendubreuil
julien dubreuil
Depuis 2009 maintenant, je développe avec le CMS/CMF Drupal. J’étais à la recherche d’un framework capable de remplacer un projet et je n’ai jamais arrêté de m’en servir depuis ce moment.

Drupal Commerce, maitriser votre checkout

Drupal Commerce configuration du checkout

Une des demandes récurrentes de la part des utilisateurs de Drupal Commerce est la possibilité de personnaliser le checkout. Que ce soit pour changer les étapes du checkout, ou pour recueillir des données supplémentaires, l’API de Drupal Commerce permet de répondre à ce besoin facilement.

Drupal Commerce vient avec deux concepts concernant le checkout, les Pages et les panes. Les “pages” permettent l’affichage et la configuration des différentes pages du checkout, comme par exemple la page de paiement, de livraison ou encore comme la page de résumé de commande. Ces pages contiennent des “panes”, permettant d’interagir avec le client, comme illustre la saisie de l’adresse ou du numéro de carte de crédit dans le checkout.

Attention toutefois, lorsque vous rallongez votre checkout, vous complexifiez le processus d’achat et augmentez les risques de perte de clients. Incontestablement, la bonne pratique est d’avoir le checkout le plus simple et court possible, néanmoins il existe certains cas où il faut déroger à la règle.

Ordonner les étapes de votre checkout

La façon la plus simple d’ordonner les étapes de votre checkout consiste à vous rendre sur l’interface d’administration de votre site dans la rubrique checkout settings de la section store > configuration

Cette page d’administration regroupe toutes les pages de votre checkout ainsi que les panes contenus dans chaque page. Drag’n dropable, vous pouvez déplacer un pane d’une page à une autre de façon à créer l’expérience utilisateur de votre choix.

Par défaut le checkout est découpé en 4 pages:
* Checkout : la page “Checkout”, est la première étape, elle permet la collecte des informations de base.
* Review order: la page “Review order” permet d’afficher un résumé de la commande avant la validation et la soumission du paiement.
* Payement : cette page, nommée “Payment”, est uniquement utilisée lorsque qu’une méthode de paiement est dite off-site.
* Checkout complete: la page “Checkout complete”, permet d’afficher une confirmation de commande au client.

Drupal Commerce checkout configurationDrupal Commerce checkout configuration

Ajouter des pages à votre checkout

Comme bien souvent, il existe deux façons de faire avec Drupal ou Drupal Commerce pour arriver à vos fins. Soit vous utilisez un module contrib, soit vous faites un peu de code custom.

Si vous souhaitez passer par un module, il vous faudra utiliser Drupal Commerce Checkout Pages qui vous permettra d’ajouter des pages depuis l’interface d’administration de votre site.

L’autre façon, consiste à utiliser l’API de Drupal Commerce en implémentant le hook_commerce_checkout_page_info() dans un module custom. Une fois créée votre page sera accessible dans l’interface d’administration. C’est de cette manière que sont créées les pages de Drupal Commerce. Pour plus d’information, rendez-vous dans le fichier commerce_checkout.api.php du sous module checkout.

Ajouter des panes à votre checkout

De la même manière que précédemment, il est possible de faire la même chose avec les panes.

Coté module vous pouvez vous baser sur Commerce extra panes afin d’afficher une ou plusieurs nodes dans votre checkout en guise d’information.

Coté code, il vous faudra implémenter le hook_commerce_checkout_pane_info() de façon à déclarer votre nouveau pane. Notez ensuite, que vous devrez créer vos callbacks, afin d’afficher les informations désirées.
Pour plus d’information, rendez-vous dans le fichier commerce_checkout.api.php du sous module checkout.

Le mot de la fin

Comme à l’accoutumée, il est simple de personnaliser le checkout de Drupal commerce que ce soit avec un module ou un peu de code custom. Encore une fois, attention de penser à l’expérience utilisateur de vos clients quand vous complexifiez le checkout.

Par Artusamak
Julien Dubois

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

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

Vous avez pu lire dans le billet précedent comment passer de la vision aux stories. Voyons maintenant comment gérer ce qu'il va se passer au démarrage du premier sprint et de tous ceux qui suivront : la sprint définition.

Pour les plus pressés d'entre vous qui ne veulent pas profiter du fun de l'article, direction le TL;DR.

A quoi sert la sprint définition ?

Le but de l'exercice est que l'équipe constitue la liste de ce qu'elle va avoir à faire au cours du sprint. Pour cela, le product owner passe en revue la liste des stories du backlog produit de la plus prioritaire à la moins prioritaire. Pour chaque story, l'équipe va passer en revue les critères d'acceptation et identifier les taches qui en découlent. L'exercice va donner lieu à des échanges entre le product owner et les membres de l'équipe, et cette dernière va débattre de la faisabilité technique, des pistes possibles pour réaliser le besoin.
Ayez toujours à l'esprit les capacités de Drupal dans vos échanges car la maîtrise de l'outil vous épargnera de gaspiller votre temps en développements futiles.
La sprint définition est le moment durant lequel l'équipe doit comprendre chaque pixel du projet. Toutes les questions doivent être posées au cours de ce rituel car ça n'est pas une fois que l'implémentation démarrera qu'il faudra qu'elle se demande à quoi servent certains boutons / portions d'une page.

Les choix d'implémentation

Lorsque les stories sont passées en revue, l'équipe a le droit de rajouter des stories techniques, de débattre des priorités si elle pense que certaines choses doivent se faire avant d'autres. L'une des forces de l'agilité étant le principe d'itérations, le groupe est fortement invité à proposer toutes les pistes qui lui viendront à l'esprit afin de produire le plus de valeur ajoutée en un minimum de temps. L'écosystème des modules Drupal est très bon à ce petit jeu là, nous ne pouvons que vous encourager à vous en servir afin de proposer au product owner plusieurs options et de lui expliquer clairement ce qui serait faisable / non faisable comparé à sa demande initiale. Le but étant de toujours aller au plus vite à un premier résultat pas toujours parfait mais qui fait le travail et en se donnant la possbilité de choisir par la suite si le résultat constaté est satisfaisant ou si du temps supplémentaire doit être investi pour l'affiner.

Dimensionner les stories

Une fois que l'équipe n'a plus de questions sur le périmètre de la story fonctionnelle et qu'elle pense avoir son plan de bataille pour l'implémentation (pas besoin de noter tous les détails, vous pouvez vous limiter aux options / pistes possibles pour le développement) le jeu du poker planning démarre. Que vos espoirs de devenir millionnaire en jouant aux cartes dans des saloons retombent car il n'en est rien :  le concept est le suivant, tous les équipiers relisent les taches listées et réfléchissent à une taille à donner à cette story.
On ne va pas mesurer le temps que cela prend de faire la réalisation (un junior et un senior ne prendraient probablement pas autant de temps) mais on va estimer l'effort que cela implique. Pour se faire, on utilise une unité abstraite, les points de complexité.
Pour éviter les dilemmes on s'inspire de la suite de Fibonnacci, ce qui donne la liste de valeurs possibles suivante : 1, 2, 3, 5, 8, 13 puis on lui ajoute les valeurs 20, 40, 100, ? et "PAUSE" pour permettre à chacun d'indiquer que quelque chose est très gros, impossible à mesurer au vue de ses connaissances ou qu'il a besoin d'une pause avant d'y arriver.

Lorsque vous allez choisir la complexité d'une story, sa valeur absolue a peu d'importance. Ce qui va compter c'est que ce que vous allez estimer à 5 représente toujours la même chose. La story la plus difficile à estimer reste la première car on travail par la suite par comparaison. "Cette story pour laquelle nous votons 3 est-elle vraiment aussi complexe que la #651 pour laquelle on avait déjà voté 3 et qui nécessitait une gestion des droits fines en plus ?".
De la même façon l'effort doit être pris en compte. Si on évalue par exemple la création d'un type de contenu à 1, si l'un d'entre eux a 70 champs, peut être allons nous évaluer l'effort à 2 ou 3.


Partager les points de vue

L'estimation de la taille des stories se fait en simultané pour chacun des coéquipiers, tous ont devant eux un jeu de cartes d'estimations (d'où le nom de planning poker) et l'abattage des estimations doit se faire au même moment une fois que tout le monde a pris le temps de trouver son estimation (et poser les dernières questions si nécessaire). L'abattage révèle souvent des surprises (et des fous rires !) et suscite des échanges. "Pourquoi as-tu voté 2 ? C'est super compliqué de faire la couche d'abstraction, rappelles toi du projet Superfish !", "Wow, 5, vraiment ? On utilise Views Megarow et c'est parti, ça nous prendra peu de temps de construire cette interface".
Les points de vue seront donc confrontés, permettant de faire émerger des choses compliquées dont tout le monde n'avait pas conscience ou en apportant de la réassurance via la découverte de techniques / savoir-faire acquis par le passé et oubliés par certains.
Lorsque les votes sont vraiment différents (2 VS 8 par exemple) il y a une période d'échanges pour comprendre la source d'un tel écart, puis l'équipe revote jusqu'à ce que les estimations soient proches (et on prendra toujours la plus pessimiste par principe). Il est important de noter que passée une certaine taille, la faisabilité d'une story devient un risque. Si la complexité de plusieurs stories est supérieure ou égale à 8 il faut probablement envisager de découper les stories en plusieurs stories de taille inférieure afin de toujours s'assurer que vous  livre quelque chose. Si les estimations chiffrées posent problème, vous pouvez changer d'unité, XS, S, M, L, XL, XXL etc (ou libre à vous d'inventer la votre)

Une fois qu'une story est dimensionnée elle rejoint le backlog de sprint et on passe à la suivante. L'exercice se répète jusqu'à ce que l'équipe estime avoir suffisamment de travail pour la durée du sprint. Et ce choix est très important, en effet, l'équipe s'engage à livrer tout ce qu'elle a intégré à son backlog de sprint. Si des choses ne sont pas terminées à la fin de l'itération il faudra en trouver la cause pour que ça ne se reproduise pas. C'est donc une promesse faite, vis à vis du product owner mais aussi vis à vis de soi même. La capacité de l'équipe à respecter ses engagements déterminera sa vélocité. Le fait de livrer toutes les 2 semaines rend le projet excitant car on mesure les progrès d'un sprint à l'autre.

Vous l'aurez compris, les journées de sprint définition sont des journées qui sont bien remplies, alors préparez-vous en ramenant le jus de fruit, les croissants et des barres de céréales et en faisant une bonne nuit de sommeil la veille. Gardez l'exercice fun, veillez à ce que tout le monde donne sont avis et votre sprint se déroulera bien.

TL;DR

  • Au cours de la sprint définition l'équipe s'approprie le projet / la vision
  • C'est pendant la sprint définition que les questions se posent, une fois passée il est trop tard et on rentre dans l'implémentation
  • L'univers contrib de Drupal permet de faire beaucoup de choses pour un faible investissement
  • Profitez des itérations pour proposer une base fonctionnelle non parfaite mais satisfaisante puis demandez-vous s'il faut aller plus loin
  • Utilisez le planning poker pour quantifier l'effort nécessaire à la réalisation des stories
  • Apprenez à estimer par comparaison
  • Echangez afin de vous assurer que vous êtes tous sur la même longueur d'onde
  • Respectez vos engagements lorsque vous constituez votre backlog de sprint
  • Multipliez les petites stories plutôt que d'en avoir de très grosses.
  • Assurez-vous de toujours livrer quelque chose.
Par anavarre

Meetup Drupal Lyon - Présentation sur la sécurité

Pour le dernier meetup Drupal Lyon avant la coupure de l'été, j'ai fait une présentation sur la sécurité. Puisque le panel est assez hétérogène et qu'on parle aussi bien à des nouveaux venus sur Drupal qu'à des experts, je me suis dit qu'il serait intéressant de faire une présentation à la fois high-level et qui récapitule un ensemble de bonnes pratiques sur la sécurité qu'on a parfois tendance à oublier. L'idée principale c'est : ne pensez pas être "nul" en sécurité ou pas assez expert pour en parler ou vous y coller.

Par Mantalo Conseil
Benjamin Grapeloux
Agence web, Agence de Communication et Marketing en Dordogne (Aquitaine)

Généralités sur la gestion de contenus Drupal

Avant d’écrire : 7 étapes

  1. Se documenter sur l’environnement du sujet à aborder 
  2. Définir le type de contenu à utiliser
  3. Déterminer les objectifs
  4. Délimiter les cibles
  5. Élaborer le plan
  6. Rédiger
  7. Illustrer

Un usage spécifique à chaque type de contenu Drupal 

Il existe différents types de contenus, adaptés à chaque type d'information du site (page, article, billet de blog, client, agents, partenaires, biens, slider…). Chaque contenu possède un usage spécifique.

Accès 

Par  le menu : "Contenu"

Trier et retrouver des contenus

  • Il est possible de trier le contenu en sélectionnant des items et cliquer sur “Appliquer / Filtrer”
  • Annuler le tri en cliquant sur “Réinitialiser”

Agir sur des contenus existants

La liste de contenus propose différentes actions : 

  • en cliquant sur le titre du contenu → affiche le contenu côté “public” du site.
  • modifier → pour modifier le contenu dans l’administration
  • supprimer → pour supprimer définitivement le contenu
  • cloner → pour dupliquer un contenu dans l’administration (cf rubrique ci-dessous)

Publier un contenu

  • Par défaut, un contenu créé ou cloné possède le statut “non publié” c’est à dire qu’il n’est pas visible pour les internautes.
  • Publier un contenu en cliquant sur “publier” dans les “Options de publication” de l’encadré du pied de page.

Cloner un contenu

Pour créer un contenu à partir d’un contenu existant (s’en servir de trame/modèle)

  • Ouvrir un contenu existant
  • cliquer sur “Cloner un contenu”
  • Par défaut, le nom donné à un contenu cloné est “Clone de…”. Donner un nouveau titre au contenu
  • “Enregistrer”

Tags: 

Nous abordons dans notre dossier Administrer un site Drupal la création de différents types de contenu sous Drupal MantaloTonic (pages, articles, produits…)

Par Artusamak
Julien Dubois

Drupal et Scrum depuis les tranchées - Constitution du backlog produit

Drupal et Scrum depuis les tranchées - Constitution du backlog produit

Une fois après avoir sauté de joie en apprenant que c'est avec nous que notre client tant convoité veut travailler, il faut se remettre au travail pour constituer la matière que les développeurs vont exploiter au moment de produire. Il va dès lors falloir que nous convertissions le cahier des charges de notre client en stories. Bonne nouvelle c'est à cela que sert le sprint 0.

Pour les gens pressés : TL;DR.

De la vision aux stories

Le sprint 0 est un sprint particulier qui ne ressemble pas aux autres, c'est celui par lequel tout débute et qui va servir à préparer la matière dont l'équipe a besoin pour démarrer le premier sprint. Au cours du sprint 0 nous allons commercer par formaliser la vision du projet. La vision est la verbalisation de pour quoi et pour qui ce projet prend vie et va nous servir de cap lorsqu'il faudra arbitrer entre deux décisions (laquelle des deux options nous permet de servir au mieux la vision ?).

Il est ensuite possible de dresser le portrait de quelques personas, cette étape n'est pas obligatoire. Les personas sont l'incarnation des profils type d'utilisateurs de notre système, on dresse leur portrait-robot et leur donne un petit nom, ce qui rend plus simple dans nos stories de désigner Mélissa ou Philippe lorsque l'on évoque un administrateur ou un contributeur à notre site Drupal.

Nous voilà fin prêts à passer en revue le périmètre fonctionnel du projet. On va commencer par lister les grands sujets du projet identifiés dans le chiffrage ou le cahier des charges puis, pour chacun de ces domaines, détailler la liste des fonctionnalités. Toutes ces fonctionnalités ne sont pas encore des stories complètes, elles ne sont que leur titre. Nous vous recommandons au cours du sprint 0 d'essayer de dresser une liste assez exhaustive des fonctionnalités pour se rendre compte de l'ampleur du travail. Une fois cette liste établie il faut la prioriser par ordre de valeur ajoutée pour l'utilisateur final de la plus importante à la moins importante. Lorsque cette partie du travail est terminée, il suffit de repasser en revue les fonctionnalités les plus importantes pour en faire de vraies stories. C'est le moment où nous allons préciser les critères d'acceptation et rédiger la description des stories reprenant le modèle "En tant que [nom du persona ou de l'utilisateur] je peux [action] afin de [but]" .

Les critères d'acceptation sont la liste des tests que le développeur et le client vont dérouler lorsqu'ils vont valider qu'une fonctionnalité remplie ses besoins. Les critères d'acceptation listent ce que doit et ne doit pas faire une story. Si par exemple des validations de format, des messages d'erreur / de confirmation doivent apparaitre il faut le préciser à ce moment là.

N'oubliez pas qu'au cours de votre sprint 0 nous ne devons pas écrire la liste exhaustive des stories détaillées de votre projet (titre, description et critères d'acceptation), ce serait un travail titanesque et surtout abérant car la liste des priorités lors du sprint 0 ne sera probablement pas la même que lors du sprint 4 (autant éviter de travailler pour rien).
Il faut se contenter de préparer un nombre suffisant de stories pour que l'équipe ait du travail au cours du sprint 1 et nous assurer que le client s'est familiarisé avec le concept de story en mettant l'accent sur les critères d'acceptation qui seront la guarantie que nous nous entendons sur le fait qu'une fonctionnalité est terminée.


Drupal impose ses propres besoins

Il ne faut pas non plus omettre qu'au cours du sprint 0 des stories techniques doivent être intégrées, votre client doit comprendre que prévoir du temps pour concevoir une API, un composant technique important de son application, etc sont des étapes nécessaires toutes aussi indispensables que des choses directement utilisées par les utilisateurs finaux.

En plus de cela, Drupal va introduire ses propres stories telles que la gestion de l'arborescence du projet, le modèle des URLs à réécrire, les permissions, l'identification de view modes...
Rappelons-nous que notre client ne connait pas Drupal, si nous attendons de lui qu'il nous livre une liste de champs pour des types de contenu nous pourrions lui fournir un livrable d'exemple pour qu'il sache comment nous aider à avancer en économisant plusieurs aller retours.

Pensons à prévoir des stories (et du temps (une demie journée) si nous faisons cela pendant le sprint 0) pour la mise en place du dépôt, des éventuels scripts de déploiement ou de la configuration spécifique que pourrait nécessiter le processus d'industrialisation.

Cette première étape est l'occasion de rappeler à notre client que nous allons travailler ensemble (et qu'il va devoir travailler lui aussi) et que nous n'allons pas être un prestataire qu'il se contente de piloter. Ah et bien entendu nous pouvons dès maintenant lui annoncer qu'il sera en retard pour livrer ses contenus !

TL;DR

  • Votre interlocuteur doit connaitre son projet et être décisionnaire pour avancer
  • Le Cahier des Charges est important car c'est la matière première à partir de laquelle on va structure le backlog produit initial
  • Rien ne sert de se précipiter, il suffit d'avoir un backlog bien préparé pour le sprint 1, il restera du temps pour l'élargir et le compléter
  • Ne pas négliger les critères d'acceptation qui sont la garantie que vous savez comment faire les choses et que lorsque les stories seront testées vous en aurez la même lecture
  • Ne pas oublier que Drupal impose ses propres stories. (Création de stories de technique et limitation des users stories à l'aspect fonctionnel)
  • Aider le client autant que possible en lui proposant des exemples lorsque vous attendez des livrables de sa part.
Par Marc Delnatte
Akabia

5 étapes indispensables pour un bon référencement onsite !

Pour bien référencer son site, il faut préalablement avoir étudié les mots clés sur lesquels vous souhaitez vous positionner. Après avoir réalisé cette minutieuse étude, vous pourrez vous attaquer à l’optimisation on-site.







Pourquoi choisir (ou pas) Drupal ?







Non, ce billet ne va pas vous proposer un comparatif des trois principaux CMS du marché, à savoir Wordpress, Joomla et Drupal. Parce que ce comparatif serait périmé au bout de quelques mois. Et parce que les fonctionnalités offertes par ces CMS tendent à se rapprocher de plus en plus, du fait d'une émulation réciproque. Mais alors, qu'est-ce qui peut différencier aujourd'hui ces CMS ? Essayons de faire un panorama des utilisations actuelles de ces CMS.

Thème 
Drupal
Drupal 7
Drupal 8

Par admin

DrupalFR vous invite au PHP Tour 2014

Le "PHP Tour" est l'événement tournant qu'organise l'AFUP (Association Française des Utilisateurs de PHP) et pour la troisième édition, celui-ci s'arrêtera à Lyon les 23 et 24 juin.

Il s'agit d'un rendez-vous incontournable autour du langage PHP, avec quelques têtes d'affiches, comme :

  • Rasmus Lerdorf, intitulée "Coding and Dreaming – PHP in 2014", soit un tour d’horizon des performances excitantes que permet désormais PHP 5.5.
  • Julien Pauli, sur "YooopeeCache", ou comment installer, configurer et profiter de OPCache, le cache d’OPCode par défaut depuis PHP5.5.
  • Pascal Martin sur "PHP 5.3 à PHP 5.6 : no pain but gain !", une conférence technique pour appréhender les changements de versions de PHP 5 en toute tranquillité !

De plus, les membres de l'association Drupal France et Francophonie peuvent bénéficier d'une remise sur le prix de l'entrée. Pour cela, il suffit d'envoyer un email au bureau pour que l'on vous communique le code "coupon".

Alors, vous pouvez vous rendre sur :

Enfin, de nombreuses surprises vous attendent comme les cliniques co-organisés par les sponsors, une soirée communautaire, etc...

Par juliendubreuil
julien dubreuil
Depuis 2009 maintenant, je développe avec le CMS/CMF Drupal. J’étais à la recherche d’un framework capable de remplacer un projet et je n’ai jamais arrêté de m’en servir depuis ce moment.

Yaml, le format de configuration

Yaml, le format de configuration

L’une des premières choses que vous allez remarquer en regardant le code de Drupal 8, est le nouveau format de configuration. Terminé les extensions en .info, maintenant toute la configuration réside dans des fichiers .yml écrits au format YAML (YAML Ain’t Markup Language).

Aussi facile à lire que précédemment, il permet plus de choses et s’est imposé comme l’un des formats de standardisation dans plusieurs langages de programmation, tels que C, Perl et Python. L’une des grandes décisions prise pour Drupal 8 a été de standardiser le plus possible et de réutiliser des composants existant et fiables de façon à se concentrer sur autre chose. Ainsi le format YAML remplacera nos bons vieux fichiers maison.

L’ancienne version du fichier .info du module block:


1
2
3
4
5
6
7
8
# Drupal 7 block.info
name = Block
description = Controls the visual building blocks a page is constructed with. Blocks are boxes of content rendered into an area, or region, of a web page.
package = Core
version = VERSION
core = 7.x
files[] = block.test
configure = admin/structure/block

La nouvelle version du fichier info du module block au format YAML


1
2
3
4
5
6
7
8
# Drupal 8 block.info.yml
name: Block
type: module
description: 'Controls the visual building blocks a page is constructed with. Blocks are boxes of content rendered into an area, or region, of a web page.'
package: Core
version: VERSION
core: 8.x
configure: admin/structure/block

Comme vous pouvez le voir, les deux fichiers sont similaires. La bonne nouvelle est que vous ne serez pas dépaysé en écrivant au format YAML.

Pour vous aider à comprendre les avantages et la structure de ce nouveau format, voici dans les grandes lignes à quoi ressemble la syntaxe. Si vous voulez en savoir plus, rendez-vous directement sur la page wikipédia ou sur la documentation Symfony 2

  • Les commentaires doivent être précédés par un #
  • La valeur Null peut être exprimée de deux façons, avec la chaîne de caractère null ou le symbole ~
  • Les booléens s’écrivent true ou false
  • Les chaînes de caractères doivent être entourées par des apostrophes. Néanmoins si votre chaîne de caractère contient une ou plusieurs apostrophes, vous pouvez utiliser les guillemets.
  • Les listes d’éléments peuvent être définies sur une seule ligne ou dans un bloc (sur plusieurs lignes). Utilisez un tiret pour ajouter un nouvel élément dans une liste.


1
2
3
4
5
# comment.info.yml
dependencies:
 - datetime
 - node
 - text

Ou si vous préférez, vous pouvez créer vos listes sur une seul ligne.


1
[datetime, node, text]

Les tableaux sont de simples objets au format clé:valeur.


1
2
3
4
5
6
7
# comment.info.yml
name: Comment
type: module
description: 'Allows users to comment on and discuss published content.'
package: Core
version: VERSION
core: 8.x

Il est possible d’imbriquer les tableaux, il suffit simplement d’ajouter une indentation à un tableau. Attention, les indentations doivent utiliser deux espaces et non pas des tabulations.


1
2
3
4
5
6
7
8
#block.routing.yml
block_admin_display:
  pattern: '/admin/structure/block'
  defaults:
    _content: '\Drupal\block\Controller\BlockListController::listing'
    entity_type: 'block'
  requirements:
    _permission: 'administer blocks'

Au final rien de méchant et rien de compliqué, l’intégration du format YAML ne vous donnera pas du fil à retordre. Cela aura juste pour conséquence d’unifier tous les fichiers de configurations en imposant un standard. Que ce soit pour la déclaration des modules, de fichiers de configuration en passant par le nouveau système de plug-in tout sera fait dans ce format.

Crédits Photo – Alessandro Prada

Comment Drupal est protégé contre les 10 plus importantes failles de sécurité







Dans le domaine de la sécurité, la réputation de Drupal n'est plus à faire. Interrogé sur les raisons de cette réputation, il est souvent indiqué que Drupal est sécurisé by design, c'est à dire depuis sa conception même. Autrement dit, dès le départ, Drupal a été conçu avec la notion toujours présente à l'esprit que le système doit être sûr et sécurisé. Regardons en détail comment Drupal, grâce à ses interfaces de programmations (API) si elles sont utilisées correctement, prend en compte chacune des failles de sécurité les plus importantes. Ces éléments de réponse proviennent du rapport publié régulièrement sur drupalsecurityreport.org.

Thème 
Sécurité Drupal
Prestataire
Spécialiste
Drupal

Par Artusamak
Julien Dubois

CMI : De la théorie...

CMI : De la théorie...

CMI, ou « Content Management Initiative » représente l’une des avancées majeures de Drupal 8 visant à répondre à un besoin semblant simple au premier abord : Apporter une solution permettant de synchroniser la configuration d’un site entre plusieurs instances.

Comme le disait Greg Dunlap, le leader du projet :

CMI hopes to separate management of your code and content once and for all! We want to make it possible to store your site’s configuration in a standard API separate from its content, soliving issues like feature management and content staging that are cumbersome in previous Drupal versions.”

Mais ça ressemble à quoi ?

Il s’agit principalement d’une API fournissant aux développeurs une manière simple, standardisée, de stocker de la configuration de telle sorte qu’elle soit déployable.
Pour l’utilisateur final, cela signifie que nous sommes désormais capables de créer et configurer un site sur un serveur (de développement, de préproduction) et de le « déplacer » ensuite en production cette même configuration.

Pour bien comprendre le fonctionnement, il faut d’abord clarifier deux notions que CMI utilise : Active storage et Staging Storage.

  • L’Active Storage est un espace, par défaut la base de données, où Drupal stocke la configuration courante du site.
  • Le Staging Storage est lui un espace, par défaut le système de fichier, où Drupal stocke la configuration qu’il va devoir importer.

Chaque changement entre le Staging et l’Active peut être visualisé dans l’administration de Drupal.

Examinons ensemble un exemple d’un fichier de configuration, ici le fichier définissant le type de contenu « Book » :

type: book
name: 'Book page'
description: '<em>Books</em> have a built-in hierarchical navigation. Use for handbooks or tutorials.'
help: ''
has_title: true
title_label: Title
settings:
  node:
    preview: 1
    options:
      status: true
      # Not promoted to front page.
      promote: false
      sticky: false
      revision: false
    submitted: true
status: true
langcode: en

Comme on peut le voir, la configuration reste très compréhensible et facile à lire. Le plus important à comprendre est que ces fichiers fonctionnent sur un mode déclaratif.

Qu'est-ce que le mode déclaratif ?

Voyons ce que nous dit Wikipedia :

La programmation déclarative est un paradigme de programmation. Il consiste à créer des applications sur la base de composants logiciels indépendants du contexte et ne comportant aucun état interne. Autrement dit, l'appel d'un de ces composants avec les mêmes arguments produit exactement le même résultat, quel que soit le moment et le contexte de l'appel.

En programmation déclarative, on décrit le quoi, c'est-à-dire le problème. Par exemple, les pages HTML sont déclaratives car elles décrivent ce que contient une page (texte, titres, paragraphes, etc.) et non comment les afficher (positionnement, couleurs, polices de caractères, etc.). Alors qu'en programmation impérative (par exemple, avec le C ou Java), on décrit le comment, c'est-à-dire la structure de contrôle correspondant à la solution.

Autrement dit, en simplifiant, on pourrait dire :

  • Programmation impérative : décris à la « machine » comment faire quelque chose, et il en résulte ce que vous escomptez.
  • Programmation déclarative : décris à la « machine » ce que vous souhaitez qu’il se passe, et laisse la machine trouver comment y arriver

CMI n’est pas features !

Si vous aviez l’habitude (et vous devez l’avoir !) d’utiliser le module Features, vous serez peut-être un peu perdu au début. En effet, il ne faut pas oublier le but initial de Features était de pouvoir packager des « trucs » ensemble afin qu’ils puissent être réutilisés.
Ce n’est pas du tout le but de CMI. Ici, on exporte systématiquement l’ensemble de la configuration de votre site, et non pas une petite section.

Pour résumer, CMI est donc un outil permettant de gérer la configuration de manière déclarative, versionnable, et déployable.

Prochaine étape, la pratique !

Par Artusamak
Julien Dubois

Keynote de Dries – Drupalcon Austin 2014

La keynote que Dries a tenu pour le lancement de la nouvelle édition américaine de la Drupalcon 2014 à Austin se résume à se demander ce que sera le web de demain et comment Drupal pourrait jouer un rôle dans cet écosystème.

Drupalcon Austin 2014C’est une question intéressante à se poser lorsque l’on constate que de plus en plus d’acteurs venus à Drupal commencent à faire marche arrière faute de libertés suffisantes avec Drupal 7 et d’une arrivée très tardive de Drupal 8. S’interroger sur ce à quoi ressemblera le web dans quelques années est une chose, mais s’inquiéter de savoir si Drupal fera partie de ce tableau en est une autre. La réponse est probablement non.

Mais il est intéressant de constater que l’évolution à laquelle on assiste auprès des acteurs du web est que les géants deviennent de plus en plus géants et qu’ils écrasent complètement les nouveaux venus. Il va falloir que les gens acceptent de se rebeller contre ça pour que l’équilibre d’internet ne soit pas en danger.

Il est presque déjà trop tard, Google décide actuellement de ne plus montrer certains sites, qu’en sera-t-il demain lorsqu’il aura aspiré toutes les données de vos sites et les montrera directement dans sa page de recherche sans vous renvoyer le moindre trafic ?

Dries pose cette question et se dit que Drupal pourrait avoir un rôle à jouer en vous permettant d’avoir entre les mains un outil permettant de créer un genre de plateforme riche à partir de laquelle le contenu pourrait être disséminé facilement selon le format dans lequel vous le consommeriez (article sur un PC, billet sur votre téléphone, etc).

Je trouve que cette keynote a le mérite de mettre en lumière ce problème pour lequel nous n’avons pas forcément conscience mais je reste sceptique sur le rôle que Drupal pourra jouer. Le pouvoir réside principalement sur le trafic plus que sur les moyens technologiques à disposition pour formater le contenu et adapter le message au visiteur. Drupal n’a pas d’emprise sur l’acquisition du trafic et l’on peut légitimement se demander comment s’affranchir d’un Google pour faire venir les visiteurs. C’est un acte citoyen de s’interroger sur ce point et sur nos habitudes de consommation, la réponse n’est pas simple mais il faudra accepter de soutenir des petits acteurs prometteurs faute de tous les voir disparaitre les uns après les autres.

Par admin

DrupalFR au CMS day 2014

Comme pour la troisième édition, l'association Drupal France et Francophonie (drupalfr) sera présente le 17 juin 2014 au CMS Day.

Il s'agit d'un événement consacré à la gestion de contenu open source (CMS), dont nous somme sponsor Bronze.

Pour l'édition 2014, le CMSday proposera plus de 30 tables rondes et ateliers.
Bien entendu, tout au long de la journée, vous pourrez également venir nous rencontrer pour échanger et parler du CMS Drupal.

CMS Day

Il est impératif de vous inscrire gratuitement pour obtenir votre badge.
Inscrivez-vous au CMS Day 2014

Trouver un prestataire Drupal







Vous avez un projet de site web et vous avez déjà identifié Drupal comme solution idéale ? Mais vous avez des difficultés pour trouver un prestataire Drupal ? Comment vous assurer le prestataire sera en mesure de vous développer un site internet dans le respect des règles de l’art ? Bref comment trouver un prestataire Drupal, ou comment s’assurer que le prestataire dispose effectivement des compétences nécessaires à la bonne maîtrise de Drupal ? Ce billet va essayer de vous donner quelques pistes pour vous permettre d'éviter quelques mauvaises surprises.

Thème 
Drupal
Spécialiste
Prestataire

Par Artusamak
Julien Dubois

Drupal 8 pour de vrai

Drupal 8 pour de vrai

Alors que Drupal 8 se profile doucement et promet des améliorations majeurs par rapport à Drupal 8, intéressons nous à ce temps avant l'apparation des premiers sites majeurs en Drupal 8.

Quel est la situation de la contrib ? Comment devons nous changer nos habitudes et que faire pour se tenir prêt à l'arrivée de Drupal 8 ?

Ensemble essayons de répondre à cette question "Quand est ce que je pourrais utiliser Drupal 8 en production ?"

 

Cette session est largement inspiré par celle de @Florian Lorétan : Drupal 8 for real

crédit image : http://www.greenhouseloft.com/

Illustration: 
Catégorie: 
Par Artusamak
Julien Dubois

La fin du .info

La fin du .info

L'arrivée prochaine de Drupal 8 marquera la mort d'un (des nombreux) aliens de Drupal : le fichier ".info".

Ce fameux ".info", indispensable à tout module, thème ou encore profil d'installation sera remplacé dans un fichier YAML.

Évidemment, la principale motivation de ce changement est de pouvoir assurer une certaine consistance avec le reste de drupal (le nouveau système de routage utilisera aussi des fichiers YAML). Et bien sûr, l'adoption de la norme YAML consiste également en un switch vers un format bien connu et surtout standard.

Ce changement se traduit donc par la conversion de tous les anciens fichiers ".info" en ".info.yml".

Pour la majorité des anciennes instructions, le simple remplacement des "=" en ":" fera le plus gros du boulot.
Pour toutes les déclarations qui avaient la forme de tableaux (c'est à dire, avec un "[]" dedans), la forme sera :

dependencies:
  - node

Autre exemple avec les feuilles de style, anciennement de la forme :

; Stylesheets
stylesheets[all][] = css/layout.css
stylesheets[all][] = css/style.css
stylesheets[print][] = css/print.css

Ceci deviendra :

# Stylesheets
stylesheets:
  all:
    - css/layout.css
    - css/style.css
  print:
    - css/print.css

Comme vous avez pu le voir dans l'exemple précédent, pour insérer un commentaire, il ne faudra plus utiliser un ";" mais un "#" en début de ligne.

Enfin, on note l'arrivée d'une nouvelle clé : "type". Celle-ci, obligatoire, aura pour valeur "module", "theme", ou encore "profile". Je crois que vous avez compris son fonctionnement là, non ?

Un exemple complet avec le thème "Seven".

Drupal 7 :

name = Seven
description = A simple one-column, tableless, fluid width administration theme.
package = Core
version = VERSION
core = 7.x
stylesheets[screen][] = reset.css
stylesheets[screen][] = style.css
settings[shortcut_module_link] = 1
regions[content] = Content
regions[help] = Help
regions[page_top] = Page top
regions[page_bottom] = Page bottom
regions[sidebar_first] = First sidebar
regions_hidden[] = sidebar_first

Drupal 8 :

name: Seven
type: theme
description: 'A simple one-column, tableless, fluid width administration theme.'
package: Core
version: VERSION
core: 8.x
stylesheets:
  screen:
    - style.css
stylesheets-override:
  - vertical-tabs.css
  - vertical-tabs-rtl.css
  - jquery.ui.theme.css
settings:
  shortcut_module_link: '1'
regions:
  content: Content
  help: Help
  page_top: 'Page top'
  page_bottom: 'Page bottom'
  sidebar_first: 'First sidebar'
regions_hidden:
  - sidebar_first
Par GoZ
Fabien CLEMENT

Trouvez la version de Drupal d'un site

Il y a plusieurs mois, j'ai mis en ligne un service qui vous permettra de savoir si un site fonctionne sous Drupal et sous quelle version.

Il y a 2 fonctionnements possibles:
- Soit les fichiers .TXT ne sont pas protégés ou le fichier CHANGELOG.txt n'a pas été supprimé, et c'est très facile.
- Soit il faut aller plus loin pour connaitre la version, et je me base alors sur le checksum des fichiers disponibles en clair (CSS et JS de drupal)

en lire plus

Par admin

Crash du site

Bonjour à toutes et à tous,

comme vous avez pu le constater le site a été inactif pendant plusieurs jours.
Il se trouve que le serveur hébergeant le site a crashé et que les disques durs ont été endommagés.

Les admins ont pu récupérer les données et remonter l'infra.
Tous les services ne sont pas encore revenus mais l'essentiel est là.

Bonne journée à tous et n'oubliez pas on se retrouve au Drupal Camp Soleil les 24 et 25 mai 2014 à Montpellier.

Pages