Planète

Par admin

Soutenez Cellou et souhaitez lui un bon anniversaire - Urgent

Drupal France soutient Cellou Diallo et demande au préfet de l’Hérault de lui permettre de rester en France.

Il n'est pas habituel que nous vous proposions de soutenir une personne, et ceci restera probablement très exceptionnel, mais nous apprécions Cellou que vous avez pu rencontrer à divers événements Logiciels Libres, et qui s'est impliqué dans les RMLL, le DrupalCamp Montpellier 2014, des sprints, ...

Vous pouvez lui souhaiter un bon anniversaire, 26 mai, en signant la pétition qui donne plus de détails sur sa situation critique sur https://www.change.org/p/m-pr%C3%A9fet-pour-l-annulation-de-l-oqtf-%C3%A...

Merci.

En page d'accueil : 
Par flocondetoile
Adhérent

Drupal 8 : les profils d'installation, introduction

Les profils d'installation sont la base, comme leur nom l'indique, pour installer Drupal. Mais aussi pour effectuer une première configuration lors de son installation. Cela peut aussi bien être une configuration de base, qu'une configuration avancée pour disposer par exemple d'un site prêt à l'emploi. L'utilisation de ces profils peut permettre aussi bien d'industrialiser la création de sites Internet, ou encore la création de fonctionnalités génériques et éviter ainsi de longues séances, répétitives, de configuration. Faisons un aperçu général du principe de fonctionnement des profils d'installation de Drupal 8.

Par flocondetoile
Adhérent

Le futur de Drupal 8

Lors de la keynote de la DrupalCon 2016 (Nouvelle Orléans), Dries Buytaert a fait un point sur l'état de Drupal. Cette keynote est particulièrement intéressante car elle a mis en perspective, et concrétisé, le fait que Drupal 8 dispose désormais d'un modèle et d'une architecture permettant une évolution fonctionnelle plus rapide que ses précédentes versions. Et elle a été l'occasion de formuler de nouvelles propositions, actant ce fait, que la sortie de Drupal 8 en version stable n'était pas l'aboutissement d'une refonte globale de son architecture, mais bien le commencement d'un nouvelle ère.

Revenons sur les moments forts de cette keynote.

Par Kgaut
Adhérent
Kevin Gautreau

Drupal 8 - Utiliser la Batch API dans un controller

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

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

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

Fonction de qui prépare le batch à traiter :

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

 

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

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

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

Par flocondetoile
Adhérent

Drupal 8 : Injecter un formulaire de contact dans un contenu en 5 étapes

Comment insérer un formulaire de contact dans un contenu de Drupal 8 ? Ou sur une page précise à un endroit précis ? Par défaut, les formulaires de contact créés disposent d'une page qui leur est dédiée.  Mais si nous souhaitons les utiliser par ailleurs. Après quelques recherches, j'ai presque cru qu'il faudrait écrire quelques lignes de code pour créer un Plugin spécifique. Mais non...

Par admin

DrupalCamp Nantes - 10, 11 et 12 juin 2016

Fichier attaché Taille
PDF iconCommuniqué de presse 545.08 Ko

Vous avez peut-être remarqué la bannière sur le site depuis un moment, formalisons cette annonce : c’est la seconde fois que cet évènement national se déroule à Nantes. Venez donc nous retrouver, échanger, apprendre et partager autour de Drupal. Cette édition 2016 se déroulera sur 3 jours, à l’Epitech Nantes, du vendredi 10 au dimanche 12 juin 2016.

3 jours rythmés par des conférences, des lightning talks et des ateliers
Au sein de l’Epitech de Nantes, les participants pourront assister à des conférences sur les journées de vendredi et samedi.
Pas d’hésitation, ni de choix, une seule conférence est donnée à la fois, ce qui permet à tous les participants de profiter des contenus riches de l’évènement. Sur ces deux jours plus d’une dizaine de sujets seront proposés, en plénière ou dans le cadre de discussions plus informelles en parallèle (lightning talks).
Le dimanche est réservé aux sprints et ateliers. Les contributeurs se regroupent, sur un sujet commun, permettant de faire avancer le CMS (développement pour Drupal 8 et Drupal 7, traduction en français, documentation, …).

Sprints, conférences et discussions sont accessibles à tous les niveaux techniques et fonctionnels, à tous les profils du développeur à l’utilisateur. Toutes ces rencontres se font dans la bonne humeur, des soirées étant aussi organisées les vendredi et samedi soirs.

Venez nombreux(ses) !

Horaires : de 9h à 18h30
Lieu : 5 Rue d'Alger, 44000 Nantes
Billet : entrée pour une journée 10€ (vendredi ou samedi). Entrée pour les 2 jours 15€ (repas du midi compris). Dimanche gratuit.
Contact presse :
Site : http://nantes2016.drupalcamp.fr/
Email : dcn2016@listes.drupalfr.org

En page d'accueil : 
Par admin

DrupalCamp Nantes - 10, 11 et 12 juin 2016

Fichier attaché Taille
PDF iconCommuniqué de presse 545.08 Ko

Vous avez peut-être remarqué la bannière sur le site depuis un moment, formalisons cette annonce : c’est la seconde fois que cet évènement national se déroule à Nantes. Venez donc nous retrouver, échanger, apprendre et partager autour de Drupal. Cette édition 2016 se déroulera sur 3 jours, à l’Epitech Nantes, du vendredi 10 au dimanche 12 juin 2016.

3 jours rythmés par des conférences, des lightning talks et des ateliers
Au sein de l’Epitech de Nantes, les participants pourront assister à des conférences sur les journées de vendredi et samedi.
Pas d’hésitation, ni de choix, une seule conférence est donnée à la fois, ce qui permet à tous les participants de profiter des contenus riches de l’évènement. Sur ces deux jours plus d’une dizaine de sujets seront proposés, en plénière ou dans le cadre de discussions plus informelles en parallèle (lightning talks).
Le dimanche est réservé aux sprints et ateliers. Les contributeurs se regroupent, sur un sujet commun, permettant de faire avancer le CMS (développement pour Drupal 8 et Drupal 7, traduction en français, documentation, …).

Sprints, conférences et discussions sont accessibles à tous les niveaux techniques et fonctionnels, à tous les profils du développeur à l’utilisateur. Toutes ces rencontres se font dans la bonne humeur, des soirées étant aussi organisées les vendredi et samedi soirs.

Venez nombreux(ses) !

Horaires : de 9h à 18h30
Lieu : 5 Rue d'Alger, 44000 Nantes
Billet : entrée pour une journée 10€ (vendredi ou samedi). Entrée pour les 2 jours 15€ (repas du midi compris). Dimanche gratuit.
Contact presse :
Site : http://nantes2016.drupalcamp.fr/
Email : dcn2016@listes.drupalfr.org

En page d'accueil : 
Par Kgaut
Adhérent
Kevin Gautreau

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

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

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

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

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

s'il n'est pas présent : 

composer require cweagans/composer-patches

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

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

exemple pour un patch pour mimemail :

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

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

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

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

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

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

composer update
composer install

 

Par Artusamak
Julien Dubois

Drupal 8 : Webservices REST

Drupal 8 : Webservices REST
Artusamak
lun 02/05/2016 - 09:46

Cet article est extrait de notre formation drupal 8 "de Drupal 7 à Drupal 8" à destination des développeurs. N'hésitez pas à nous contacter pour en savoir plus !

Les services web sont un principe permettant à des applications de communiquer entre elles à distance, via Internet, et ceci indépendamment des plates-formes et des langages sur lesquelles elles reposent.

Il n'y a donc pas de différence fondamentale entre l'interaction d'un navigateur avec une ressource et celle d'un service web avec une ressource. Ce qui diffère se situe au niveau du format de la représentation des données renvoyé dans la réponse : HTML pour les navigateurs, XML ou JSON pour les services web.

Un point rapide sur HAL

HAL, ou encore Hypertext Application Language, est un format fournissant une manière simple et consistante de fournir des liens entres diverses ressources d’une API.

HAL permet de rendre les APIs plus facilement explorables et d’une certaine manière d’intégrer directement la documentation de l’API dans cette dernière. Elle peut fournir la manière d'interroger une ressource liée à la ressource actuellement interrogée au sein même de la réponse. Exemples : les liens vers les pages précédente et suivante dans le cadre d’une ressource qui liste des contenus ou encore le lien vers l’édition du profil de l’utilisateur lorsque l’on récupère son profil pour consultation.

REST et Drupal 8

Dans le cœur de Drupal 8, les interactions avec les entités de contenu sont supportées via une interface REST. Par défaut, les méthodes HTTP supportées sont GET, POST, PATCH et DELETE.

Le module REST est dépendant du module Serialisation qui fourni les représentations JSON et XML des entités. D’autres représentations  sérialisées sont disponibles en activant le module HAL par exemple.

Le module REST de Drupal 8 ne possède aucune interface graphique. Les modifications et ajustements de configuration doivent s’effectuer directement en surchargeant les fichiers de configuration YAML de Drupal.

Récupération d’informations

L’opération la plus simple est la récupération des informations d’une entité.

Par défaut, l’ensemble des opérations sont disponibles sur les entités de contenu de type nœud, il est néanmoins possible de personnaliser ce comportement (par exemple, changer le format de sortie en json ou xml, ou encore rajouter une méthode d’authentification telle que oauth par exemple).

Pour ce faire, il faut tout d’abord exporter la configuration du module REST. La configuration de base devrait ressembler à ceci. (Configuration > Configuration synchronization  > Export > Single item)

<span class="token comment" spellcheck="true"># rest.settings.yml</span>
<span class="token comment" spellcheck="true"># Example configuration for enabling REST resources.</span>
<span class="token key atrule">resources</span><span class="token punctuation">:</span>
  <span class="token comment" spellcheck="true"># Enable the node resource.</span>
  <span class="token key atrule">'entity:node'</span><span class="token punctuation">:</span>
    <span class="token key atrule">GET</span><span class="token punctuation">:</span>
      <span class="token key atrule">supported_formats</span><span class="token punctuation">:</span>
        <span class="token punctuation">-</span> hal_json
      <span class="token key atrule">supported_auth</span><span class="token punctuation">:</span>
        <span class="token punctuation">-</span> basic_auth
  <span class="token comment" spellcheck="true"># Enable the taxonomy term resource.</span>
  <span class="token key atrule">'entity:taxonomy_term'</span><span class="token punctuation">:</span>
    <span class="token key atrule">GET</span><span class="token punctuation">:</span>
      <span class="token key atrule">supported_formats</span><span class="token punctuation">:</span>
        <span class="token punctuation">-</span> hal_json
      <span class="token key atrule">supported_auth</span><span class="token punctuation">:</span>
        <span class="token punctuation">-</span> basic_auth

