Planète

Par Artusamak
Julien Dubois

Drupal 8 : Les formulaires

Drupal 8 : Les formulaires
lun, 08/02/2016 - 17:29
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 formulaires ne coupent pas au passage à la POO. Maintenant pour en créer un il vous faut étendre l’une des trois classes de base fournies par le coeur.
Il y a celle que vous utiliserez probablement le plus qui est
FormBase qui permet tout simplement de créer un formulaire “classique”.
Vient ensuite
ConfirmFormBase qui sert à créer des formulaires de confirmation.
S’ajoute enfin à cela
ConfigFormBase qui permet de faire un formulaire qui va aller exporter ses données dans de la configuration.

Pourquoi s’appuyer sur des classes de base ? Si l’on prend l’exemple de la classe ConfigFormBase, c’est que vous voulez sauver une donnée de façon pérenne dans de la configuration. Pour faire cela proprement, il faut faire appel au service qui gère la configuration (nous verrons plus tard ce que sont les services).
Pour éviter d’avoir à tout (re)faire à la main, des classes de base sont à votre disposition pour cela, chacune apportant sont lot de services et d’accès aux données (utilisateur courant, route, etc) vous évitant ainsi d’écrire beaucoup de code à faible valeur ajoutée.

Voici un exemple de classe d'un formulaire de configuration :

<?php
namespace Drupal\happy_alexandrie\Form;
use Drupal\Core\Form\ConfigFormBase;
use Drupal\Core\Form\FormStateInterface;
/**
 * Configuration form for the grand Alexandrie library.
 */
class AlexandrieConfigForm extends ConfigFormBase {
  /**
   * Defines the form ID.
   *
   * This method replaces the hook_form.
   */
  public function getFormId() {
    return 'alexandrie_config_form';
  }
  /**
   * Indicates the namespace of the exported data for this form.
   *
   * Specific to the config forms, indicates under which name the configuration
   * data should be exported. It will be the filename of the exported data.
   */
  public function getEditableConfigNames() {
    return array(
      'happy_alexandrie.library_config'
    );
  }
  /**
   * Defines the form structure.
   *
   * This is where you will define the content of the form, note that the
   * method takes two arguments as in Drupal 7, the form and form state but
   * the form states is now an object, it must match the FormStateInterface.
   */
  public function buildForm(array $form, FormStateInterface $form_state) {
    // Call the parent implementation to inherit from the save button and
    // form style.
    $form = parent::buildForm($form, $form_state);
    // Add our custom form fields.
    $form['opening_hours'] = array(
      '#type' => 'textarea',
      '#title' => 'Opening hours',
      '#description' => 'Days / hours of the library',
      '#default_value' => $this->config('happy_alexandrie.library_config')->get('opening_hours'),
      '#rows' => 5,
    );
    return $form;
  }
  /**
   * Submit callback.
   *
   * Implements the form logic.
   */
  public function submitForm(array &$form, FormStateInterface $form_state) {
    $this->config('happy_alexandrie.library_config')
      ->set('opening_hours', $form_state->getValue('opening_hours'))
      ->save();
    // Call the parent implementation to inherit from what has been done in it.
    // In our case, display the confirmation message.
    parent::submitForm($form, $form_state);
  }
}

Les formulaires n’ont pas radicalement changé dans leur fonctionnement. L’identifiant du formulaire est fourni via la méthode getFormId(), le contenu du formulaire est défini dans la méthode buildForm() et le traitement du formulaire une fois soumis est implémenté dans la méthode submitForm(). Il est toujours possible de valider les données via la méthode validateForm().

L’autre changement important lié aux formulaires est la manipulation de la variable $form_state. Anciennement un tableau, c’est devenu un objet de type FormStateInterface.
Quels conséquences cela engendre-t-il ? Il devient plus simple de parcourir ses données car la récupération des valeurs se fait via la méthode
getValue() comme suit :

# NodePreviewForm.php
// Récupération du view mode dans lequel prévisualiser le noeud.
$view_mode = $form_state->getValue('view_mode');

Cette interface contient aussi une méthode setRedirect() pour rediriger l’utisateur, une méthode getErrors() pour récupérer les erreurs, une méthode setErrorByName() pour indiquer une erreur sur un champ, une méthode setValue() pour surcharger la valeur d’un champ, etc. Jetez un oeil à la définition de l’interface pour voir tout ce qu’il est possible de faire.

La sauvegarde des données qui étaient stockées dans la table variable se fait maintenant via l’API de configuration simple pour être exportées dans les fichiers de configuration YAML.
Cela signifie c’est que c’est à vous d’écrire le code qui exporte vos données (entre autres, parce que c’est aussi à vous de choisir le nom machine de ces données).

Par Artusamak
Julien Dubois

Drupal 8 : CMI / Configuration, les fondements

Drupal 8 : CMI / Configuration, les fondements
mer, 03/02/2016 - 14:34
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 !

Il y a plusieurs mois de cela nous vous avions présenté les concepts de l'initiative CMI (Configuration Management Initiative) et vous avions montré quelques exemples pratiques. Cette initiative, annoncée dès le démarrage du cycle de développement de Drupal 8. a donné naissance à l’API de configuration. Elle permet l’export de  la configuration du site dans des fichiers YAML.

Le YAML 

Le YAML est un format de représentation des données standard utilisé par beaucoup d’autres logiciels ou technologies, notamment Symfony. Il a l’avantage d’être plus facilement “parsé” que les anciens fichiers INI en .info tout en restant compréhensible par les humains.

Les fichiers associés à ce format sont les .yml et sont utilisés dans Drupal 8 pour exporter / importer l’ensemble de la configuration du site.

Il existe plusieurs outils pour gérer de la configuration, chacun répondant à un besoin particulier.

  • Le Service de gestion de configuration
  • La State API
  • Les entités de configuration

Les données simples

Les données de configuration simples (exemple : une option oui / non pour un paramètre de votre module, la taille d’un buffer, logger ou non des erreurs, etc) exploitent le Service de gestion de configuration. Ces données très simples à stocker n’ont qu’une version possible et sont pérennes.

Exemple de données simples exportés dans un fichier .yml :

# system.theme.yml
admin: ''
default: stark

Il est possible de fournir de la configuration par défaut, prise en compte lors de l’installation d’un module, en la plaçant dans le dossier config/install/<module_name>.<groupe>.yml du module, le groupe permettant de rassembler des variables traitant du même sujet. Il arrivera que votre module puisse livrer de la configuration pour des dépendances non activées (exemple : une vue pour de la taxonomie alors que le module de taxonomie n’est pas actif). Pour éviter d’avoir à activer tous les modules, vous pourrez livrer de la configuration dite optionnelle, il faudra dans ce cas la placer dans le dossier config/optional/<module>.<groupe>.yml.

Documentation officielle : https://www.drupal.org/node/1809490

Configuration schema

La configuration ayant vocation à être exportée, il a fallut créer une façon de décrire les données à exporter. CMI a mis en place un système de description de la configuration et l’enrichit de certaines méta-données à travers un fichier .yml. L’idée de ce fichier est de décrire le type de données stockées par la configuration, d’y associer un label, d’informer que les données soient traduisibles ou non, etc. Plus d’informations à propos des schémas de configuration et des méta-données peuvent être trouvées sur cette page : https://www.drupal.org/node/1905070.

Le fichier à créer se placera dans config/schema/<module_name>.schema.yml et il permettra de décrire toutes les configurations utilisées par ce module.

Extrait du fichier schéma pour le fichier system.schema.yml :

# system.schema.yml
# [...]
system.theme: # couple .
  type: config_object
  label: 'Theme settings'
  mapping:
    admin:
      type: string
      label: 'Administration theme'
        default:
      type: string
      label: 'Default theme
# [...]

Le couple <module_name>.<groupe> du fichier de configuration sera utilisé comme clef dans le fichier schéma, vient ensuite la description des types de données de chacune des données, ainsi qu’un label descriptif. Les types de données existants sont décrits dans la page de documentation liée plus haut et exploitent la Typed Data API.

Documentation officielle : https://www.drupal.org/node/1905070

Utilisation de la configuration

On pourra récupérer les données liées à ce groupe en utilisant comme identifiant de configuration la clé “module.groupe” (voir ci-dessous).
La configuration doit toujours être sauvée. Mettre des données dans un objet de configuration ne suffit pas. Les objets de configuration peuvent être récupérés soit en lecture seule soit prêts à être modifiés selon les besoins.

# Controller.php
// Récupérer la valeur pour lecture.
$config = \Drupal::config('system.performance');
$enabled = $config->get('cache.page.enabled');
// Définir la valeur pour écriture.
$config = \Drupal::configFactory()->getEditable('system.performance');
$config->set('cache.page.enabled', TRUE);
$config->save();

Une ligne de configuration peut être supprimée en utilisant la fonction clear(). Pour supprimer une configuration complète il faudra utiliser la fonction delete().

Exemple :

# Controller.php
$config_factory = \Drupal::configFactory();
// Supprime la configuration de la durée de vie maximale du cache de page.
$config = $config_factory->getEditable('system.performance');
$config->clear('cache.page.max_age')->save();
// Supprime la configuration globale de system.performance.
$config_factory->getEditable('system.performance')->delete();

Ces données lorsqu’elles sont sauvées sont stockées dans la table config. Cette table remplace la défunte table fourre-tout variable. C’est le point de passage centralisé où les données de configuration transitent avant d’être exportées. Si vos données ne sont pas exportées elles resteront dans cette table.

State API

Certaines de vos données ne seront pas identiques d’un environnement à un autre, voire indépendante. Exemples : dernier passage de cron, clés d’API externe, niveau de reporting des erreurs. Ces données pourraient être éligibles pour être gérées via l’API de configuration des données simples mais un système dédié leur est consacré.

Ce système est la State API qui s’utilise comme suit :

# Controller.php
// Récupérer une valeur.
$maintenance_state = \Drupal::state()->get('system.maintenance_mode');
// Récupérer une valeur multiple.
$pairs = \Drupal::state()->getMultiple($keys);
// Définir une valeur.
\Drupal::state()->set('key','value');
// Définir une valeur multiple.
\Drupal::state()->setMultiple($keyvalues);
// Supprimer une valeur.
\Drupal::state()->delete('key'); 

Une bonne pratique consiste à préfixer les clés avec le nom du module qui défini la valeur, exemple : system.maintenance_mode. Il n’est pas toujours simple de choisir s’il on va utiliser la State API ou l’API de configuration de données simples alors voici un truc pour savoir quoi faire : si vos données doivent être exportées, utilisez l’API de configuration, si ça n’est pas le cas, la State API fera sûrement l’affaire !

À noter qu'il existe un PDF d'aide pour retrouver toutes les commandes liées à la manipulation de la configuration.

Entité de configuration

Poursuivant le principe de “tout est nœud” puis “tout est entité” des anciennes versions de Drupal, une partie de la configuration se retrouve aussi dans des entités. Cela s’appelle les entités de configuration et elles sont majoritairement utilisées quand il s’agit de définir un ensemble de variables de configuration pouvant être définies plusieurs fois. Le principe de type et de bundle existe dans ce cas là aussi mais les bundles d’entités ne sont pas utilisés. Toutes les entités de configuration d’un même type (une vue, un profil de style d’image, un rôle, un vocabulaire, etc) ont le bundle par défaut. (C’est déjà suffisamment compliqué comme ça !).
Bien qu’ayant un fonctionnement différent des données simples, les entités de configuration sont aussi exportables au même format que la configuration simple.

Exemple de configuration d’une entité exportée dans un fichier .yml :

# user.role.administrator.yml

uuid: aad4152c-be3a-4be7-8555-85d45b67e239
langcode: en
status: true
dependencies: {  }
id: administrator
label: Administrator
weight: 2
is_admin: true
permissions: {  }
Par admin

Les propositions de logo pour l'association

Il y a quelques semaines, nous présentions l'appel à contribution, lançant un concours de logo pour l'association. L'idée est de mettre une coup de neuf sur l'identité visuelle de l'association.

Voici les propositions anonymes, sans annotations.
Les commentaires sont ouverts, et le bureau fera une sélection prochainement.

Il reste encore une semaine pour proposer vos contributions, à vos crayons.

1. Logo 1 1. Fond Bleu logo 1
2. Logo 2 2. Fond bleu logo 2
3. Logo 3 3. Fond blanc logo 3
4. Logo 4 fond bleu 4. Logo 4
5. Logo 5 6. Logo 6
7. Logo 7 8. Logo 8
9. Logo 9 10. Logo 10
11. Logo 11 12. Logo 12
13. Logo 13 13. bis Logo 13 bis
14. Logo 14
En page d'accueil : 
Par Marc Delnatte
Akabia

Gestion de Drupal 8 avec Drupal Console

Comme sur Symfony, Drupal 8 dispose maintenant de son outil Drupal Console. En complément de Drush, Drupal Console permet d’automatiser certaines tâches comme la génération de modules, de blocs, d’entités …

Par vincent59
Vincent Liefooghe

Cartographie rapide avec Drupal

Comme nous le verrons dans cet article, il peut être très rapide d'ajouter des fonctions de cartographie sur un site Drupal, avec quelques modules simples.