Des modifications peuvent alors être apportées en modifiant ce fichier YAML puis en important à nouveau cette configuration dans Drupal.

Exemple : pour autoriser le format de données XML, la configuration de la ressource node sur la méthode GET deviendrait :

  <span class="token comment" spellcheck="true"># rest.settings.yml</span>
  <span class="token comment" spellcheck="true"># Enable the node resource.</span>
  <span class="token key atrule">'entity:node'</span><span class="token punctuation">:</span>
    <span class="token key atrule">GET</span><span class="token punctuation">:</span>
      <span class="token key atrule">supported_formats</span><span class="token punctuation">:</span>
        <span class="token punctuation">-</span> hal_json
        <span class="token punctuation">-</span> xml

À noter qu’un module de la communauté existe afin de fournir une interface graphique pour réaliser ceci : RestUI

Exemple de mise en oeuvre :

Après avoir créé un contenu, activez le module RESTFul Web Services ainsi que HAL

N’oubliez pas de configurer les permissions.

A présent, à l’aide d’un navigateur non connecté sur votre instance Drupal, rendez-vous à l’adresse “ http://d8.dev/node/1?_format=hal_json”.

Voici un exemple ce que vous obtiendrez.

(Le contenu est volontairement tronqué dans cet exemple)

Création de contenu

Afin de pouvoir créer du contenu à l’aide des modules de webservices de Drupal 8, il est impératif d’activer le module core HAL.

Comme il s’agit ici de création de contenu, cette opération va probablement devoir être sécurisée (seul un utilisateur possédant les droits de création de contenu doit être accepté). C’est pourquoi nous allons activer le module HTTP Basic Authentication qui fourni la méthode authentification “Basic” la plus simple.

Afin de créer un contenu, il convient de créer une requêtes sur l’adresse http://<site_drupal>/entity/<entity_type>.

Pour s’identifier, le client HTTP doit envoyer la requête en spécifiant l'en-tête HTTP « Authorization » et avec la valeur de connexion. Celle-ci est composée de la méthode utilisée (Basic) suivie de la représentation en Base64 du nom de l'utilisateur et du mot de passe séparés par le caractère « : » (deux-points).

Protection supplémentaire, il faut également fournir un en-tête HTTP « X-CSRF-Token ». Ce dernier est récupérable à l’adresse rest/session/token de votre site.

Il faut néanmoins rester vigilant car de nombreux contenus Drupal sont composés d’entités liées entres-elles. Par exemple, si l’on souhaite créer un commentaire, il faut pouvoir le lier à un utilisateur. Pour ce faire, il est nécessaire de renseigner ce lien grâce à l’entrée “ _links ” du JSON.

Afin de recréer ce lien, il est plus simple de tout d’abord effectuer un appel GET sur cette ressource et d’en étudier ses entrées “ _links ”.

Les entrées du tableau “ _links ” sont créées et normalisées par le module >HAL (voir premier paragraphe du chapitre).

Pour résumer

Requête

http://example.com/entity/node

Headers

Nom de l’en-tête

Valeur de l’en-tête

X-CSRF-Token

(récupéré via rest/session/token)

Authorization

Basic (Hash base 64 username/password)

Content-Type

application/hal+json

Corps
{
"_links": {
   "type": {
     "href": "http://example.com/rest/type/node/article"
   }
},
"title": {
   "value": "Test Article 2"
},
"type": {
   "target_id": "article"
}
}

Mise à jour de contenu

Il est également possible de mettre à jour des contenus grâce au verbe HTTP PATCH .

Afin de pouvoir créer du contenu à l’aide des modules de webservices de Drupal 8, il est impératif d’activer le module core HAL ainsi que HTTP Basic Authentication.

Afin de mettre à jour un contenu, il convient de créer une requête sur l’adresse http://<site_drupal>/node/<nid>.

À l’instar de la création de contenu, il est également nécessaire de passer les en-têtes HTTP « Authorization » et « X-CSRF-Token ».

Pour résumer

Requête

http://example.com/node/<nid>

Headers

Nom de l’en-tête

Valeur de l’en-tête

X-CSRF-Token

(récupéré via rest/session/token)

Authorization

Basic (Hash base 64 username/password)

Content-Type

application/hal+json

Corps
{
"_links": {
   "type": {
     "href": "http://example.com/rest/type/node/article"
   }
},
"nid": {
   "": {
     "value": "8"
   }
},
"type": {
   "target_id": "article"
},
"promote": {
   "value": "1"
},
"body": {
   "": {
     "value": "foo bar baz", "lang": "en"
  }
}
}

 

Suppression de contenu

A l'aide du verbe HTTP DELETE, il est bien sur possible de supprimer des entités. Le fonctionnement presque identique au méthodes précédentes.

Requête

https://example.com/node/<nid>

Headers

Nom de l’en-tête

Valeur de l’en-tête

X-CSRF-Token

(récupéré via rest/session/token)

Authorization

Basic (Hash base 64 username/password)

Par Artusamak
Julien Dubois

Drupal 8 : Webservices REST

Drupal 8 : Webservices REST
lun, 02/05/2016 - 09:46
Artusamak

Cet article est extrait de notre formation drupal 8 "de Drupal 7 à Drupal 8" à destination des développeurs. N'hésitez pas à nous contacter pour en savoir plus !

Les services web sont un principe permettant à des applications de communiquer entre elles à distance, via Internet, et ceci indépendamment des plates-formes et des langages sur lesquelles elles reposent.

Il n'y a donc pas de différence fondamentale entre l'interaction d'un navigateur avec une ressource et celle d'un service web avec une ressource. Ce qui diffère se situe au niveau du format de la représentation des données renvoyé dans la réponse : HTML pour les navigateurs, XML ou JSON pour les services web.

Un point rapide sur HAL

HAL, ou encore Hypertext Application Language, est un format fournissant une manière simple et consistante de fournir des liens entres diverses ressources d’une API.

HAL permet de rendre les APIs plus facilement explorables et d’une certaine manière d’intégrer directement la documentation de l’API dans cette dernière. Elle peut fournir la manière d'interroger une ressource liée à la ressource actuellement interrogée au sein même de la réponse. Exemples : les liens vers les pages précédente et suivante dans le cadre d’une ressource qui liste des contenus ou encore le lien vers l’édition du profil de l’utilisateur lorsque l’on récupère son profil pour consultation.

REST et Drupal 8

Dans le cœur de Drupal 8, les interactions avec les entités de contenu sont supportées via une interface REST. Par défaut, les méthodes HTTP supportées sont GET, POST, PATCH et DELETE.

Le module REST est dépendant du module Serialisation qui fourni les représentations JSON et XML des entités. D’autres représentations  sérialisées sont disponibles en activant le module HAL par exemple.

Le module REST de Drupal 8 ne possède aucune interface graphique. Les modifications et ajustements de configuration doivent s’effectuer directement en surchargeant les fichiers de configuration YAML de Drupal.

Récupération d’informations

L’opération la plus simple est la récupération des informations d’une entité.

Par défaut, l’ensemble des opérations sont disponibles sur les entités de contenu de type nœud, il est néanmoins possible de personnaliser ce comportement (par exemple, changer le format de sortie en json ou xml, ou encore rajouter une méthode d’authentification telle que oauth par exemple).

Pour ce faire, il faut tout d’abord exporter la configuration du module REST. La configuration de base devrait ressembler à ceci. (Configuration > Configuration synchronization  > Export > Single item)

<span class="token comment" spellcheck="true"># rest.settings.yml</span>
<span class="token comment" spellcheck="true"># Example configuration for enabling REST resources.</span>
<span class="token key atrule">resources</span><span class="token punctuation">:</span>
  <span class="token comment" spellcheck="true"># Enable the node resource.</span>
  <span class="token key atrule">'entity:node'</span><span class="token punctuation">:</span>
    <span class="token key atrule">GET</span><span class="token punctuation">:</span>
      <span class="token key atrule">supported_formats</span><span class="token punctuation">:</span>
        <span class="token punctuation">-</span> hal_json
      <span class="token key atrule">supported_auth</span><span class="token punctuation">:</span>
        <span class="token punctuation">-</span> basic_auth
  <span class="token comment" spellcheck="true"># Enable the taxonomy term resource.</span>
  <span class="token key atrule">'entity:taxonomy_term'</span><span class="token punctuation">:</span>
    <span class="token key atrule">GET</span><span class="token punctuation">:</span>
      <span class="token key atrule">supported_formats</span><span class="token punctuation">:</span>
        <span class="token punctuation">-</span> hal_json
      <span class="token key atrule">supported_auth</span><span class="token punctuation">:</span>
        <span class="token punctuation">-</span> basic_auth

Des modifications peuvent alors être apportées en modifiant ce fichier YAML puis en important à nouveau cette configuration dans Drupal.

Exemple : pour autoriser le format de données XML, la configuration de la ressource node sur la méthode GET deviendrait :

  <span class="token comment" spellcheck="true"># rest.settings.yml</span>
  <span class="token comment" spellcheck="true"># Enable the node resource.</span>
  <span class="token key atrule">'entity:node'</span><span class="token punctuation">:</span>
    <span class="token key atrule">GET</span><span class="token punctuation">:</span>
      <span class="token key atrule">supported_formats</span><span class="token punctuation">:</span>
        <span class="token punctuation">-</span> hal_json
        <span class="token punctuation">-</span> xml

À noter qu’un module de la communauté existe afin de fournir une interface graphique pour réaliser ceci : RestUI

Exemple de mise en oeuvre :

Après avoir créé un contenu, activez le module RESTFul Web Services ainsi que HAL

N’oubliez pas de configurer les permissions.

A présent, à l’aide d’un navigateur non connecté sur votre instance Drupal, rendez-vous agrave; l’adresse “ http://d8.dev/node/1?_format=hal_json”.

Voici un exemple ce que vous obtiendrez.

(Le contenu est volontairement tronqué dans cet exemple)

Création de contenu

Afin de pouvoir créer du contenu à l’aide des modules de webservices de Drupal 8, il est impératif d’activer le module core HAL.

Comme il s’agit ici de création de contenu, cette opération va probablement devoir être sécurisée (seul un utilisateur possédant les droits de création de contenu doit être accepté). C’est pourquoi nous allons activer le module HTTP Basic Authentication qui fourni la méthode authentification “Basic” la plus simple.

Afin de créer un contenu, il convient de créer une requêtes sur l’adresse http://<site_drupal>/entity/<entity_type>.

Pour s’identifier, le client HTTP doit envoyer la requête en spécifiant l'en-tête HTTP « Authorization » et avec la valeur de connexion. Celle-ci est composée de la méthode utilisée (Basic) suivie de la représentation en Base64 du nom de l'utilisateur et du mot de passe séparés par le caractère « : » (deux-points).

Protection supplémentaire, il faut également fournir un en-tête HTTP « X-CSRF-Token ». Ce dernier est récupérable à l’adresse rest/session/token de votre site.

Il faut néanmoins rester vigilant car de nombreux contenus Drupal sont composés d’entités liées entres-elles. Par exemple, si l’on souhaite créer un commentaire, il faut pouvoir le lier à un utilisateur. Pour ce faire, il est nécessaire de renseigner ce lien grâce à l’entrée “ _links ” du JSON.

Afin de recréer ce lien, il est plus simple de tout d’abord effectuer un appel GET sur cette ressource et d’en étudier ses entrées “ _links ”.

Les entrées du tableau “ _links ” sont créées et normalisées par le module >HAL (voir premier paragraphe du chapitre).

Pour résumer

Requête

http://example.com/entity/node

Headers

Nom de l’en-tête

Valeur de l’en-tête

X-CSRF-Token

(récupéré via rest/session/token)

Authorization

Basic (Hash base 64 username/password)

Content-Type

application/hal+json

Corps
{
"_links": {
   "type": {
     "href": "http://example.com/rest/type/node/article"
   }
},
"title": {
   "value": "Test Article 2"
},
"type": {
   "target_id": "article"
}
}

Mise à jour de contenu

Il est également possible de mettre à jour des contenus grâce au verbe HTTP PATCH .

Afin de pouvoir créer du contenu à l’aide des modules de webservices de Drupal 8, il est impératif d’activer le module core HAL ainsi que HTTP Basic Authentication.

Afin de mettre à jour un contenu, il convient de créer une requête sur l’adresse http://<site_drupal>/node/<nid>.

À l’instar de la création de contenu, il est également nécessaire de passer les en-têtes HTTP « Authorization » et « X-CSRF-Token ».

Pour résumer

Requête

http://example.com/node/<nid>

Headers

Nom de l’en-tête

Valeur de l’en-tête

X-CSRF-Token

(récupéré via rest/session/token)

Authorization

Basic (Hash base 64 username/password)

Content-Type

application/hal+json

Corps
{
"_links": {
   "type": {
     "href": "http://example.com/rest/type/node/article"
   }
},
"nid": {
   "": {
     "value": "8"
   }
},
"type": {
   "target_id": "article"
},
"promote": {
   "value": "1"
},
"body": {
   "": {
     "value": "foo bar baz", "lang": "en"
  }
}
}

 

Suppression de contenu

A l'aide du verbe HTTP DELETE, il est bien sur possible de supprimer des entités. Le fonctionnement presque identique au méthodes précédentes.

Requête

https://example.com/node/<nid>

Headers

Nom de l’en-tête

Valeur de l’en-tête

X-CSRF-Token

(récupéré via rest/session/token)

Authorization

Basic (Hash base 64 username/password)

Tags
Par Artusamak
Julien Dubois

Drupal 8 : Webservices REST

Drupal 8 : Webservices REST
Artusamak
lun 02/05/2016 - 09:46

Cet article est extrait de notre formation drupal 8 "de Drupal 7 à Drupal 8" à destination des développeurs. N'hésitez pas à nous contacter pour en savoir plus !

Les services web sont un principe permettant à des applications de communiquer entre elles à distance, via Internet, et ceci indépendamment des plates-formes et des langages sur lesquelles elles reposent.

Il n'y a donc pas de différence fondamentale entre l'interaction d'un navigateur avec une ressource et celle d'un service web avec une ressource. Ce qui diffère se situe au niveau du format de la représentation des données renvoyé dans la réponse : HTML pour les navigateurs, XML ou JSON pour les services web.

Un point rapide sur HAL

HAL, ou encore Hypertext Application Language, est un format fournissant une manière simple et consistante de fournir des liens entres diverses ressources d’une API.

HAL permet de rendre les APIs plus facilement explorables et d’une certaine manière d’intégrer directement la documentation de l’API dans cette dernière. Elle peut fournir la manière d'interroger une ressource liée à la ressource actuellement interrogée au sein même de la réponse. Exemples : les liens vers les pages précédente et suivante dans le cadre d’une ressource qui liste des contenus ou encore le lien vers l’édition du profil de l’utilisateur lorsque l’on récupère son profil pour consultation.

REST et Drupal 8

Dans le cœur de Drupal 8, les interactions avec les entités de contenu sont supportées via une interface REST. Par défaut, les méthodes HTTP supportées sont GET, POST, PATCH et DELETE.

Le module REST est dépendant du module Serialisation qui fourni les représentations JSON et XML des entités. D’autres représentations  sérialisées sont disponibles en activant le module HAL par exemple.

Le module REST de Drupal 8 ne possède aucune interface graphique. Les modifications et ajustements de configuration doivent s’effectuer directement en surchargeant les fichiers de configuration YAML de Drupal.

Récupération d’informations

L’opération la plus simple est la récupération des informations d’une entité.

Par défaut, l’ensemble des opérations sont disponibles sur les entités de contenu de type nœud, il est néanmoins possible de personnaliser ce comportement (par exemple, changer le format de sortie en json ou xml, ou encore rajouter une méthode d’authentification telle que oauth par exemple).

Pour ce faire, il faut tout d’abord exporter la configuration du module REST. La configuration de base devrait ressembler à ceci. (Configuration > Configuration synchronization  > Export > Single item)

<span class="token comment" spellcheck="true"># rest.settings.yml</span>
<span class="token comment" spellcheck="true"># Example configuration for enabling REST resources.</span>
<span class="token key atrule">resources</span><span class="token punctuation">:</span>
  <span class="token comment" spellcheck="true"># Enable the node resource.</span>
  <span class="token key atrule">'entity:node'</span><span class="token punctuation">:</span>
    <span class="token key atrule">GET</span><span class="token punctuation">:</span>
      <span class="token key atrule">supported_formats</span><span class="token punctuation">:</span>
        <span class="token punctuation">-</span> hal_json
      <span class="token key atrule">supported_auth</span><span class="token punctuation">:</span>
        <span class="token punctuation">-</span> basic_auth
  <span class="token comment" spellcheck="true"># Enable the taxonomy term resource.</span>
  <span class="token key atrule">'entity:taxonomy_term'</span><span class="token punctuation">:</span>
    <span class="token key atrule">GET</span><span class="token punctuation">:</span>
      <span class="token key atrule">supported_formats</span><span class="token punctuation">:</span>
        <span class="token punctuation">-</span> hal_json
      <span class="token key atrule">supported_auth</span><span class="token punctuation">:</span>
        <span class="token punctuation">-</span> basic_auth

Des modifications peuvent alors être apportées en modifiant ce fichier YAML puis en important à nouveau cette configuration dans Drupal.

Exemple : pour autoriser le format de données XML, la configuration de la ressource node sur la méthode GET deviendrait :

  <span class="token comment" spellcheck="true"># rest.settings.yml</span>
  <span class="token comment" spellcheck="true"># Enable the node resource.</span>
  <span class="token key atrule">'entity:node'</span><span class="token punctuation">:</span>
    <span class="token key atrule">GET</span><span class="token punctuation">:</span>
      <span class="token key atrule">supported_formats</span><span class="token punctuation">:</span>
        <span class="token punctuation">-</span> hal_json
        <span class="token punctuation">-</span> xml

À noter qu’un module de la communauté existe afin de fournir une interface graphique pour réaliser ceci : RestUI

Exemple de mise en oeuvre :

Après avoir créé un contenu, activez le module RESTFul Web Services ainsi que HAL

N’oubliez pas de configurer les permissions.

A présent, à l’aide d’un navigateur non connecté sur votre instance Drupal, rendez-vous à l’adresse “ http://d8.dev/node/1?_format=hal_json”.

Voici un exemple ce que vous obtiendrez.

(Le contenu est volontairement tronqué dans cet exemple)

Création de contenu

Afin de pouvoir créer du contenu à l’aide des modules de webservices de Drupal 8, il est impératif d’activer le module core HAL.

Comme il s’agit ici de création de contenu, cette opération va probablement devoir être sécurisée (seul un utilisateur possédant les droits de création de contenu doit être accepté). C’est pourquoi nous allons activer le module HTTP Basic Authentication qui fourni la méthode authentification “Basic” la plus simple.

Afin de créer un contenu, il convient de créer une requêtes sur l’adresse http://<site_drupal>/entity/<entity_type>.

Pour s’identifier, le client HTTP doit envoyer la requête en spécifiant l'en-tête HTTP « Authorization » et avec la valeur de connexion. Celle-ci est composée de la méthode utilisée (Basic) suivie de la représentation en Base64 du nom de l'utilisateur et du mot de passe séparés par le caractère « : » (deux-points).

Protection supplémentaire, il faut également fournir un en-tête HTTP « X-CSRF-Token ». Ce dernier est récupérable à l’adresse rest/session/token de votre site.

Il faut néanmoins rester vigilant car de nombreux contenus Drupal sont composés d’entités liées entres-elles. Par exemple, si l’on souhaite créer un commentaire, il faut pouvoir le lier à un utilisateur. Pour ce faire, il est nécessaire de renseigner ce lien grâce à l’entrée “ _links ” du JSON.

Afin de recréer ce lien, il est plus simple de tout d’abord effectuer un appel GET sur cette ressource et d’en étudier ses entrées “ _links ”.

Les entrées du tableau “ _links ” sont créées et normalisées par le module >HAL (voir premier paragraphe du chapitre).

Pour résumer