Nous allons ici travailler avec une poignée de modules : geolocationctools, views, ip_geoloc et libraries

Quelques étapes seulement sont nécessaires pour y arriver :

  • Activer les modules
  • Créer ou modifier un type de contenu pour ajouter un champ de type "geolocation"
  • Pour aller plus loin, créer une vue reprenant nos différents points de vue

Télécharger et activer le module Geolocation

Avec drush le téléchargement et l'installation se font en deux lignes de commande :

drush dl geolocation
drush en geolocation geolocation_googlemaps geolocation_html5

Ceci active le module principal, ainsi que le "widget" Google Maps et la possibilité de géolocaliser via HTML5.

Création / Modification du contenu

Une fois le module activé, on peut ajouter un champ de type "Geolocation".

On choisit alors le type de "widget" pour la saisie : Google Map (une carte), Latitude / Longitude (2 cases pour la saisie) ou la géolocalisation HTML5.

Voyons le comportement de chacun en saisie...

Latitude / Longitude

Dans ce mode, il faut saisir directement la latitude et longitude. Cela peut être intéressant si on dispose déjà de ces informations.

Géolocalisation HTML 5

Dans ce mode, lorsqu'on coche la case, le navigateur nous propose d'utiliser nos coordonnées.

Ceci n'est évidemment intéressant que dans certains cas, lorsqu'on veut par exemple établir une localisation d'utilisateurs, ou éventuellement avec un site affiché sur mobile.

Google Map

Cette option est beaucoup plus visuelle. Elle s'appuie sur les API de Google Map pour réaliser un premier géocodage, à partir des informations saisies (via le bouton "Get location")

Dès lors, la carte s'affiche avec le marqueur, que l'on peut bouger (ceci se paramètre), afin d'affiner la position directement sur la carte.

Visualisation

De la même manière que pour la saisie, le module propose différents types de formateurs : simple texte, latitude ou longitude en text, carte google map statique, carte google map dynamique, html5 map.
Voyons donc les différents modes de rendu / affichage.

Simple texte

Pas très visuel, on affiche uniquement les données de longitude et latitude.

Par exemple, pour le mont Saint Michel on va trouver quelque chose comme

Geolocation is 48.63559154226376, -1.5108776092529297

Texte simple Latitude ou Latitude

Ceci affiche sous forme de texte la latitude OU la longitude selon le choix défini, de la même manière que précédemment.

Carte Google Map Statique

Ce format d'afichage nous permet déjà de rentrer dans le monde de la cartographie, et d'afficher les coordonnées sur une carte. On dispose de quelques options : la taille de la carte, le format d'image (PNG 8 bits par défaut), le type (route, satellite, hybride) et le niveau de zoom.

Tout ceci est réglable. Par défaut on obtient une carte statique (pas de zoom ni de déplacement).

Carte Google Map dynamique

Nous allons ici un cran plus loin, avec une carte dynamique, sur laquelle on va pouvoir zoomer et scroller. De la même manière que précédemment, on pourra fixer la taille de la carte, le niveau de zoom par défaut et le type de carte (route, satellite).

C'est souvent ce type d'affichage que l'on utilisera avec ce module.

On y retrouve les possibiltiés offertes par Google Map : zoom, déplacement de la carte, choix de l'affichage en mode route ou satellite.

 

 

 

 

HTML5 Image

Cet affichage montre une planisphère, avec la localisation de manière très vague. Personnellement je ne vois pas trop l'intérêt ?

Afficher plusieurs points sur la carte

Pour le moment, nous n'avons pu afficher qu'un seul point sur la carte, celui qui correspond à notre contenu.

Si on veut aller plus loin, il faut passer par le module Views. Il faut cependant ajouter un module qui permettra de faire le lien entre Geolocation et Views : IP Geolocation Views and Maps. Sans cela, il ne sera pas possible d'afficher une seule carte avec tous les contenus.
Commençons par télécharge et activer ces modules (libraries est un pré-requis pour ip_geoloc):

drush dl ctools views ip_geoloc libraries
drush en ctools views views_ui ip_geoloc libraries

Il faut alors créer une vue, qui va afficher les champs de nos contenus. On peut choisir un format "Map (Google API)" :

ainsi que le champ qui contient les données de géolocalisation, le type de marqueur, etc. :

On sauvegarde et on peut alors voir le résultat :

D'autres paramètres sont disponibles dans le module IP Geolocation : choix du marqueur, niveau de zoom et centre de la carte par défaut, etc. C'est un module très riche, et qui peut également s'interfacer avec d'autres modules tels que Leaflet, si l'on ne veut pas dépendre de Google Maps.

On peut aussi afficher des marqueurs différents, sur la base d'une taxonomie liée au contenu, par exemple

Conclusion

Nous avons vu qu'il est possible très rapidement d'ajouter des fonctions de cartographie dans Drupal. Nous verrons dans d'autres articles qu'il existe plusieurs modules permettant d'arriver au même résultat, avec plus ou moins de richesse et de souplesse.

L'avantage du module Geolocation est de proposer une approche tout en un : stockage des coordonnées, widget de saisie et modes d'affichage. Par contre, il n'est pas possible d'avoir une version textuelle de l'adresse en plus de la carte. C'est l'une des limitations de ce module.

Catégorie: 


Tag: 

Par vincent59
Vincent Liefooghe

Cartographie rapide avec Drupal

Comme nous le verrons dans cet article, il peut être très rapide d'ajouter des fonctions de cartographie sur un site Drupal, avec quelques modules simples.

Nous allons ici travailler avec une poignée de modules : geolocationctools, views, ip_geoloc et libraries

Quelques étapes seulement sont nécessaires pour y arriver :

  • Activer les modules
  • Créer ou modifier un type de contenu pour ajouter un champ de type "geolocation"
  • Pour aller plus loin, créer une vue reprenant nos différents points de vue

Télécharger et activer le module Geolocation

Avec drush le téléchargement et l'installation se font en deux lignes de commande :

drush dl geolocation
drush en geolocation geolocation_googlemaps geolocation_html5

Ceci active le module principal, ainsi que le "widget" Google Maps et la possibilité de géolocaliser via HTML5.

Création / Modification du contenu

Une fois le module activé, on peut ajouter un champ de type "Geolocation".

On choisit alors le type de "widget" pour la saisie : Google Map (une carte), Latitude / Longitude (2 cases pour la saisie) ou la géolocalisation HTML5.

Voyons le comportement de chacun en saisie...

Latitude / Longitude

Dans ce mode, il faut saisir directement la latitude et longitude. Cela peut être intéressant si on dispose déjà de ces informations.

Géolocalisation HTML 5