Requête

http://example.com/entity/node

Headers

Nom de l’en-tête

Valeur de l’en-tête

X-CSRF-Token

(récupéré via rest/session/token)

Authorization

Basic (Hash base 64 username/password)

Content-Type

application/hal+json

Corps
{
"_links": {
   "type": {
     "href": "http://example.com/rest/type/node/article"
   }
},
"title": {
   "value": "Test Article 2"
},
"type": {
   "target_id": "article"
}
}

Mise à jour de contenu

Il est également possible de mettre à jour des contenus grâce au verbe HTTP PATCH .

Afin de pouvoir créer du contenu à l’aide des modules de webservices de Drupal 8, il est impératif d’activer le module core HAL ainsi que HTTP Basic Authentication.

Afin de mettre à jour un contenu, il convient de créer une requête sur l’adresse http://<site_drupal>/node/<nid>.

À l’instar de la création de contenu, il est également nécessaire de passer les en-têtes HTTP « Authorization » et « X-CSRF-Token ».

Pour résumer

Requête

http://example.com/node/<nid>

Headers

Nom de l’en-tête

Valeur de l’en-tête

X-CSRF-Token

(récupéré via rest/session/token)

Authorization

Basic (Hash base 64 username/password)

Content-Type

application/hal+json

Corps
{
"_links": {
   "type": {
     "href": "http://example.com/rest/type/node/article"
   }
},
"nid": {
   "": {
     "value": "8"
   }
},
"type": {
   "target_id": "article"
},
"promote": {
   "value": "1"
},
"body": {
   "": {
     "value": "foo bar baz", "lang": "en"
  }
}
}

 

Suppression de contenu

A l'aide du verbe HTTP DELETE, il est bien sur possible de supprimer des entités. Le fonctionnement presque identique au méthodes précédentes.

Requête

https://example.com/node/<nid>

Headers

Nom de l’en-tête

Valeur de l’en-tête

X-CSRF-Token

(récupéré via rest/session/token)

Authorization

Basic (Hash base 64 username/password)

Par flocondetoile
Adhérent

To Twig or not to Twig ? That is Drupal 8

Avec le remplacement du vénérable PHPTemplate par Twig comme moteur de template pour Drupal 8, la conception des pages et de leurs agencements a pris une nouvelle dimension.

Autant sur Drupal 7 des solutions comme Panels ou Display suite étaient privilégiées, car travailler en profondeur dans des templates mixant deux languages (PHP et HTML), dont le premier est particulièrement verbeux, pouvait très vite devenir illisible et inmaintenable, autant l'arrivée de Twig avec Drupal 8 peut changer radicalement cette perspective. Quels sont les avantages de chacune des solutions à notre disposition ? Que faut-il privilégier ? Essayons de dégager quelques éléments de réflexion.

Par Artusamak
Julien Dubois

Drupal 8 : Concevoir votre application pour Drupal 8

Drupal 8 : Concevoir votre application pour Drupal 8
Artusamak
jeu 28/04/2016 - 09:43

Cet article est extrait de notre formation drupal 8 "de Drupal 7 à Drupal 8" à destination des développeurs. N'hésitez pas à nous contacter pour en savoir plus !

Combien parmi vous se revendiquent “développeur Drupal” plutôt que “développeur PHP” ? Cela est probablement dû au fait que Drupal fonctionne grâce à un certain nombre de couches d’abstractions qui lui sont propres et que si demain vous étiez privé(e) de Drupal vous vous sentiriez démuni(e) sans Form API, Entity API, Views ou Batch API.

En pointant cela du doigt on se rend compte de la richesse d’un outil mais on peut aussi se demander si cela n’est pas une erreur. En utilisant un composant drupalo-drupalien, vous ne pourrez pas vous en resservir en changeant de technologie et c’est bien dommage. C’est une des raisons pour lesquelles Drupal 8 s’est ouvert sur le monde extérieur. Pouvoir bénéficier de composants connus et réutilisables. On parle ici de Twig, de HTTPKernel et HTTPFoundation, de l’autoloader PSR, de Guzzle, etc. D’ailleurs tout n’est pas à jeter dans Drupal, si Views devenait un composant proprement découplé il pourrait être réutilisé dans d’autres applications. Les développeurs de Commerce 2.x sont dans cet état d’esprit de design par composants indépendants et réutilisables et il est probable que cela soit une tendance de fond sur les années à venir.

L’idée derrière cela est qu’il faut garder à l’esprit qu’à chaque fois que nous concevons un nouveau projet web avec une valeur ajoutée métier, nous devons réfléchir à son architecture. Trop souvent cela se résume à choisir les modules contribués sur lesquels nous reposer, combien de view modes à créer par type de contenu ou s’il faudra utiliser Panels VS des templates VS Display Suite (troll en approche).

Une application web est composée d’objets et il y a des liens entre ces objets. Si vous utilisiez un framework il faudrait pondre un diagramme de classes et un schéma de base de données, designer vos interfaces pour rendre votre code élégant. Drupal 7 a apporté les trop peu utilisés types d’entités, profitez de Drupal 8 pour vous poser la question du bon stockage de vos données (bundle de nœud VS nouveau type d’entité VS simple table).

IC378684.png

Trop souvent le code est fragmenté et manque de recul. Pour savoir si votre application est de qualité, il suffit de vous demander cela : “suis-je capable de faire du refactoring ou de modifier des pans capitaux de l’application tout en restant serein(e) ?”. Dans la plupart des cas la réponse sera non. La faible couverture de tests (unitaires ou fonctionnels) en est l’une des principales explications. Pour cette raison, plus vous suivrez un modèle clairement défini en amont et partagé par l’équipe plus vous serez en maîtrise de votre application et, qui sait, si votre processus de production est très avancé vous réussirez à produire des tests !

Concevoir une application c’est se demander quel est le bon outil pour un usage donné. Lorsque vous designer l’infrastructure nécessaire pour faire tourner votre application vous piochez parmi des outils tels que Varnish, Nginx, Memcache, Redis, Solr.. faites la même chose sur la partie PHP. Il sera parfois plus simple d’utiliser une autre technologie voire un autre langage ou s’appuyer sur une librairie externe plutôt qu’un module Drupal pour adresser certaines problématiques. L’important est de pouvoir faire communiquer tout ce petit monde ensemble et la bonne nouvelle c’est que les webservices se sont démocratisés (encore faut-il bien les designer), facilitant par la même occasion l’échange de données. Et si vous en venez à écrire vos propres solutions, pensez à les partager, c’est la clé de l’Open Source.

Par Artusamak
Julien Dubois

Drupal 8 : Concevoir votre application pour Drupal 8

Drupal 8 : Concevoir votre application pour Drupal 8
Artusamak
jeu 28/04/2016 - 09:43

Cet article est extrait de notre formation drupal 8 "de Drupal 7 à Drupal 8" à destination des développeurs. N'hésitez pas à nous contacter pour en savoir plus !

Combien parmi vous se revendiquent “développeur Drupal” plutôt que “développeur PHP” ? Cela est probablement dû au fait que Drupal fonctionne grâce à un certain nombre de couches d’abstractions qui lui sont propres et que si demain vous étiez privé(e) de Drupal vous vous sentiriez démuni(e) sans Form API, Entity API, Views ou Batch API.

En pointant cela du doigt on se rend compte de la richesse d’un outil mais on peut aussi se demander si cela n’est pas une erreur. En utilisant un composant drupalo-drupalien, vous ne pourrez pas vous en resservir en changeant de technologie et c’est bien dommage. C’est une des raisons pour lesquelles Drupal 8 s’est ouvert sur le monde extérieur. Pouvoir bénéficier de composants connus et réutilisables. On parle ici de Twig, de HTTPKernel et HTTPFoundation, de l’autoloader PSR, de Guzzle, etc. D’ailleurs tout n’est pas à jeter dans Drupal, si Views devenait un composant proprement découplé il pourrait être réutilisé dans d’autres applications. Les développeurs de Commerce 2.x sont dans cet état d’esprit de design par composants indépendants et réutilisables et il est probable que cela soit une tendance de fond sur les années à venir.

L’idée derrière cela est qu’il faut garder à l’esprit qu’à chaque fois que nous concevons un nouveau projet web avec une valeur ajoutée métier, nous devons réfléchir à son architecture. Trop souvent cela se résume à choisir les modules contribués sur lesquels nous reposer, combien de view modes à créer par type de contenu ou s’il faudra utiliser Panels VS des templates VS Display Suite (troll en approche).

Une application web est composée d’objets et il y a des liens entre ces objets. Si vous utilisiez un framework il faudrait pondre un diagramme de classes et un schéma de base de données, designer vos interfaces pour rendre votre code élégant. Drupal 7 a apporté les trop peu utilisés types d’entités, profitez de Drupal 8 pour vous poser la question du bon stockage de vos données (bundle de nœud VS nouveau type d’entité VS simple table).

IC378684.png

Trop souvent le code est fragmenté et manque de recul. Pour savoir si votre application est de qualité, il suffit de vous demander cela : “suis-je capable de faire du refactoring ou de modifier des pans capitaux de l’application tout en restant serein(e) ?”. Dans la plupart des cas la réponse sera non. La faible couverture de tests (unitaires ou fonctionnels) en est l’une des principales explications. Pour cette raison, plus vous suivrez un modèle clairement défini en amont et partagé par l’équipe plus vous serez en maîtrise de votre application et, qui sait, si votre processus de production est très avancé vous réussirez à produire des tests !

Concevoir une application c’est se demander quel est le bon outil pour un usage donné. Lorsque vous designer l’infrastructure nécessaire pour faire tourner votre application vous piochez parmi des outils tels que Varnish, Nginx, Memcache, Redis, Solr.. faites la même chose sur la partie PHP. Il sera parfois plus simple d’utiliser une autre technologie voire un autre langage ou s’appuyer sur une librairie externe plutôt qu’un module Drupal pour adresser certaines problématiques. L’important est de pouvoir faire communiquer tout ce petit monde ensemble et la bonne nouvelle c’est que les webservices se sont démocratisés (encore faut-il bien les designer), facilitant par la même occasion l’échange de données. Et si vous en venez à écrire vos propres solutions, pensez à les partager, c’est la clé de l’Open Source.

Par Artusamak
Julien Dubois

Drupal 8 : Concevoir votre application pour Drupal 8