Dans ce mode, lorsqu'on coche la case, le navigateur nous propose d'utiliser nos coordonnées.

Ceci n'est évidemment intéressant que dans certains cas, lorsqu'on veut par exemple établir une localisation d'utilisateurs, ou éventuellement avec un site affiché sur mobile.

Google Map

Cette option est beaucoup plus visuelle. Elle s'appuie sur les API de Google Map pour réaliser un premier géocodage, à partir des informations saisies (via le bouton "Get location")

Dès lors, la carte s'affiche avec le marqueur, que l'on peut bouger (ceci se paramètre), afin d'affiner la position directement sur la carte.

Visualisation

De la même manière que pour la saisie, le module propose différents types de formateurs : simple texte, latitude ou longitude en text, carte google map statique, carte google map dynamique, html5 map.
Voyons donc les différents modes de rendu / affichage.

Simple texte

Pas très visuel, on affiche uniquement les données de longitude et latitude.

Par exemple, pour le mont Saint Michel on va trouver quelque chose comme

Geolocation is 48.63559154226376, -1.5108776092529297

Texte simple Latitude ou Latitude

Ceci affiche sous forme de texte la latitude OU la longitude selon le choix défini, de la même manière que précédemment.

Carte Google Map Statique

Ce format d'afichage nous permet déjà de rentrer dans le monde de la cartographie, et d'afficher les coordonnées sur une carte. On dispose de quelques options : la taille de la carte, le format d'image (PNG 8 bits par défaut), le type (route, satellite, hybride) et le niveau de zoom.

Tout ceci est réglable. Par défaut on obtient une carte statique (pas de zoom ni de déplacement).

Carte Google Map dynamique

Nous allons ici un cran plus loin, avec une carte dynamique, sur laquelle on va pouvoir zoomer et scroller. De la même manière que précédemment, on pourra fixer la taille de la carte, le niveau de zoom par défaut et le type de carte (route, satellite).

C'est souvent ce type d'affichage que l'on utilisera avec ce module.

On y retrouve les possibiltiés offertes par Google Map : zoom, déplacement de la carte, choix de l'affichage en mode route ou satellite.

 

 

 

 

HTML5 Image

Cet affichage montre une planisphère, avec la localisation de manière très vague. Personnellement je ne vois pas trop l'intérêt ?

Afficher plusieurs points sur la carte

Pour le moment, nous n'avons pu afficher qu'un seul point sur la carte, celui qui correspond à notre contenu.

Si on veut aller plus loin, il faut passer par le module Views. Il faut cependant ajouter un module qui permettra de faire le lien entre Geolocation et Views : IP Geolocation Views and Maps. Sans cela, il ne sera pas possible d'afficher une seule carte avec tous les contenus.
Commençons par télécharge et activer ces modules (libraries est un pré-requis pour ip_geoloc):

drush dl ctools views ip_geoloc libraries
drush en ctools views views_ui ip_geoloc libraries

Il faut alors créer une vue, qui va afficher les champs de nos contenus. On peut choisir un format "Map (Google API)" :

ainsi que le champ qui contient les données de géolocalisation, le type de marqueur, etc. :

On sauvegarde et on peut alors voir le résultat :

D'autres paramètres sont disponibles dans le module IP Geolocation : choix du marqueur, niveau de zoom et centre de la carte par défaut, etc. C'est un module très riche, et qui peut également s'interfacer avec d'autres modules tels que Leaflet, si l'on ne veut pas dépendre de Google Maps.

On peut aussi afficher des marqueurs différents, sur la base d'une taxonomie liée au contenu, par exemple

Conclusion

Nous avons vu qu'il est possible très rapidement d'ajouter des fonctions de cartographie dans Drupal. Nous verrons dans d'autres articles qu'il existe plusieurs modules permettant d'arriver au même résultat, avec plus ou moins de richesse et de souplesse.

L'avantage du module Geolocation est de proposer une approche tout en un : stockage des coordonnées, widget de saisie et modes d'affichage. Par contre, il n'est pas possible d'avoir une version textuelle de l'adresse en plus de la carte. C'est l'une des limitations de ce module.

Catégorie: 


Tag: 

Par Marc Delnatte
Akabia

Migration d'un site Drupal 6

Sortie depuis le 19 Novembre dernier, Drupal 8 va très certainement révolutionner le marché du CMS Open source. Mais cela n’est pas sans conséquence, la fin du support de Drupal 6 ( voir Drupal 6 end-of-life announcement) a aussi été annoncé à la date du 24 février 2016.

La problématique de migrer de Drupal 6 vers une version supérieure de Drupal doit donc se poser dès maintenant.

Par Artusamak
Julien Dubois

Drupal 8 : fonctionnement des permissions

Drupal 8 : fonctionnement des permissions
lun, 18/01/2016 - 17:54
Artusamak

Comme dans Drupal 7, le contrôle d’accès de base de Drupal 8 repose sur les permissions rattachées aux rôles des utilisateurs. Même si le concept de base n’a pas changé, la façon dont il est implémenté a lui été repensé pour être plus cohérent avec le reste.

Définition des permissions

Ainsi, les rôles sont désormais des entités de configuration identifiées par un nom machine et disposant d’un label traduisible. Elles portent également un booléen is_admin qui remplace la variable user_admin_role de Drupal 7 et permet de définir un ou plusieurs rôles disposant de toutes les permissions. Enfin, contrairement à Drupal 7 dans lequel c’étaient les permissions qui portaient la liste des rôles rattachés (du moins lors d’un export via Features), chaque rôle contient désormais une liste des permissions qui lui sont associées.

# user.role.authenticated.yml
uuid: 31ee396d-455b-48c6-ae00-aad6f105fe13
langcode: en
status: true
dependencies: {  }
id: authenticated
label: 'Authenticated user'
weight: 1
is_admin: false
permissions:
 - 'access content'
 - 'use text format basic_html'
 - 'access comments'
 - 'post comments'
 - 'skip comment approval'
 - 'access site-wide contact form'
 - 'access shortcuts'

Les permissions quant à elles restent aussi simples qu’avant. Au lieu d’utiliser un hook_permission() pour les définir, on utilise un fichier *.permissions.yml comme suit :

# my_things.permissions.yml
administer my things:
  title: 'Administer my things'
  description: 'Create, update and delete all my things.'
  restrict access: true
access my things:
  title: 'Access my things'
  description: 'View all my things.'

Étant donné que la déclaration des permissions ne se fait plus en PHP, il n’est plus aussi évident de les définir de façon dynamique. Il est toutefois possible de spécifier une ou plusieurs fonctions de callback à appeler pour y parvenir. Cela se fait via la clef permission_callbacks du fichier *.permissions.yml :

# my_things.permissions.yml
permission_callbacks:
  - \Drupal\my_things\MyThingPermissions::dynamicPermissions
# MyThingPermissions.php
namespace Drupal\my_things;
use Drupal\Core\StringTranslation\StringTranslationTrait;
use Drupal\my_things\Entity\ThingType;
/**
 * Provides dynamic permissions for my things.
 */
class MyThingsPermissions {

  use StringTranslationTrait;

  /**
   * Returns an array of permissions.
   *
   * @return array
   *   The permissions.
   *   @see \Drupal\user\PermissionHandlerInterface::getPermissions()
   */
  public function dynamicPermissions() {
    $perms = array();
    // Generate permissions for all things types.
    foreach (ThingType::loadMultiple() as $type) {
      $type_id = $type->id();
      $type_params = ['%thing' => $type->label()];
      $perms += [
        "create $type_id thing" => [
          'title' => $this->t('%thing: Create new thing', $type_params),
        ],
        "edit $type_id thing" => [
          'title' => $this->t('%thing: Edit any thing', $type_params),
        ],
        "delete $type_id thing" => [
          'title' => $this->t('%thing: Delete any thing', $type_params),
        ],
      ];
    }
    return $perms;
  }
}

Pour finir il est important de noter qu’il n’est toujours pas possible actuellement d’altérer les permissions définies par le cœur ou par un autre module. La demande de la communauté n’étant pas spécialement pressante, il est peu probable que l’on voit apparaître cette fonctionnalité dans les prochains mois.

Contrôle d’accès simple

Dans Drupal 7, la façon la plus simple et rapide de tester si l’utilisateur dispose d’une permission est l’appel à la fonction user_access(). Dans Drupal 8, cette fonction a été remplacée par la méthode AccountInterface::hasPermission().

# Controller.php
// Vérification que l'utilisateur courant a une permission donnée.
\Drupal::currentUser()->hasPermission('name of permission');
// La même vérification pour un utilisateur précis.
$account = User::load('3');
$account->hasPermission('name of permission');

D’autres contrôles d’accès étaient faits de façon plus automatique comme par exemple lorsque l’on spécifiait un nom de permission dans une clef access arguments d’une entrée du hook_menu(). Dans Drupal 8, on retrouve une clef équivalente dans la partie requirements de nos routes.

Exemple :

# my_things.routing.yml
my_things.settings:
 path: '/admin/config/my_things'
 defaults:
   _form: '\Drupal\my_things\Form\SettingsForm'
 requirements:
   _permission: 'administer my things'

Nouveauté par rapport à Drupal 7 : il est désormais possible d’associer plusieurs permissions à une même route en les séparant soit par une virgule, soit par un plus (+). La virgule équivaut à un ET alors que le plus équivaut à un OU. Il n’est pas possible de combiner les virgules et les plus en utilisant cette syntaxe.

Exemples :

_permission: 'administer my things+administer content'
_permission: 'access thing TYPE,access restricted things'

Contrôle d’accès avancé

Si d’aventure vous souhaitez avoir une logique plus avancée pour gérer le contrôle d’accès, il faut utiliser la clé _custom_access au lieu de _permission, sa valeur est la référence d’une méthode à appeler intégrant la classe à laquelle elle est rattachée. À noter que le contrôleur d’accès doit retourner un objet de type AccessResultInterface.

Exemple :

# my_things.routing.yml
my_things.all:
 path: '/things/all'
 defaults:
   _controller: '\Drupal\my_things\Controller\ThingsController::all'
   _title: 'All things'
 requirements:
   _custom_access: '\Drupal\my_things\Controller\ThingsAccess::all'
# ThingsAccess.php
namespace Drupal\my_things\Controller;
use Drupal\Core\Session\AccountInterface;
use Drupal\Core\Access\AccessResult;
class ThingsAccess {
  /**
   * Randomly limit access to the things.
   *
   * @param \Drupal\Core\Session\AccountInterface $account
   */
  public function all(AccountInterface $account) {
    if (rand() > 0.5) {
      return AccessResult::allowed();
    }
    return AccessResult::forbidden();
  }
}

Les objets de type AccessResultInterface disposent de nombreuses méthodes statiques très utiles pour autoriser ou restreindre l’accès de façon conditionnelle tout en évitant les problèmes liés aux performances. Par exemple, vous pourriez choisir de restreindre l’accès à un contenu en fonction d’un état calculé de manière complexe et des permissions de l’utilisateur tout en garantissant que cet accès redevienne fonctionnel au moment même où l’état change ou à tout moment pour les utilisateurs autorisés.

Exemple :

# my_things.routing.yml
entity.my_things.canonical:
 path: '/things/{thing}'
 defaults:
   _controller: '\Drupal\my_things\Controller\ThingsController::view'
   _title_callback: '\Drupal\my_things\Controller\ThingsController::title'
 requirements:
   _custom_access: '\Drupal\my_things\Controller\ThingsAccess::view'
# ThingsAccess.php
namespace Drupal\my_things\Controller;
use Drupal\Core\Session\AccountInterface;
use Drupal\Core\Access\AccessResult;
user Drupal\my_things\Entity\Thing;
class ThingsAccess {
  /**
   * Limit access to the things according to their restricted state.
   *
   * @param \Drupal\Core\Session\AccountInterface $account
   * @param \Drupal\my_things\Entity\Thing $thing
   */
  public function view(AccountInterface $account, Thing $thing) {
    $is_restricted = $thing->myComplexState() === 'restricted';
    $has_permission = AccessResult::allowedIfHasPermission($account, 'access restricted   things');

    $result = AccessResult::allowedIf($is_restricted)->andIf($has_permission);
    $result->addCacheableDependency($thing);

    return $result;
  }
}

Dans cet exemple, on met le résultat en cache pour tous les utilisateurs ayant les mêmes permissions (grâce à l’appel à allowedIfHasPermission) et tant que l’entité $thing n’est pas modifiée. Ainsi, même si le calcul effectué dans $thing-&gt;myComplexState() est coûteux, il n’aura d’impact sur l’accès à ce contenu que la première fois que l’on interrogera cette méthode d’accès.

Par Kgaut
Kevin Gautreau

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

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

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

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

Installation de Drupal Console

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

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

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

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

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

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

Configuration initiale

Via la commande

drupal init

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

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

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

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

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

  language: en

à

  language: fr

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

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

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

Fish: Créez un lien symbolique

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

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

Drupal Console & Drupal 8

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

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

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

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

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

drupal list

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

Génération d'un module

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

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

Lancez la commande et laissez-vous guider :

drupal generate:module  

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

 Entrez le nom du nouveau module:
 > Mon Module

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

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

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

 Entrez le nom du paquet [Other]:
 > Kgaut

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

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

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

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


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

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

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

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

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