Drupal 8 : Concevoir votre application pour Drupal 8
jeu, 28/04/2016 - 09:43
Artusamak

Cet article est extrait de notre formation drupal 8 "de Drupal 7 à Drupal 8" à destination des développeurs. N'hésitez pas à nous contacter pour en savoir plus !

Combien parmi vous se revendiquent “développeur Drupal” plutôt que “développeur PHP” ? Cela est probablement dû au fait que Drupal fonctionne grâce à un certain nombre de couches d’abstractions qui lui sont propres et que si demain vous étiez privé(e) de Drupal vous vous sentiriez démuni(e) sans Form API, Entity API, Views ou Batch API.

En pointant cela du doigt on se rend compte de la richesse d’un outil mais on peut aussi se demander si cela n’est pas une erreur. En utilisant un composant drupalo-drupalien, vous ne pourrez pas vous en resservir en changeant de technologie et c’est bien dommage. C’est une des raisons pour lesquelles Drupal 8 s’est ouvert sur le monde extérieur. Pouvoir bénéficier de composants connus et réutilisables. On parle ici de Twig, de HTTPKernel et HTTPFoundation, de l’autoloader PSR, de Guzzle, etc. D’ailleurs tout n’est pas à jeter dans Drupal, si Views devenait un composant proprement découplé il pourrait être réutilisé dans d’autres applications. Les développeurs de Commerce 2.x sont dans cet état d’esprit de design par composants indépendants et réutilisables et il est probable que cela soit une tendance de fond sur les années à venir.

L’idée derrière cela est qu’il faut garder à l’esprit qu’à chaque fois que nous concevons un nouveau projet web avec une valeur ajoutée métier, nous devons réfléchir à son architecture. Trop souvent cela se résume à choisir les modules contribués sur lesquels nous reposer, combien de view modes à créer par type de contenu ou s’il faudra utiliser Panels VS des templates VS Display Suite (troll en approche).

Une application web est composée d’objets et il y a des liens entre ces objets. Si vous utilisiez un framework il faudrait pondre un diagramme de classes et un schéma de base de données, designer vos interfaces pour rendre votre code élégant. Drupal 7 a apporté les trop peu utilisés types d’entités, profitez de Drupal 8 pour vous poser la question du bon stockage de vos données (bundle de nœud VS nouveau type d’entité VS simple table).

IC378684.png

Trop souvent le code est fragmenté et manque de recul. Pour savoir si votre application est de qualité, il suffit de vous demander cela : “suis-je capable de faire du refactoring ou de modifier des pans capitaux de l’application tout en restant serein(e) ?”. Dans la plupart des cas la réponse sera non. La faible couverture de tests (unitaires ou fonctionnels) en est l’une des principales explications. Pour cette raison, plus vous suivrez un modèle clairement défini en amont et partagé par l’équipe plus vous serez en maîtrise de votre application et, qui sait, si votre processus de production est très avancé vous réussirez à produire des tests !

Concevoir une application c’est se demander quel est le bon outil pour un usage donné. Lorsque vous designer l’infrastructure nécessaire pour faire tourner votre application vous piochez parmi des outils tels que Varnish, Nginx, Memcache, Redis, Solr.. faites la même chose sur la partie PHP. Il sera parfois plus simple d’utiliser une autre technologie voire un autre langage ou s’appuyer sur une librairie externe plutôt qu’un module Drupal pour adresser certaines problématiques. L’important est de pouvoir faire communiquer tout ce petit monde ensemble et la bonne nouvelle c’est que les webservices se sont démocratisés (encore faut-il bien les designer), facilitant par la même occasion l’échange de données. Et si vous en venez à écrire vos propres solutions, pensez à les partager, c’est la clé de l’Open Source.

Par Artusamak
Julien Dubois

Drupal 8 : Gestion de la configuration

Drupal 8 : Gestion de la configuration
mer, 20/04/2016 - 13:49
Artusamak

Cet article est extrait de notre formation drupal 8 "de Drupal 7 à Drupal 8" à destination des développeurs. N'hésitez pas à nous contacter pour en savoir plus !

Philosophie

L’industrialisation est un sujet récurrent depuis pas mal d’années dans le monde Drupal. Drupal 7 a été une vraie avancée de ce côté là grâce à Features qui rend bien des choses exportables. Le principal problème c’est que Features n’a pas du tout été prévu pour cela. L’usage premier de Features consiste à assembler un groupe de composants pour en faire une fonctionnalité. Pour une galerie d’images par exemple, on a besoin d’un type de contenu avec quelques champs, d’une vue et d’une librairie. Chaque module contribué a la responsabilité de s’intégrer du mieux possible avec Features pour que ses composants soient exportables.

L’état de l’art est correct, on arrive à exporter la plupart des éléments d’un site mais on sent que c’est parfois laborieux d’exporter certains composants qui sont pourtant des éléments centraux de Drupal (blocs, menus, etc). La principale solution pour remédier à ce problème est d’avoir un système prévu pour cela depuis le cœur, permettant d’enlever une grosse couche de bidouille.

C’est en concertation avec les auteurs de Features que Greg Dunlap, le responsable de l’initiative CMI s’est nourri de leurs retours et des échanges avec la communauté pour concevoir un système et une API dédiés à la configuration dans Drupal 8.

Nous l’avons abordé dans le chapitre sur l’API de configuration des données, le format d’export des données est le YAML. Chaque type d’entité de configuration définit son format d’export.

Au lieu de gérer des groupes de composants comme vous pouviez gérer vos modules Features, la configuration de votre site est un tout que vous faites évoluer.

Fonctionnement

Pour comprendre comment fonctionne la configuration et comment la synchroniser entre plusieurs environnements, appuyons-nous sur l’illustration suivante :

schema_export_config.png

Icônes par Maria Leandro & Anshul Dhiman - CC 3.0 BY

Pour chaque environnement, vous retrouvez un dossier /sites/default/files/config_<hash_de_sécurité>/sync qui, juste après l’installation de Drupal, est vide.

(1) À chaque fois que vous modifiez de la configuration sur votre site (exemple : vous configurez une vue ou la position de vos blocs), Drupal sauvegarde automatiquement vos changements dans la table config.

(2) Vous voulez envoyer vos modifications sur le serveur de production. Il faut exporter la configuration. Pour cela cliquez sur Configuration > Configuration management > Full import/export > Export et cliquez sur le bouton “Export”. Vous vous retrouverez avec une archive contenant tous les fichiers de configuration de votre site.
L’autre possibilité est d’exporter la configuration par Drush avec la commande :

$ drush config-export sync
# Exporte la configuration vers sync.

Ce qui est intéressant (et même recommandé), c’est qu’il est possible d’indiquer où se situe le dossier sync. Vous pouvez ainsi vous affranchir du hash de sécurité pour mettre les dossiers hors de la racine du site et en profiter pour versionner les fichiers de configuration.

Pour faire cela, voilà la variable à surcharger dans votre fichier settings.php.

<span class="token variable">$config_directories</span><span class="token punctuation">[</span><span class="token string">'sync'</span><span class="token punctuation">]</span> <span class="token operator">=</span> <span class="token string">'../config_hc/sync'</span><span class="token punctuation">;</span>

(3) Il faut ensuite rapatrier les fichier sur le serveur de production. Soit via votre gestionnaire de source préféré, soit en rapatriant une archive, l’objectif étant de remplacer les fichiers existants sur le serveur.

(4) Pour que les nouvelles modifications soient prises en compte il faut importer la nouvelle configuration. Soit par l’interface de Drupal dans le menu Configuration > Configuration management > Synchronize, soit par la commande Drush :

$ drush config-import sync --preview=diff
# Importe la configuration depuis sync.

Drupal étant capable de vous indiquer quelles sont les surcharges de configuration à importer vous pourrez contrôler les changements. Une fois fait, le tour est joué, la nouvelle configuration est déployée, votre site prend en compte les changements.

Informations supplémentaires

Il est possible de récupérer ou d’importer un seul fichier de configuration à la fois si on le souhaite via l’interface web ou via la commande Drush :

$ drush config-get &lt;nom_composant&gt; // Récupération.
$ drush config-set &lt;nom_composant&gt; &lt;valeur&gt; // Mise à jour.

Ce qui est intéressant, maintenant que les données sont exportées proprement, c’est que les composants indiquent des dépendances entre eux. Par exemple si vous souhaitez supprimer un champ, Drupal va vous indiquer que la configuration du View mode se servant de ce champ va être supprimée, que la vue dans laquelle ce champ est utilisé va être supprimée. C’est assez sain pour se rendre compte de ce que l’on fait.

Comme vu précédemment, un module peut livrer de la configuration par défaut en la fournissant dans son dossier /config/install. Là où les choses se compliquent un peu c’est que tout n’est pas permis.
Si vous livrez de la configuration “nouvelle”, c’est à dire basée sur votre propre format ou qui n’est pas encore livrée par le cœur de Drupal, dans ce cas la nouvelle configuration sera prise en compte.
En revanche, si vous tentez d’activer un module livrant de la configuration et qui a comme nom machine une configuration déjà livrée par le cœur, vous rencontrerez une erreur.

Exemple : votre module comporte un fichier /config/install/monprojet.config.yml. Ce fichier est importé avec succès.
Si vous avez un fichier
/config/install/system.site.yml, là, vous avez une erreur.

La solution consiste alors à faire les actions de surcharge dans votre profil d’installation ou au sein d’un hook_update_N() avec les fonctions de l’API de config. L’alternative consiste à livrer la configuration depuis le dossier config/install de votre profil d’installation. Dans ce contexte précis, votre configuration sera prise en compte sans générer d’erreur.