Mise à jour de Drupal Console

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

sudo drupal self-update

 

Par Artusamak
Julien Dubois

Drupal 8 : le routage

Drupal 8 : le routage
lun, 11/01/2016 - 22:42
Artusamak

Depuis quelques années, les applications se sont complexifiées. Les APIs se sont multipliées et avec leur usage le respect de la norme HTTP s’est amélioré.

Pourquoi parler de HTTP ? Car c’est le fondement de toute action que vous faites avec un navigateur.

Lorsque vous cliquez sur un lien, lorsque vous soumettez un formulaire, un verbe HTTP est utilisé. Vous les connaissez, il s’agit respectivement des verbes GET et POST mais il en existe d’autres (PUT, DELETE, etc.). Drupal 8, en s’appuyant sur le composant Symfony HTTPFoundation, respecte bien mieux ces verbes que dans ses versions précédentes.

A chaque fois que vous faites appel à une ressource (au sens URL ou URI), deux actions se déroulent en permanence : l’appel de la ressource, la requête (Request) et la construction de sa réponse (Response). La réponse d’une requête est générée par un contrôleur.

Drupal8Routing.png

Schéma issu de la documentation drupal.org / CC BY-SA 2.0

Les requêtes et les réponses peuvent donc être manipulées à travers deux objets distincts grâce au composant Symfony HTTPFoundation. Et le Routage dans tout cela ?

Le Routage sert à identifier quel contrôleur doit être utilisé pour générer la réponse à retourner à la requête.
Pour cela, Drupal s’appuie maintenant sur le système de routes de Symfony.

Une Route représente une ressource à laquelle nous faisons appel pour servir une page. C’est ce qui fait la connexion entre une URI et le code qui va générer sa réponse.  Voici un exemple de route :

 #user.routing.yml user.logout:   path: '/user/logout'   defaults:     _controller: '\Drupal\user\Controller\UserController::logout'   requirements:     _user_is_logged_in: 'TRUE'

Chaque route se voit attribuée un nom arbitraire qui permettra de la désigner à travers notre base de code (pour faire un lien par exemple). La définition d’une route agrège à minima les paramètres suivants :

  • path (obligatoire) : chemin par lequel l’utilisateur accède à la route
  • defaults (obligatoire) : tableau indiquant quelles données utiliser lorsque la route est appelée
  • requirements (obligatoire) : tableau de conditions à valider pour pouvoir accéder à la route.

Pour connaître les subtilités des données à envoyer aux routes, reportez-vous à la page de documentation dédiée. (https://www.drupal.org/node/2092643)

Un exemple de réponse de route est le suivant :

# UserController.php namespace Drupal\user\Controller; use Drupal\Core\Controller\ControllerBase; use Symfony\Component\DependencyInjection\ContainerInterface; use Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException; /**  * Controller routines for user routes.  */ class UserController extends ControllerBase {  /**   * Logs the current user out.   *   * @return \Symfony\Component\HttpFoundation\RedirectResponse   *   A redirection to home page.   */  public function logout() {    user_logout();    return $this->redirect('');  } }

Le principal avantage apporté par les routes réside dans le fait que si vous voulez supplanter le comportement par défaut d’une route (comme modifier la permission nécessaire pour accéder à la page) il vous suffit d’écrire quelques lignes de code pour indiquer au système de générer une réponse totalement différente.

# RouteSubscriber.php use Drupal\Core\Routing\RouteSubscriberBase; use Symfony\Component\Routing\RouteCollection; /** * Listens to the dynamic route events. */ class RouteSubscriber extends RouteSubscriberBase { /** * {@inheritdoc} */ public function alterRoutes(RouteCollection $collection) { // Change path '/user/login' to '/login'. if ($route = $collection->get('user.login')) { $route->setPath('/login'); } } }

 

# module.services.yml services: foo.route_subscriber: class: Drupal\foo\Routing\RouteSubscriber tags: - { name: event_subscriber }

Ce qui est très intéressant et très puissant c’est qu’en modifiant simplement un en-tête lors de l’appel d’une route, la réponse d’une page peut être radicalement différente. Elle peut par exemple retourner du JSON ou du HTML et ce simplement grâce à l’ajout d’un paramètre _format.
L’intérêt est de gérer ce genre de demande très tôt dans la génération de la page (et donc à un niveau très bas) pour éviter les calculs et traitements inutiles. Pourquoi attacher des feuilles de styles et fichiers Javascript si vous allez faire une réponse en JSON ?

Par Artusamak
Julien Dubois

Drupal 8 : structure des fichiers d'un module

Drupal 8 : structure des fichiers d'un module
mer, 06/01/2016 - 21:52
Artusamak

La structure des modules a évolué avec Drupal 8, le format YAML ayant pris le pas sur le format INI, le .info hérite logiquement de l'appendice .yml. C'est d'ailleurs le seul fichier obligatoire pour faire vivre un module. Ça n'avance pas forcément à grand chose s'il n'y a que ce fichier évidemment mais c'est la répercussion du fait que vous écrirez de moins en moins de hooks (souvent remplacés par des classes, nous y reviendrons).

Les modules ne peuvent plus être dans l’état désactivé, ils sont soit installés soit désinstallés et désinstaller un module retire du système sa configuration.

La conséquence directe de cela est la disparition des hooks suivants :

  • hook_modules_preenable()
  • hook_enable()
  • hook_modules_enabled()
  • hook_disable()
  • hook_modules_disabled()
  • hook_modules_preinstall()

Les fonctions module_enable() et module_disable() filent au musée car elles sont remplacées par une syntaxe à la sauce POO. Pour installer et désinstaller des modules, il faut maintenant utiliser la syntaxe suivante :

// Activation d'un module version D7.
module_enable(array('mymodule'));

// Activation d'un module version D8.
\Drupal::service('module_handler')->install(array('mymodule'), $enable_dependencies);

// Désinstallation d'un module version D7.
module_uninstall(array('mymodule'));

// Désinstallation d'un module version D8.
\Drupal::service('module_handler')->uninstall(array('mymodule'), $enable_dependencies);

Les modules peuvent définir d’autres informations telles que :

  • Des librairies (<module_name>.libraries.yml)
  • Des entrées de routeur (<module_name>.routing.yml)
  • Des entrées de menu associées à des entrées de routeur (<module_name>.links.<type>.yml)
  • Des permissions (<module_name>.permissions.yml)
  • Des services (<module_name>.services.yml)

Votre code métier devrait glisser du fichier .module vers des classes. La norme PSR-4 est le nouveau standard embrassé pour organiser ces dernières. Elle en permet le chargement automatique, à la demande. Cela engendre l’apparition d’un dossier /src voire d’un dossier /tests afin de respectivement implémenter vos classes de code métier et vos tests.

On retrouvera aussi de manière régulière les répertoires /config/install et /config/optional qui permettent de fournir les fichiers YAML de configuration par défaut de différents composants de Drupal (View mode, Type de contenu, Configuration, etc.).
Le dossier install contient les éléments qui seront obligatoirement utilisés par votre module, le dossier optional quant à lui contient les configurations utilisables par d'autres modules. Exemple : vous développez un module générique qui peut s'interfacer avec Views. Vous ne savez pas si Views sera utilisé sur le site, vous ne voulez donc pas ajouter une dépendance sur ce module dans le fichier .info.yml mais vous voulez tout de même fournir une vue le cas échéant. Dans ce scénario, il vous suffit alors de placer l'export de votre vue dans le dossier /config/optional et si un utilisateur installe Views sur son site, votre vue sera visible sans action supplémentaire de sa part.

Un dossier /config/schema/ peut également exister, il contient (entre autres) la description de la structure des données lorsqu'elles sont exportées via l'API de configuration.

Par admin

Concours de logo Drupal France et francophonie - Brief créatif

1. Brief créatif

Qui ?

Drupal France et francophonie, association loi de 1901, est le représentant officiel en France de la communauté qui développe et édite le logiciel libre gratuit Drupal.

Elle s'occupe en particulier de promouvoir Drupal et son utilisation, sa traduction en français, d'encourager la documentation en français, et d'organiser des événements liés à Drupal. Elle favorise et organise des échanges autour des sujets qui touchent ou concernent Drupal.

Elle défend les intérêts du projet Drupal et de sa communauté, ainsi que la marque Drupal sur la France.

Au-delà de la France l'Association Drupal France et Francophonie peut intervenir dans des pays francophones qui n'ont pas d'association établie.

La Drupal Association est l'association internationale qui représente et organise le projet Drupal et sa communauté au niveau mondial. Son site officiel est drupal.org qui est LE site de référence mais est en anglais.

Dries Buytaert est le créateur du projet Drupal, en reste le leader et est président de la Drupal Association. Dries est titulaire de la marque Drupal et délègue sa gestion à la Drupal Association qui peut la déléguer à des associations nationales.

Drupal France et Francophonie agit sous l'égide de la Drupal Association et peut faire appel à elle ou à Dries Buytaert en cas de besoin.

Actuellement, Drupal France et francophonie dispose du logo ci-dessous.

logo actuel

A la création de l'association, celle-ci aurait dû s'appeler logiquement Drupal France, mais elle a été appelée « Drupal France et francophonie » pour se différencier d’un nom de domaine occupé et que l’association a depuis prévu de récupérer.
Le site officiel pour Drupal en France est celui de Drupal France et francophonie.
Aujourd’hui le site de l’association est drupalfr.org, mais après analyse des autres associations à travers les communautés, l’utilisation d’un autre nom de domaine à court terme, comme par exemple drupal.fr, aussi détenu par l’association semble plus légitime et faciliterait la reconnaissance du public. Le nom de domaine est donc susceptible de changer par rapport à ce qui est indiqué ci-dessous.

Drupal France et francophonie n'a pas encore une identité à la hauteur de ses responsabilités et missions. Le fait d’être mentionné comme Drupalfr, DFR, ADFF, DFF, Drupal France ou Drupal France et francophonie selon les locuteurs, est pénalisant pour l'association et surtout pour la communication et la promotion de Drupal en France, même si la demande forte pour cette solution libre masque ces enjeux.

Pourquoi un nouveau logo ?

Le logo actuel, créé en même temps que l'association, a le mérite d'exister et de bien représenter Drupal, mais ne représente pas clairement l'association française.
Parmi les points négatifs du logo actuel, nous avons reçu les remarques suivantes :
- logo pas assez lisible, fouillis
- ressemble à celui d'un événement indépendant de Drupal France et francophonie.
- passe mal en très petit
- difficile à décliner
Au cours des dernières années, la stature et les missions de l'association française ont évolué, grâce à un travail de clarification mené avec la Drupal Association. Ces évolutions permettront et doivent s'accompagner de la clarification de l'identité de l'association.
La création d'associations Drupal dans d'autres pays francophones va amener Drupal France et francophonie à se recentrer sur la France, tout en conservant sa mission d'appui à des pays francophones qui n'ont pas d'association établie.

Nous souhaitons traduire dans le logo une identité claire et forte, pour améliorer la visibilité de Drupal et de l'association, particulièrement en France, en unifiant nos différents modes de communication : Nom usuel de l’association, url du site.

Buts recherchés

Le nouveau logo doit envoyer les messages suivants :
- Drupal
- France
- représentant officiel
Quelques idées ou mots-clés qui peuvent alimenter votre réflexion :
- échange
- collaboration
- mouvement (l'association et Drupal évoluent en permanence)

Nom juridique : Drupal France et francophonie
Nom pour la communication : Drupal France (avec éventuellement une baseline comportant “association” et/ou “communauté”, “francophonie”)
Nom usuel : Drupal France
URL du site : drupal.fr
Twitter : drupalfr

A éviter

Ce que nous souhaitons éviter
- une mascotte
- des indications géographiques trop restrictives : tour Eiffel, centrée sur Paris.
- des initiales ou raccourcis : DFF, ADFF, drupalfr, dfr, ...

2. Brief technique

Type de livrable souhaité

  • un logo, avec si nécessaire une déclinaison monochrome
  • un format vectoriel pour pouvoir l'adapter à différentes dimensions,
  • si le logo comporte un pictogramme, avoir la possibilité d'utiliser ce dessin seul sans le texte,
  • lisible en petit… mais aussi utilisable en grand, car l'association l'utilisera dans des contextes très variés : cartes de membre, site web, favicon, plaquettes, kakémono, …

Au terme du concours, le logo sera demandé en plusieurs formats utilisables pour les différents supports de communication.

Quel nom sur le logo ?

Si un texte est indiqué, ce serait « Drupal France ». Le logo doit être aussi disponible sans le texte pour permettre de modifier ce texte simplement. Le texte peut être accompagné des mentions “association”, “communauté” et ou “francophonie”.

3. Modalités

Dates

Les propositions de logo doivent être reçues par le bureau au plus tard le 31 janvier à minuit, par mail à bureau@listes.drupalfr.org.

Si les résultats reçus permettent un choix, celui-ci sera présenté lors de l’assemblée générale annuelle de l’association (après le 15 février).

Engagement

Le logo du gagnant ou de la gagnante sera utilisé sur le site officiel de l'association, sur les sites de ces événements, sur les pages partenaires des événements auxquels nous participons, sur des badges, kakémonos, tee-shirts, plaquettes, ...

Dans le cas où aucun logo ne paraîtrait répondre aux attentes, le bureau pourrait demander à un ou plusieurs candidats des améliorations à leur proposition. Les candidats sollicités disposeraient d'un mois pour peaufiner leur logo. Si ensuite aucun résultat n'est convainquant, le bureau se réserve le droit de déclarer le concours infructueux.

Visibilité des logos

Les propositions reçues seront visibles même avant la date limite de remise en étant ajoutées sur le site officiel par le bureau. Elles seront ouvertes aux commentaires des adhérents. Les participants pourront aussi les partager via les réseaux sociaux.

4. Finalisation

Le gagnant ou la gagnante s'engage soit à modifier le logo pour le finaliser selon les besoins ou remarques du jury, soit accepte que quelqu'un d'autre le modifie.
Le logo pourra être cédé gratuitement à l’association ou publié sous une licence Creative Commons ou autre licence réservant son utilisation à l’association.

Prix

Le gagnant ou la gagnante du concours se verra remercié publiquement par l’association via son compte Twitter et son site. Son travail sera publié, et il ou elle pourra le commenter. Il sera mis en avant, personnellement et professionnellement, sur les différents canaux de communication.
Aucune compensation financière ne sera remboursée, ce concours est gratuit.

Jury

La décision finale du choix du logo sera faite par le bureau de l’association. Avant cette décision, l’ensemble des logos proposés seront publiés sur une page du site de l’association, qui sera ouverte aux commentaires, sans votes. Les participants au concours pourront aussi de leur côté publier sur leur site ou sur les réseaux sociaux leurs propositions.

A vos crayons !

PS : Un grand merci à Philippe Gervaise qui nous a bien aidé dans la préparation de ce brief.

En page d'accueil : 
Par Artusamak
Julien Dubois

Drupal 8 : les outils

Drupal 8 : les outils
lun, 14/12/2015 - 23:08
Artusamak

La communauté Drupal a toujours cherché à améliorer le confort de ses participants. Cela a donné naissance à plusieurs outils gravitant autour de Drupal et de son code. Il y en a pour tous les goûts, de simplytest.me (service en ligne pour évaluer un ensemble de modules Drupal) à Dreditor (script enrichissant drupal.org pour les contributeurs) en passant par Drupal For Firebug ou Devel (outils pour faciliter la vie du développeur).

Drush

Au milieu de tous ces outils trône Drush, véritable compagnon du développeur, ce script PHP à utiliser dans un shell est une boîte à outils essentielle au quotidien. Pour ceux qui ne connaissent pas Drush, sachez que c’est un indispensable permettant de manipuler Drupal depuis la ligne de commande. Il fonctionne sous Linux, Mac et Windows. On peut lancer une installation, une sauvegarde, vider les caches, changer un mot de passe, créer du contenu, lancer des migrations, télécharger et activer des modules, etc. Enfin, les commandes sont extensibles par les modules ce qui ouvre énormément de possibilités.

Notez que la commande la plus utilisée drush clear-cache all (et son alias drush cc all) n’existe plus, elle est remplacée par la commande drush cache-rebuild (et son alias drush cr).

Drush make

Cette commande utilise un “makefile”, qui est un fichier décrivant une installation, où trouver les modules ou les librairies, quelle version prendre, etc pour construire un Drupal automatiquement. C’est très utile pour faciliter la création de distribution ou faire du déploiement continu.

Drupal Console

L’adoption du développement orienté objet dans Drupal 8 nécessite d’écrire du code un peu plus verbeux. Symfony utilise un composant nommé Console permettant d’automatiser la génération de ce code via la ligne de commande. Drupal a étendu cet outil à ses composants et il est donc possible de s’en servir pour générer du code à partir de template pour pas mal d'éléments de Drupal 8 (des pages, des formulaires, des entités, des blocs, etc). Cette Console peut aussi servir à activer des modules, vider les caches, lancer des migrations…

Cela fait un peu doublon avec Drush. D’ailleurs la Console Drupal peut même lancer des commandes Drush. Il faut tout de même savoir que les équipes de Drush et de Drupal Console travaillent de concert et il semble aujourd’hui que Drush se dédie à devenir le couteau suisse d’un Drupal existant, alors que la Console Drupal servira surtout durant le développement pour générer du code, lancer des tests, etc...

Composer

Composer est un outil de gestion de paquets et de dépendances d’un projet venant du monde PHP. Il est utilisé dans de nombreux projets PHP dont Drupal 8. C’est une sorte de drush make (mais en mieux) qui peut télécharger pour vous la version spécifique des librairies à l’aide d’un simple fichier de configuration composer.json tout en gérant les dépendances récursives.

Il s’occupe aussi de générer les fichiers autoload.php permettant à l’application de charger automatiquement les classes des librairies téléchargées quand elles sont appelées.

Ressources associées

Par flocondetoile
Adhérent

Réaliser des tris sur des vues indexées de Drupal Search API

Photo de lego

J'ai été confronté récemment à un bug pour le moins atypique. J'obtenais des contenus dupliqués et/ou manquants sur différentes paginations d'une même vue basée sur Search API. Un bug présent sur le site de production, sur le site de preprod mais différement, et quasi-absent de l'instance de développement. Et le tout apparaissant de façon aléatoire. Après avoir chercher sans relâche sur les termes "drupal search api duplicate sorting" ou "drupal search api duplicate pagination" ou toutes les déclinaisons possibles, je souhaite partager le résultat d'un debug bien corsé.

Thème 
Drupal 7
Commerce
Développement

Par Kgaut
Kevin Gautreau

Générateur de squelette de site Drupal 7

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

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

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

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

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

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

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

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

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

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

 

Par flocondetoile
Adhérent

Les nouveautés de Drupal 8 : son système de configuration

Chaines soutenant un ascenceur

Le système de configuration de Drupal 8 constitue une nouveauté et amélioration majeure de Drupal 8, portée par l'initiative CMI. Le principe en est simple : séparer la configuration d'un site Drupal 8 de son contenu. Cette distinction entre configuration et contenu permet une transition entre plusieurs environnements d'un même site. Toutes les configurations sont stockées désormais au moyen de simple fichiers texte (au format YAML), ce qui sécurise toute modification et évolution si on dispose d'un système de versionning du système de fichiers. Ainsi, des changements et évolutions d'un site Drupal 8 peuvent être envisagées beaucoup plus sereinement. Découvrons les concepts clés de cette nouveauté majeure de Drupal 8.

Thème 
Drupal 8
Configuration
CMI

Pages