Il n’est pas possible d’installer un site à partir de sa configuration exportée, vous devez nécessairement installer le site puis importer la configuration. La situation restera en l’état au minimum jusqu’à la version 8.1.x pour plusieurs raisons, consultez l’issue sur drupal.org si vous souhaitez plus de détails [Issue #1613424]. Notez cependant qu’Alex Pott a démarré le module “Configuration Installer” pour faire une installation depuis de la configuration.

Maintenant que le système de gestion de la configuration considère la configuration de votre site comme un tout, si vous vous retrouvez à avoir des modifications introduites sur votre site en production vous risquez d’avoir un problème.
Si vous souhaitez interdire à votre client de faire la moindre modification en production vous pouvez utiliser le module “Configuration Read-only mode” qui vous protégera.
Cela étant dit, les modifications en production peuvent être légitimes, il arrive que des équipes laissent la main à leur client pour repositionner des blocs ou modifier la structure d’une page.

Dans un tel cas de figure, vous allez devoir faire face à un problème lorsque vous allez vouloir déployer les nouveaux changements réalisés par les développeurs.
L’API du cœur ne sait faire que deux choses : importer la nouvelle configuration définie ou exporter la configuration actuelle du site. Dans le premier cas vous perdriez les modifications faites sur le site, dans le second les nouveaux changements seraient écrasés.
Pour remédier à cela, les gens de Pantheon ont développé le module drush config-extra qui expose quelques nouvelles commandes. Celle qui nous intéresse est
config-merge, elle va exporter les nouveaux changements dans le dossier “staging” en même temps que fusionner les nouveaux changements de l’équipe. Idéal pour que tout le monde reste content, il se peut même que cela vous serve pour la synchronisation entre développeurs.

La commande config-merge s’utilise comme suit :

$ drush @dev-site config-merge @production-site

L’autre solution qui s’offre à vous consiste à rapatrier une copie de la base de données de la production en local avant de commencer vos nouveaux développements, exporter cette nouvelle configuration et la versionner puis construire votre nouvelle fonctionnalité à partir de cet existant.

Par Artusamak
Julien Dubois

Drupal 8 : Gestion de la configuration

Drupal 8 : Gestion de la configuration
Artusamak
mer 20/04/2016 - 13:49

Cet article est extrait de notre formation drupal 8 "de Drupal 7 à Drupal 8" à destination des développeurs. N'hésitez pas à nous contacter pour en savoir plus !

Philosophie

L’industrialisation est un sujet récurrent depuis pas mal d’années dans le monde Drupal. Drupal 7 a été une vraie avancée de ce côté là grâce à Features qui rend bien des choses exportables. Le principal problème c’est que Features n’a pas du tout été prévu pour cela. L’usage premier de Features consiste à assembler un groupe de composants pour en faire une fonctionnalité. Pour une galerie d’images par exemple, on a besoin d’un type de contenu avec quelques champs, d’une vue et d’une librairie. Chaque module contribué a la responsabilité de s’intégrer du mieux possible avec Features pour que ses composants soient exportables.

L’état de l’art est correct, on arrive à exporter la plupart des éléments d’un site mais on sent que c’est parfois laborieux d’exporter certains composants qui sont pourtant des éléments centraux de Drupal (blocs, menus, etc). La principale solution pour remédier à ce problème est d’avoir un système prévu pour cela depuis le cœur, permettant d’enlever une grosse couche de bidouille.

C’est en concertation avec les auteurs de Features que Greg Dunlap, le responsable de l’initiative CMI s’est nourri de leurs retours et des échanges avec la communauté pour concevoir un système et une API dédiés à la configuration dans Drupal 8.

Nous l’avons abordé dans le chapitre sur l’API de configuration des données, le format d’export des données est le YAML. Chaque type d’entité de configuration définit son format d’export.

Au lieu de gérer des groupes de composants comme vous pouviez gérer vos modules Features, la configuration de votre site est un tout que vous faites évoluer.

Fonctionnement

Pour comprendre comment fonctionne la configuration et comment la synchroniser entre plusieurs environnements, appuyons-nous sur l’illustration suivante :

schema_export_config.png

Icônes par Maria Leandro & Anshul Dhiman - CC 3.0 BY

Pour chaque environnement, vous retrouvez un dossier /sites/default/files/config_<hash_de_sécurité>/sync qui, juste après l’installation de Drupal, est vide.

(1) À chaque fois que vous modifiez de la configuration sur votre site (exemple : vous configurez une vue ou la position de vos blocs), Drupal sauvegarde automatiquement vos changements dans la table config.

(2) Vous voulez envoyer vos modifications sur le serveur de production. Il faut exporter la configuration. Pour cela cliquez sur Configuration > Configuration management > Full import/export > Export et cliquez sur le bouton “Export”. Vous vous retrouverez avec une archive contenant tous les fichiers de configuration de votre site.
L’autre possibilité est d’exporter la configuration par Drush avec la commande :

$ drush config-export sync
# Exporte la configuration vers sync.

Ce qui est intéressant (et même recommandé), c’est qu’il est possible d’indiquer où se situe le dossier sync. Vous pouvez ainsi vous affranchir du hash de sécurité pour mettre les dossiers hors de la racine du site et en profiter pour versionner les fichiers de configuration.

Pour faire cela, voilà la variable à surcharger dans votre fichier settings.php.

<span class="token variable">$config_directories</span><span class="token punctuation">[</span><span class="token string">'sync'</span><span class="token punctuation">]</span> <span class="token operator">=</span> <span class="token string">'../config_hc/sync'</span><span class="token punctuation">;</span>

(3) Il faut ensuite rapatrier les fichier sur le serveur de production. Soit via votre gestionnaire de source préféré, soit en rapatriant une archive, l’objectif étant de remplacer les fichiers existants sur le serveur.

(4) Pour que les nouvelles modifications soient prises en compte il faut importer la nouvelle configuration. Soit par l’interface de Drupal dans le menu Configuration > Configuration management > Synchronize, soit par la commande Drush :

$ drush config-import sync --preview=diff
# Importe la configuration depuis sync.

Drupal étant capable de vous indiquer quelles sont les surcharges de configuration à importer vous pourrez contrôler les changements. Une fois fait, le tour est joué, la nouvelle configuration est déployée, votre site prend en compte les changements.

Informations supplémentaires

Il est possible de récupérer ou d’importer un seul fichier de configuration à la fois si on le souhaite via l’interface web ou via la commande Drush :

$ drush config-get &lt;nom_composant&gt; // Récupération.
$ drush config-set &lt;nom_composant&gt; &lt;valeur&gt; // Mise à jour.

Ce qui est intéressant, maintenant que les données sont exportées proprement, c’est que les composants indiquent des dépendances entre eux. Par exemple si vous souhaitez supprimer un champ, Drupal va vous indiquer que la configuration du View mode se servant de ce champ va être supprimée, que la vue dans laquelle ce champ est utilisé va être supprimée. C’est assez sain pour se rendre compte de ce que l’on fait.

Comme vu précédemment, un module peut livrer de la configuration par défaut en la fournissant dans son dossier /config/install. Là où les choses se compliquent un peu c’est que tout n’est pas permis.
Si vous livrez de la configuration “nouvelle”, c’est à dire basée sur votre propre format ou qui n’est pas encore livrée par le cœur de Drupal, dans ce cas la nouvelle configuration sera prise en compte.
En revanche, si vous tentez d’activer un module livrant de la configuration et qui a comme nom machine une configuration déjà livrée par le cœur, vous rencontrerez une erreur.

Exemple : votre module comporte un fichier /config/install/monprojet.config.yml. Ce fichier est importé avec succès.
Si vous avez un fichier
/config/install/system.site.yml, là, vous avez une erreur.

La solution consiste alors à faire les actions de surcharge dans votre profil d’installation ou au sein d’un hook_update_N() avec les fonctions de l’API de config. L’alternative consiste à livrer la configuration depuis le dossier config/install de votre profil d’installation. Dans ce contexte précis, votre configuration sera prise en compte sans générer d’erreur.

Il n’est pas possible d’installer un site à partir de sa configuration exportée, vous devez nécessairement installer le site puis importer la configuration. La situation restera en l’état au minimum jusqu’à la version 8.1.x pour plusieurs raisons, consultez l’issue sur drupal.org si vous souhaitez plus de détails [Issue #1613424]. Notez cependant qu’Alex Pott a démarré le module “Configuration Installer” pour faire une installation depuis de la configuration.

Maintenant que le système de gestion de la configuration considère la configuration de votre site comme un tout, si vous vous retrouvez à avoir des modifications introduites sur votre site en production vous risquez d’avoir un problème.
Si vous souhaitez interdire à votre client de faire la moindre modification en production vous pouvez utiliser le module “Configuration Read-only mode” qui vous protégera.
Cela étant dit, les modifications en production peuvent être légitimes, il arrive que des équipes laissent la main à leur client pour repositionner des blocs ou modifier la structure d’une page.

Dans un tel cas de figure, vous allez devoir faire face à un problème lorsque vous allez vouloir déployer les nouveaux changements réalisés par les développeurs.
L’API du cœur ne sait faire que deux choses : importer la nouvelle configuration définie ou exporter la configuration actuelle du site. Dans le premier cas vous perdriez les modifications faites sur le site, dans le second les nouveaux changements seraient écrasés.
Pour remédier à cela, les gens de Pantheon ont développé le module drush config-extra qui expose quelques nouvelles commandes. Celle qui nous intéresse est
config-merge, elle va exporter les nouveaux changements dans le dossier “staging” en même temps que fusionner les nouveaux changements de l’équipe. Idéal pour que tout le monde reste content, il se peut même que cela vous serve pour la synchronisation entre développeurs.

La commande config-merge s’utilise comme suit :

$ drush @dev-site config-merge @production-site

L’autre solution qui s’offre à vous consiste à rapatrier une copie de la base de données de la production en local avant de commencer vos nouveaux développements, exporter cette nouvelle configuration et la versionner puis construire votre nouvelle fonctionnalité à partir de cet existant.

Par Artusamak
Julien Dubois

Drupal 8 : Gestion de la configuration

Drupal 8 : Gestion de la configuration
Artusamak
mer 20/04/2016 - 13:49

Cet article est extrait de notre formation drupal 8 "de Drupal 7 à Drupal 8" à destination des développeurs. N'hésitez pas à nous contacter pour en savoir plus !

Philosophie

L’industrialisation est un sujet récurrent depuis pas mal d’années dans le monde Drupal. Drupal 7 a été une vraie avancée de ce côté là grâce à Features qui rend bien des choses exportables. Le principal problème c’est que Features n’a pas du tout été prévu pour cela. L’usage premier de Features consiste à assembler un groupe de composants pour en faire une fonctionnalité. Pour une galerie d’images par exemple, on a besoin d’un type de contenu avec quelques champs, d’une vue et d’une librairie. Chaque module contribué a la responsabilité de s’intégrer du mieux possible avec Features pour que ses composants soient exportables.

L’état de l’art est correct, on arrive à exporter la plupart des éléments d’un site mais on sent que c’est parfois laborieux d’exporter certains composants qui sont pourtant des éléments centraux de Drupal (blocs, menus, etc). La principale solution pour remédier à ce problème est d’avoir un système prévu pour cela depuis le cœur, permettant d’enlever une grosse couche de bidouille.

C’est en concertation avec les auteurs de Features que Greg Dunlap, le responsable de l’initiative CMI s’est nourri de leurs retours et des échanges avec la communauté pour concevoir un système et une API dédiés à la configuration dans Drupal 8.

Nous l’avons abordé dans le chapitre sur l’API de configuration des données, le format d’export des données est le YAML. Chaque type d’entité de configuration définit son format d’export.

Au lieu de gérer des groupes de composants comme vous pouviez gérer vos modules Features, la configuration de votre site est un tout que vous faites évoluer.

Fonctionnement

Pour comprendre comment fonctionne la configuration et comment la synchroniser entre plusieurs environnements, appuyons-nous sur l’illustration suivante :

schema_export_config.png

Icônes par Maria Leandro & Anshul Dhiman - CC 3.0 BY

Pour chaque environnement, vous retrouvez un dossier /sites/default/files/config_<hash_de_sécurité>/sync qui, juste après l’installation de Drupal, est vide.

(1) À chaque fois que vous modifiez de la configuration sur votre site (exemple : vous configurez une vue ou la position de vos blocs), Drupal sauvegarde automatiquement vos changements dans la table config.

(2) Vous voulez envoyer vos modifications sur le serveur de production. Il faut exporter la configuration. Pour cela cliquez sur Configuration > Configuration management > Full import/export > Export et cliquez sur le bouton “Export”. Vous vous retrouverez avec une archive contenant tous les fichiers de configuration de votre site.
L’autre possibilité est d’exporter la configuration par Drush avec la commande :

$ drush config-export sync
# Exporte la configuration vers sync.

Ce qui est intéressant (et même recommandé), c’est qu’il est possible d’indiquer où se situe le dossier sync. Vous pouvez ainsi vous affranchir du hash de sécurité pour mettre les dossiers hors de la racine du site et en profiter pour versionner les fichiers de configuration.

Pour faire cela, voilà la variable à surcharger dans votre fichier settings.php.

<span class="token variable">$config_directories</span><span class="token punctuation">[</span><span class="token string">'sync'</span><span class="token punctuation">]</span> <span class="token operator">=</span> <span class="token string">'../config_hc/sync'</span><span class="token punctuation">;</span>

(3) Il faut ensuite rapatrier les fichier sur le serveur de production. Soit via votre gestionnaire de source préféré, soit en rapatriant une archive, l’objectif étant de remplacer les fichiers existants sur le serveur.

(4) Pour que les nouvelles modifications soient prises en compte il faut importer la nouvelle configuration. Soit par l’interface de Drupal dans le menu Configuration > Configuration management > Synchronize, soit par la commande Drush :

$ drush config-import sync --preview=diff
# Importe la configuration depuis sync.

Drupal étant capable de vous indiquer quelles sont les surcharges de configuration à importer vous pourrez contrôler les changements. Une fois fait, le tour est joué, la nouvelle configuration est déployée, votre site prend en compte les changements.

Informations supplémentaires

Il est possible de récupérer ou d’importer un seul fichier de configuration à la fois si on le souhaite via l’interface web ou via la commande Drush :

$ drush config-get &lt;nom_composant&gt; // Récupération.
$ drush config-set &lt;nom_composant&gt; &lt;valeur&gt; // Mise à jour.

Ce qui est intéressant, maintenant que les données sont exportées proprement, c’est que les composants indiquent des dépendances entre eux. Par exemple si vous souhaitez supprimer un champ, Drupal va vous indiquer que la configuration du View mode se servant de ce champ va être supprimée, que la vue dans laquelle ce champ est utilisé va être supprimée. C’est assez sain pour se rendre compte de ce que l’on fait.

Comme vu précédemment, un module peut livrer de la configuration par défaut en la fournissant dans son dossier /config/install. Là où les choses se compliquent un peu c’est que tout n’est pas permis.
Si vous livrez de la configuration “nouvelle”, c’est à dire basée sur votre propre format ou qui n’est pas encore livrée par le cœur de Drupal, dans ce cas la nouvelle configuration sera prise en compte.
En revanche, si vous tentez d’activer un module livrant de la configuration et qui a comme nom machine une configuration déjà livrée par le cœur, vous rencontrerez une erreur.

Exemple : votre module comporte un fichier /config/install/monprojet.config.yml. Ce fichier est importé avec succès.
Si vous avez un fichier
/config/install/system.site.yml, là, vous avez une erreur.

La solution consiste alors à faire les actions de surcharge dans votre profil d’installation ou au sein d’un hook_update_N() avec les fonctions de l’API de config. L’alternative consiste à livrer la configuration depuis le dossier config/install de votre profil d’installation. Dans ce contexte précis, votre configuration sera prise en compte sans générer d’erreur.

Il n’est pas possible d’installer un site à partir de sa configuration exportée, vous devez nécessairement installer le site puis importer la configuration. La situation restera en l’état au minimum jusqu’à la version 8.1.x pour plusieurs raisons, consultez l’issue sur drupal.org si vous souhaitez plus de détails [Issue #1613424]. Notez cependant qu’Alex Pott a démarré le module “Configuration Installer” pour faire une installation depuis de la configuration.

Maintenant que le système de gestion de la configuration considère la configuration de votre site comme un tout, si vous vous retrouvez à avoir des modifications introduites sur votre site en production vous risquez d’avoir un problème.
Si vous souhaitez interdire à votre client de faire la moindre modification en production vous pouvez utiliser le module “Configuration Read-only mode” qui vous protégera.
Cela étant dit, les modifications en production peuvent être légitimes, il arrive que des équipes laissent la main à leur client pour repositionner des blocs ou modifier la structure d’une page.

Dans un tel cas de figure, vous allez devoir faire face à un problème lorsque vous allez vouloir déployer les nouveaux changements réalisés par les développeurs.
L’API du cœur ne sait faire que deux choses : importer la nouvelle configuration définie ou exporter la configuration actuelle du site. Dans le premier cas vous perdriez les modifications faites sur le site, dans le second les nouveaux changements seraient écrasés.
Pour remédier à cela, les gens de Pantheon ont développé le module drush config-extra qui expose quelques nouvelles commandes. Celle qui nous intéresse est
config-merge, elle va exporter les nouveaux changements dans le dossier “staging” en même temps que fusionner les nouveaux changements de l’équipe. Idéal pour que tout le monde reste content, il se peut même que cela vous serve pour la synchronisation entre développeurs.

La commande config-merge s’utilise comme suit :

$ drush @dev-site config-merge @production-site

L’autre solution qui s’offre à vous consiste à rapatrier une copie de la base de données de la production en local avant de commencer vos nouveaux développements, exporter cette nouvelle configuration et la versionner puis construire votre nouvelle fonctionnalité à partir de cet existant.

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

Agence Drupal en Dordogne Aquitaine

Logo Drupal

Quand une agence Web investit, ses clients y gagnent

Les limites de la facilité

La tentation est forte pour les agences Web d'aller au plus simple pour gagner du temps et réaliser immédiatement des marges conséquentes. Lorsque les temps sont durs, le raisonnement est naturel.

Pour autant, nous pensons qu'il n'est pas juste car sous peine de glisser rapidement dans l'opportunisme et la médiocrité, notre posture professsionnelle consiste à influencer positvement notre marché sur la durée.

Dans le domaine du blogging ou dans celui du commerce en ligne, la majorité des CMS ont misé sur une prise en main imédiate ne nécessitant aucune spécialisation particulière pour le créateur du site Internet. Il en résulte un développement assez superficiel au service d'usages généralement peu exigeants, mais également des modules peu approfondis dont la fiabilité laisse souvent à désirer.

Les risques de la facilité

Lorsque l'agence Web enrichit le code source de codes spécifiques et de nombreuses corrections, elle peut alors espérer livrer des sites de qualité acceptable. Mais elle a dans ce cas consacré un temps considérable à un travail qui risque fort d'être à refaire à chaque mise à jour de la version ou du module...

Si l'agence ne facture pas ses clients pour de telles prestations, elle s'expose d'autant plus à des difficultés économiques que ses clients sont nombreux...

En les facturant, elle s'expose à l'incompréhension de sa clientèle qui considère alors à juste titre avoir été flouée ou mal conseillée !

L'intérêt de la qualité

Notre choix s'est donc orienté vers Drupal pour répondre aux attentes d'une clientèle qui souhaite investir dans des solutions de qualité, durables et totalement évolutives pour accompagner efficacement les projets !

Une agence Drupal pour + de sérénité

Liberté d'action

Comme tous les CMSDrupal repose sur le professionnalisme et la pérénité de la communauté informatique qui le développe. Lorsqu'une agence Web fait le choix de livrer à ses clients des sites internet propulsés par un CMS Open source, ils les libèrent d'une forme de dépendance vis à vis d'eux en leur livrant les accès au code source.

C'est notre choix car nous pensons que nos clients ont d'autant plus envie d'approfondir leurs relations avec notre agence, qu'ils sont libres de leurs mouvements !

Sécurité assurée

On peut pousser le raisonnement... Propulser les sites de nos clients avec un CMS revient aussi à sécuriser l'administration de leur site au delà de notre propre existence ! Une compétence Drupal ne s'improvise pas et les agences qui ont fait le choix de se spécialiser Drupal se trouvent facilement sur l'ensemble du territoire national, européen et international.

Puissance garantie

Très solide dans sa conception, le noyau Drupal résiste à des contraintes très lourdes, tant sur le plan des données que sur celui des fonctionnalités. Cette caractéristique est directement liée aux domaines d'applications complexes auquel Drupal s'est destiné dès son origine.

Stabilité optimale

Déjà très stable dans la version 7, la prochaine version Drupal 8 atteindra un niveau de stabilité encore optimisé du fait d'un développement sous Symfony2.

Situer Drupal parmi les CMS Open Source

9 CMS à la loupe...

L'enquête CMS Open source très complète conduite par l'intégrateur Smile permet d'apprécier de façon objective et argumentée les CMS les plus emblématiques du marché :

5 axes d'analyse

Les angles d'observation s'organisent selon la méthodologie suivante :

  1. Structuration du contenu ;
  2. Manipulation du contenu ;
  3. Exploitation du contenu ;
  4. Utilisation et politique de sécurité ;
  5. Caractéristiques du socle technique.

En résumé...

Toutes analyses confondues, Drupal figure en seconde position dans le trio de tête juste derrière eZ Publish et devant HippoCMS. Avec des écarts significatifs, Spip et Joomla ferment la marche .

Si on considère chacun des axes d'analyse, il ressort que :

  • Concernant la structure du contenu, Drupal se positionne bien avec eZ PublishJahiaHippoCMS et Liferay. Nous retrouvons Joomla et Spip en queue de classement.
  • Pour la manipulation du contenu, DrupalHippoCMSJahia et Liferay sont ex aequo en première position. Joomla et Spip ne brillent pas davantage sur ce point non plus.
  • S'agissant de l'exploitation du contenu, eZ Publish et HippoCMS tiennent la tête, suivis de très près par Drupal.  Joomla et Spip tiennent ex aequo les dernières positions.
  • Sur le plan de l'utilisation et de la politique de sécurité, Drupal et Liferay sont ex aequo en tête du classement suivis de près par eZ Publish et JahiaTYPO3 se positionne honorablement sur ce point. Spip et Joomla ne parviennent pas non plus sur ce point à remonter dans le classement.
  • Enfin, concernant la qualité du socle technique, DrupaleZ Publish et TYPO3 se distinguent à égalité avec des performances remarquables. Rien ne change en fin de classement pour Spip et Joomla.

WordPress a été peu cité car se situant de façon constante dans une honorable moyenne. Cette performance renforce l'idée que WordPress est bel et bien un moteur polyvalent qui peut répondre à des utilisations dont les spécificités ne sont pas clairement posées, avec le risque d'une extensibilité réduite.

Sources

Vous pouvez télécharger l'intégralité des sources de l'enquête CMS Open source sur la page que Smile met à votre disposition.

Drupal pour quels sites ?

Si le socle Drupal répond de façon très professionnelle aux exigences de sites marketing, de réseaux sociaux, de sites institutionnels et de portails intranet, ses performances servent particulièrement la réalisation de sites sur mesure dont l'évolution est probable, y compris sur le commerce en ligne !

Cette analyse nous conforte dans l'option d'une spécialisation Drupal sans ignorer d'autres CMS comme WordPress lorsque les contraintes ou exigences fonctionnelles sont très génériques et peu évolutives.

 

Découvrez nos réalisations web et n'hésitez pas à nous consulter pour nous présenter vos projets de communication digitale. Nous réagirons avec attention et objectivité.

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

e-commerce : un catalogue vendeur sans budget photo

Image appareil photo et caddie

Un site marchand sans photos attrayantes... juste inimaginable !

Imaginez une boutique sans vitrine ou un catalogue commercial sans illustrations... un remède contre la vente !

Plus encore, l'image a pris une telle importance dans nos comportements d'achat qu'elle ne doit pas seulement exister, elle se doit aussi d'être attractive pour satisfaire notre sensibilité croissante au marketing sensoriel.

Les studios spécialisés dans la photo publicitaire offrent sans aucun doute la meilleure solution sur le plan technique. Sans avoir participé un jour à un shooting produits de A à Z, on imagine difficilement le temps et les ressources nécessaires... ce qui nous laisse pantois lorsqu'on reçoit les devis.

Le coût d'un shooting produits en studio

Toujours trop cher lorsque le budget global est serré, les devis des photographes sont toutefois généralement justifiés. Comptez globalement entre 900 et 1000 euros HT pour une vingtaine de photos avec le retraitement numérique et les droits d'exploitation.

Évidemment, si on considère q'un produit doit en moyenne faire l'objet de 3 vues différentes, et qu'une boutique en ligne doit offrir une gamme de produits suffisante pour être attractive (au moins 50 références hors déclinaisons), le budget atteint assez facilement 7500 euros, soit environ autant que le budget minimum permettant le développement d'un site marchand générique de qualité satisfaisante.

Alternatives aux photos professionnelles

Rares sont donc les jeunes e-commerçants qui ont recours aux services d'un studio professionnel. Pour autant, disposer de belles photos produits reste essentiel et pour ne pas condamner le site marchand à l'échec dès le départ, il faut s'organiser au mieux avec les ressources disponibles.

Installez un studio de forture dans vos locaux

N'importe quelle pièce peut faire l'affaire pour peu que vous puissiez mobiliser environ 10 m2durant quelques semaines, avec :

  • un point de lumière naturelle,
  • un plateau de présentation pour les prises de vue,
  • une étagère (ou des suspensions) pour y entreposer les accessoires ou les produits en cours de travail,
  • une zone de circulation pour accéder facilement aux tables sans déplacer le pied de l'appareil photo et les dispositifs d'éclairage.

Réaliser toutes les prises de vues à partir de la même installation garantit l'homogénéité des photos et du résultat final.

Disposez du bon matériel

L'outillage indispensable se résume à 3 équipements :

  • Un trépied pour stabiliser l'appareil photo au cours des réglages et des prises de vues,
  • Un appareil photo numérique qui permet un réglage manuel de l'ouverture et de l'exposition,
  • Une boite à lumière ou des sources de lumière continue d'une puissance suffisante et adaptée aux produits à shooter.

Pour le reste, faites appel à votre imagination et à votre ingéniosité :

  • usez de papier ou de toile pour le fond,
  • mettez à profit le ruban adhésif et le fil de nylon pour suspendre et fixer le fond sur son support,
  • tracez au crayon ou au blanco vos repères de positionnement sur la table de présentation,
  • montez une étagère en kit pour tout ranger et tout avoir sous la main,
  • ...

Considérez l'éclairage comme essentiel

Rassurez-vous, les plus grands professionnels passent eux aussi beaucoup de temps à trouver la bonne organisation des sources lumineuses.

Le bon choix d'éclairage permet des prises de vues qui respectent les couleurs et leurs contrastes. N'hésitez donc pas à passer le temps nécessaire aux essais car une fois trouvée, la solution servira durant toute la durée du shooting photo. Pensez aussi à garder sous la main un quart de feuille blanche qui vous servira à étalonner vos photos sur la plan de la luminosité.

Les ombres peuvent être parasites, ou de précieux alliés pour souligner les formes et donner du réalisme à vos produits.

Soignez la présentation des produits

Il reste la mise en scène des produits et sur ce point, vous pouvez simplement vous inspirer de certains sites référents qui impulsent les tendances pour des produits similaires aux votres. Bien sûr, si votre créativité vous autorise à innover... surprenez-nous !

5 clés pour valoriser à coup sûr les prises de vues de vos produits :

  • Inspectez vos produits sous toutes les coutures pour ne laisser aucun détail dégrader leur aspect (micro tâches, peluches, traces, grains de poussière, ...),
  • Trouvez l'angle le plus favorable pour mettre en évidence leurs signes distinctifs (rotation, inclinaison, surplomb, ...),
  • Associez vos produits à des objets très courants (clés, montre, carte de crédit, ...) si vous souhaitez que vos clients aient une bonne appréciation de leurs dimensions sans avoir à les rechercher dans le descriptif,
  • Enrichissez la présentation de vos produits par la présence d'accessoires s'ils contribuent fortement à intensifier l'intérêt ou le plaisir sensoriel,
  • Assurez-vous avant chaque prise de vue que votre fond soit resté impécable (exempt de plis, tâches, accrocs, ...) afin d'éviter les retouches post-production toujours ruineuses en temps.

Toutes les astuces sont permises pour imprimer un mouvement, maintenir en suspend un élément, raidir un support, ... et là, c'est à vous de jouer.

Focus sur la prise de vues

De la même façon que les repères sur votre fond guideront vos dispositions sur le plateau de shooting, le ou les points de prise de vues seront exactement tracés au sol, une fois définies comme satisfaisantes.

Prévoyez de demander à votre prestataire web une fonctionnalité zoom sur vos photos. Vos clients pourront ainsi examiner vos produits dans leurs moindres détails, et ils adorent ça... pour peu que les angles de prise de vues anticipent cette observation.

Doublez enfin toujours vos photos d'une prise de vue avec un quart de feuille blanche contre votre produit, face à l'angle de shoot. Vous aurez ainsi un repère constant de luminosité. Il sera un précieux indice pour guider le retraitement numérique définitif.

Traiter les photos avant intégration dans la boutique

Le retraitement numérique de vos photos se justifie par :

  • la volonté de montrer à vos clients, des photos totalement fidèles à l'aspect réel de vos produits,
  • l'intérêt de suivre les préconisation d'un guide de style que vous aurez préalablement établi en précisant notamment :
    • les contraintes de taille des images,
    • la dimension des différentes marges,
    • les couleurs de background,
    • les alignements pour les différentes catégories de produits,
    • les ombrages et leurs caractéristiques,
  • le respect des principales règles visuelles pour la vente en ligne telles qu'exigées par certaines plateformes de vente en ligne comme eBay, Amazon ou Google Shopping, si vous étiez amenés à les utiliser.

Cette opération est la moins accessible pour les e-commerçants qui ne maîtrisent pas les outils de retouche numérique. C'est sur ce point qu'ils peuvent mettre à profit les services de notre agence.

À propos de la Web agency Mantalo

Lorsque le budget de nos clients le permet, nous collaborons volontiers avec les studios spécialisés en photographie publicitaire.

Dans les autres cas, à l'instar de cette publication ouverte et compte tenu de notre souhait de contribuer à la réussite de leur commerce en ligne, nous les aidons à mettre en oeuvre les moyens requis pour produire des photos de produits dans les meilleures conditions par un accompagnement :

  • à la mise en place d'un studio "maison" dans leurs locaux,
  • à la formalisation d'un guide de style,
  • à la prise de vues.

Nous offrons également à nos clients, des prestations de retraitement numérique à l'aide de logiciels professionnels qui nécessitent une licence d'utilisation et une formation spécialisée.

Category: 

Votre projet de e-commerce tient la route ?

Votre budget photo est trop réduit pour faire appel à un studio professionnel en photographies publicitaires ?

Contactez-nous et voyons ensemble comment optimiser vos ressources disponibles !

Pages