Planète

Par admin

Assemblée générale de l'association, le 5 avril 2017

Chers adhérents,

Nous avons le plaisir de vous convier à l'assemblée générale ordinaire de notre association mercredi 5 avril 2017, conformément à l'article 8 des statuts, qui se tiendra à 18h30 à la Maison des Associations du 3ème, 5 rue Perrée, 75003 Paris.

J'attire votre attention sur le fait que l'assemblée générale a besoin d'un taux de participation ou représentation (pouvoirs) suffisant pour atteindre le quorum nécessaire au vote. Votre participation marque aussi votre soutien à l'association et à ses actions.

Vous devez être adhérent à jour de votre cotisation pour participer à cette assemblée générale et voter.

L'assemblée générale ordinaire aura à l'ordre du jour suivant :

  • Rapport moral présenté par le président
  • Rapport financier présenté par le trésorier
  • Élection du nouveau bureau
  • Questions ouvertes

Le bureau doit se renouveler

L'actuel bureau est en place depuis 3 ans et il est temps de faire une rotation. Nous sommes donc à la recherche de candidats pour les 3 postes du bureau : secrétaire, trésorier et président.
Pour aider ceux qui le souhaitent, les membres sortant pourront se présenter à un poste d'adjoint pour accompagner la transition.
Alors si vous avez quelques heures par mois pour discuter du fonctionnement de l'association et pour suivre les projets du bureau, nous attendons vos candidatures par email à bureau@listes.drupalfr.org

Le vote

Si vous ne pouvez être physiquement présent lors du vote, vous pouvez vous faire représenter par un autre membre de l'association muni d'un pouvoir régulier (ou en l'envoyant à l'adresse de l'association au minimum 4 jours avant l'assemblée générale ou par scan signé à bureau@listes.drupalfr.org). Le pouvoir est disponible ci-dessous.

Comment assister à distance à l'assemblée générale ?

Vous pouvez également participer à l'assemblée générale par un moyen de communication électronique permettant de vous identifier formellement. Dans ce cas, si vous souhaitez participer aux votes vous devrez renoncer à l'anonymat des votes afin de les transmettre.

En page d'accueil : 
Par GoZ
Fabien CLEMENT

Mise à jour de Drupaloscopy

Mise à jour de Drupaloscopy

Drupaloscopy est un service permettant de savoir si un site utilise Drupal, connaitre la version utilisée et test quelques configurations de base tels que l'aggrégation, la protection de fichiers TXT, l'utilisation de cache.

Le service fonctionne via des scripts bashs qui se basent sur le hash des fichiers css et js pour déterminer la version du site Drupal.

GoZ
dim 12/03/2017 - 18:32

Par Artusamak
Julien Dubois

Happyculture aux Drupal Developer Days Séville

Happyculture aux Drupal Developer Days Séville
Artusamak
ven 10/03/2017 - 14:31

Du 21/03/2017 au 25/03/2017 se tiendra la nouvelle édition des Drupal Dev Days à Séville. Si vous nous suivez, vous savez que nous sommes des fidèles de l'événement puisque nous n'en avons raté aucun depuis leur création ! Milan l'année dernière, Montpellier l'année d'avant...

Cette année l'équipe se rendra au sud de l'Espagne pour retrouver la communauté, débattre des sujets du moment et sprinter pendant la semaine. Nous ne serons pas au grand complet malheureusement pour une raison tout à fait valable mais nous serons tout de même bien présents pour vous permettre d'être bien éveillés tout au long de la semaine grâce à notre package de sponsoring café !

Badge sponsor café pour les DDD 2017

Il reste des places pour vous inscrire, vous pouvez également consulter le programme. Si vous n'avez jamais participé à un événement du genre, c'est toujours une parfaite occasion de rejoindre la communauté et de prendre part aux nombreux sprints.

En espérant vous y voir, n'hésitez pas à venir nous dire coucou sur place.

Par flocondetoile
Adhérent

Personnaliser le menu d'administration de Drupal 8

Drupal 8 dispose nativement d'une barre d'outils responsive permettant d'administrer le site. Cette barre d'outils contient le menu principal d'administration ainsi que l'accès aux raccourcis et au compte utilisateur, et si elle s'avère très utile à l'administration et conception du site, elle reste peu utile aux utilisateurs et gestionnaires de contenus d'un site. Découvrons comment l'utiliser pour personnaliser des menus dédiés à ces profils d'utilisateur.

Par Kgaut
Adhérent
Kevin Gautreau

Module Drupal 8 - Flag, un « j'aime » en plus puissant

Flag est un module drupal 7 et 8 permettant de « Marquer » du contenu.

Pour avoir une idée simple de ce que cela veut dire, on peut penser au « j'aime » de facebook. Si un utilisateur clique sur le « J'aime » en dessous d'une photo, alors il la flag.

Par défaut un flag est personnel, donc chacun possède ses propres contenus flagués ou non. Mais un flag peut aussi être global, et dans ce cas, un contenu flagué le sera pour l'ensemble des membres.

Via l'interface d'administration du module, on peut gérer autant de type de flag que l'on veut :

liste des flags

Un flag ne peut s'appliquer qu'à un type d'entité, mais par contre peut s'appliquer à l'ensemble de ses bundles, ou non. Par exemple on peut créer un type de flag pour les nœuds, mais le restreindre à certains types de contenus.

Ensuite le flag peut se comporter comme un champs que l'on choisi d'afficher ou non suivant les view mode, on peut personnaliser pas mal d'option d'affichage :

Options flag

Flag options 2

Flag s'intègre bien avec actions, rules, views...

Les flags sont des types d'entités auxquels on peut ajouter des champs. Si par exemple on l'utiliser pour faire du reporting de contenu non légal, il est utile d'ajouter une zone de texte pour que l'utilisateur explique pourquoi il reporte le contenu.

Pour installer le module deux options, soit via composer avec :

composer require drupal/flag

Soit en le téléchargeant directement sur la page du module sur drupal.org : https://www.drupal.org/project/flag

Par Kgaut
Adhérent
Kevin Gautreau

PHP, Git, MySQL, configuration et environnements

Un point qui revient souvent lors du développement est la gestion des paramètres de configuration (MySQL par exemple) sur les différents environnements (production, préproduction, local…) et entre différents développeurs d'une même équipe.

Si l’on est tout seul à travailler sur un projet avec un seul environnement (la production) alors la question ne se pose pas, on met les paramètres dans le fichier de configuration (wp-config.php pour wordpress, settings.php pour drupal…) et ça fonctionne.

Le problème du versioning de la configuration

Mais si l’on utilise un système de gestion de version (git avec gitlab / github par exemple) alors cela veut dire que nos identifiants de connexion à la base de données de notre site en production sont stockés sur d’autres serveurs que l’unique sur lequel il devrait être...

Github et Gitlab sont des solutions éprouvées, mais on est jamais à l’abri d’une fuite ou d’un piratage, ou tout bêtement de l’oubli de désactiver l’accès au dépôt à un ancien collaborateur avec qui l’histoire s’est mal terminée et qui a une éthique pro douteuse.

Le problème du travail en équipe

Autre potentiel problème, imaginons une équipe de deux personnes (A et B) qui travaillent en local sur un site en développement.

A travaille sous windows avec wamp, par défaut l’identifiant de connexion à la base de données sous wamp est «root», il n’y a pas de mot de passe.

B travaille sous macos avec mamp, par défaut l’identifiant de connexion à la base de données sous mamp est «root», le mot de passe est lui «root».

On voit vite le jeu que cela va être à chaque commit, A et B s'écrasant mutuellement le fichier de configuration de l’autre.

En plus, notre sysadmin étant moins drôle, il refuse de définir le mot de passe de mysql en production sur «root», encore moins marrant, il refuse de ne pas en définir… Donc on se retrouve avec un troisième jeu d'identifiants que l’on devra (re)mettre à chaque mise à jour du site en production…

Note : évidement utiliser "root" comme idenfiant ou mot de passe, ailleurs qu'en local est évidement à éviter impérativement ! Il faut créer un utilisateur qui n'a la main que sur la (ou les) base(s) de données du site. Bonne pratique à utiliser aussi en local, même si c'est moins «dangereux».

Le problème des environnements

En plus des différences d’identifiants de base de données, il existe souvent d’autres divergences entre deux environnements d’un même site.

Généralement notre site ne fonctionne pas exactement pareil en local, sur notre serveur de développement, sur notre préproduction et sur notre serveur de production.

Par exemple, si l'on travail sur un site d'e-commerce, on aura pas forcément la même brique de paiement, ou il faudra lui passer des paramètres différents pour activer le mode test.

Autres exemples : l'affichage des messages d'erreurs, la désactivation du cache en local pour éviter d’avoir à le vider manuellement à chaque modification...

Enfin, On peut (doit ?) aussi désactiver ou intercepter les envois de mail sur les autres serveurs que celui de production.

Les solutions

Avertissement

Les solutions décrites ici sont des solutions que j'ai trouvées, expérimentées, modifiées... Je n'en réclame ni la paternité ni leur supériorité sur une autre solution, d'ailleurs, si vous faites autrement, n'hésitez-pas à en parler.

Se baser sur le HTTP_HOST

Un première possibilité serait, au sein même du fichier de configuration, d’ajouter des conditions en fonction de l’url par exemple.

Ainsi si l’url du site est “monsite.dev” on sait que l’on est en local, si c’est "monsite.com" alors on est en production.

Exemple de code :

//Paramètres par défaut = production
$databases = array (
  'default' => 
  array (
    'default' => 
    array (
      'database' => 'monsite.com',
      'username' => 'monsite',
      'password' => 'loremipsum',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => '',
    ),
  ),
);
$conf['site_env'] = 'PROD';

// Si l'url se termine par .mapreprod.monentreprise.com"
// par exemple monsite.mapreprod.monentreprise.com
// alors on est en préproduction
if(preg_match('`\.mapreprod.monentreprise.com$`',$_SERVER['HTTP_HOST'])) {
  $conf['site_env'] = 'PREPROD';
  $databases['default']['default']['database'] = 'monsite.com';
  $databases['default']['default']['username'] = 'monsite_preprod';
  $databases['default']['default']['password'] = '123456789';
}

// Si l'url se termine par .dev"
// par exemple monsite.dev
// alors on est en local
if(preg_match('`\.dev$`',$_SERVER['HTTP_HOST'])) {
  $conf['site_env'] = 'DEV';
  $conf['theme_debug'] = true;
  $conf['hybridauth_debug'] = 1;
  $databases['default']['default']['database'] = 'monsite.com';
  $databases['default']['default']['username'] = 'root';
  $databases['default']['default']['password'] = 'mysql';
}

Par défaut, je définis les paramètres de production de mon site, ensuite, je me base sur le HTTP_HOST (l'adresse de notre site) pour déterminer l'environnement (ici préproduction ou local).

Et en fonction j'ajuste à la fois ma configuration mysql ainsi que différents paramètres de configuration pour mon site.

À noter, je définis aussi une variable qui contient l'environnement dans lequel je suis (ici : $conf['site_env']) ce qui peut être utile dans notre code pour savoir si l'on doit par exemple envoyer mail, sms, notification...

Quelques inconvénients à cette solution :

  • Les identifiants de notre prod et de nos autres environnement sont versionnés.
  • Si un nouveau développeur arrive sur le projet et qu'il a un fonctionnement différent, alors le fichier de config sera sans cesse écrasé.

La config différentielle dans un fichier non versionné

C'est la solution que j'utilise maintenant, on se base non plus sur l'url mais sur un fichier supplémentaire, qui défini la configuration spécifique et écrase potentiellement la configuration selon l'environnement.

Exemple :

Le fichier de configuration commun et versionné :

// La configuration de la base de donnée n'est pas définie car elle
// spécifique à chaque environnement
 $databases = array();

// On inclue le fichier settings.local.php s'il existe
if (file_exists(__DIR__ . '/settings.local.php')) {
  include __DIR__ . '/settings.local.php';
}

Le fichier de configuration settings.local.php en production (lui non versionné) :

<?php
  $conf['site_env'] = 'PROD';
  $databases['default']['default']['database'] = 'monsite.com';
  $databases['default']['default']['username'] = 'monsite';
  $databases['default']['default']['password'] = 'loremipsum';

Le fichier de configuration settings.local.php en local (lui non versionné non plus) :

<?php
  $conf['site_env'] = 'DEV';
  $conf['theme_debug'] = true;
  $conf['hybridauth_debug'] = 1;
  $databases['default']['default']['database'] = 'monsite.com';
  $databases['default']['default']['username'] = 'root';
  $databases['default']['default']['password'] = 'mysql';

Les fichiers settings.local.php ne sont pas versionnés grâce au fichier .gitignore et cette ligne (ici pour un drupal, mais à adapter en fonction de votre configuration) :

web/sites/*/settings.local.php

Avantages de cette solution :

  • Une fois configuré, le fichier de configuration de base ne bouge pas, il contient la configuration commune du site.
  • Pas de risque de s'écraser mutuellement la configuration entre développeurs.
  • Les fichiers settings.local.php ne sont pas versionné et donc aucun identifiant ne se retrouve sur github ou gitlab.

Je vois un inconvénient principal : quand un nouveau développeur arrive sur le projet, il faut qu'il comprenne cette organisation, c'est pourquoi généralement je crée un fichier settings.local.example.php qui lui est versionné et j'ajoute les lignes suivantes au readme du projet :

Pour ne pas risquer d'altérer la configuration de la base de données en production,
les identifiants de base de données doivent être renseignés dans un fichier `sites/default/settings.local.php`,
vous pouvez copier le fichier `sites/default/settings.local.example.php` en le renommant pour avoir un exemple
de fichier local.

Le fichier settings.php ne doit jamais être modifié directement, sauf cas très particulier.

Conclusion

La solution décrite juste au-dessus me convient bien, et semble bien marcher aussi pour les personnes avec qui je travaille. Néanmoins, ça n'est évidemment pas la solution universelle et vous avez peut-être mieux, si c'est le cas, n'hésitez-pas à venir en discuter dans les commentaires !

Par Simon Georges
Simon Georges

Faut-il mettre Drupal ou Symfony dans son cahier des charges ? Aucun ! Décrivez nous votre besoin !

Cela fait des années que nous développons des sites web sur la base d'un CMS ou d'un framework, qu'il s'agisse du monde PHP (Drupal, Symfony) ou Python (Plone, Wagtail, Django).
Trop souvent, le cadre technique nous est imposé dans le cahier des charges et à la fin du projet il s'avère que le choix n'était pas judicieux. Parlons-en !

Par GoZ
Fabien CLEMENT

Search API Solr sort by a field depending of value

Search API Solr sort by a field depending of value

With Drupal 7 and Search API + Search API Solr, i need to return content in top of results depending of another value.

Content indexed has 2 multiple fields list (or taxonomies like in example, whatever) with the same list: 'field_job' and 'field_best_job'. This is my example, but this can be converted by many other uses case.
First, my search is filtered by a facet on a field 'field_job' with value 'developer' and i want to put on top of results every contents which also have 'developer' value in the field 'field_best_job'.

GoZ
lun 20/02/2017 - 09:01

Par flocondetoile
Adhérent

Présentation du module Protected file sur Drupal 8

Drupal 8 dispose de plusieurs solutions et méthodes pour gérer les droits accès sur chacun des éléments inclus dans un contenu, et ceci de manière très granulaire. Permettre l'accès en visualisation ou modification de certains champs inclus dans un type de contenu peut se réaliser très simplement. La problématique est différente quand il s'agit de pouvoir gérer les droits de téléchargement d'un fichier tout en permettant sa visualisation. C'est à cette question que répond le module Protected file.

Par GoZ
Fabien CLEMENT

Index localized taxonomy term with Search API and Solr

Index localized taxonomy term with Search API and Solr

In Drupal 7 with Search API and Solr, i need to index taxonomy terms label which are localized, so terms can be searched in full text or thanks to facets in each localized translation.

I use modules search_api, search_api_solr, search_api_et, search_api_et_solr and i18n_taxonomy.

I see many issues and patch to make this fixing or altering facets, but it's not the way here. I have an item by language and want to index the text for this language.

GoZ
mar 14/02/2017 - 15:30

Par flocondetoile
Adhérent

Créer une action pour des mises à jours en masse personnalisées avec Drupal 8

Drupal 8 permet de réaliser nativement certaines actions en masse sur les contenus d'un site, comme par exemple publier ou dé-publier massivement des contenus, les positionner en haut des listes, etc. il peut être utile d'offrir à certains profils d'utilisateur certaines actions personnalisées liées aux spécificités de votre site, comme par exemple mettre en avant certains termes de taxonomie.

Découvrons comment mettre en place de telles actions.

Par Marc Delnatte
Akabia

Intégration de AMP (Accelerated Mobile Pages) avec Drupal 8

AMP en quelques mots

Améliorer les performances du web sur mobile est au cœur des préoccupations des développeurs, le projet AMP (Accelerated Mobile Pages) en est la preuve. Ce projet a fait l'objet d'une initiative open source et a été élaboré conjointement par Google et Lullabot en janvier 2016. Il est possible, dans la version beta du module Drupal 8, d'intégrer le support des pages AMP. Ce n'est pas encore le cas pour la version 7 de Drupal, mais le module est en train d'être finalisé, laissant présager une disponibilité rapide.

Par Marc Delnatte
Akabia

Intégration de AMP (Accelerated Mobile Pages) avec Drupal 8

L'AMP en quelques mots

Améliorer les performances du web sur mobile est au cœur des préoccupations des développeurs, le projet AMP (Accelerated Mobile Pages) en est la preuve. Ce projet a fait l'objet d'une initiative open source et a été élaboré conjointement par Google et Lullabot en janvier 2016. Il est possible, dans la version beta du module Drupal 8, d'intégrer le support des pages AMP. Ce n'est pas encore le cas pour la version 7 de Drupal, mais le module est en train d'être finalisé, laissant présager une disponibilité rapide.

Par flocondetoile
Adhérent

Mettre en place une visite guidée sur Drupal 8

Drupal 8 dispose d'un nouveau module intégré dans son coeur, le module Tour, qui nous permet de mettre en place une aide contextuelle permettant de guider les utilisateurs d'un site Drupal 8 pour leur premiers pas, que ce soit pour la découverte de leur profil utilisateur, des possibilités qui leurs sont offertes, sur la manière de créer un contenu ou encore sur la gestion générale des contenus du site.

Par flocondetoile
Adhérent

Mettre en place une visite guidée sur Drupal 8

Drupal 8 dispose d'un nouveau module intégré dans son coeur, le module Tour, qui nous permet de mettre en place une aide contextuelle permettant de guider les utilisateurs d'un site Drupal 8 pour leur premiers pas, que ce soit pour la découverte de leur profil utilisateur, des possibilités qui leurs sont offertes, sur la manière de créer un contenu ou encore sur la gestion générale des contenus du site.

Par Kgaut
Adhérent
Kevin Gautreau

Module Drupal 8 - Email Registration pour utiliser l'email comme identifiant

Un besoin classique sur un site avec gestion de membre est d'utiliser l'email comme identifiant. De base drupal utiliser la notion de "pseudo" et demande un email en plus.

Si l'on souhaite n'utiliser que l'email et supprimer complètement la notion de pseudo, on peut utiliser le module "Email Registration".

Ainsi il cache complètement le champs "pseudo" du formulaire de création de compte. Pour des raisons techniques le "username" est quand même généré en fonction de l'adresse email et de l'id de l'utilisateur, mais le module propose un hook spécifique si l'on souhaite mettre en place notre propre règle de génération de pseudo (hook_email_registration_name).

Le pseudo peut quand même être utilisé et défini par l'utilisateur en ajustant les permissions, mais il n'est plus nécessaire pour s'inscrire. De même façon, lors de l'authentification, il est possible d'utiliser à la fois son email ou son pseudo s'il est définis.

Ce module existe en stable pour drupal 7 est est en alpha pour drupal 8 mais fonctionne déjà sans soucis.

Pour installer le module, soit via composer avec :

composer require drupal/email_registration

Soit en le téléchargeant directement sur la page du module sur drupal.org : https://www.drupal.org/project/email_registration

Par Kgaut
Adhérent
Kevin Gautreau

Module Drupal 8 - Admin Toolbar

Une présentation rapide d'un petit module d'administration qui ne révolutionne rien mais qui permet de gagner de précieuses secondes : Admin toolbar.

Il surcharge la barre d'administration et lui ajoute des menus déroulants :

Ce module, couplé à coffee, permet de fluidifier la navigation dans le backoffice drupal, qui peut souvent s’avérer laborieuse avec les arborescences à 57 niveaux...

Et le sous module "admin_toolbar_tools" ajoute des liens vers des fonctions bien pratiques pour l’administrateur d'un site drupal : vidage de cache, updates, cron...

Pour l’installer via composer :

composer require drupal/admin_toolbar

Ou bien en le téléchargeant directement sur la page du module : https://www.drupal.org/project/admin_toolbar

Par Artusamak
Julien Dubois

Les nouveautés de Drupal 8.2.0

Les nouveautés de Drupal 8.2.0

DuaelFr
mar 10/01/2017 - 09:45

Il y a trois mois de cela, le 5 octobre, sortait, à l'heure, la version 8.2.0 de Drupal, apportant une fois encore son lot de correctifs et quelques nouveautés. Comme notre précédent article sur les évolutions de Drupal 8.1.0, cet article s'attardera sur les points essentiels de cette mise à jour "mineure" de notre CMS favori.

Content Moderation

Petit nouveau dans les modules expérimentaux, Content Moderation est issu de la Workflow initiative et pose les bases de la mise en place de workflows dans Drupal. Qu'il s'agisse d'un processus de validation de publication de contenus ou d'un processus de commande sur un site e-commerce, la possibilité d'associer des états à des entités ouvre les portes à de nombreuses fonctionnalités. Content Moderation est un portage éclairé du module Workbench Moderation et est la première pierre qui amènera Drupal à proposer des expériences de publication innovantes comme la possibilité de préparer et prévisualiser l'évolution d'un site complet et pas juste d'une page de contenu.

Contrairement à ce que permettait Workbench Moderation sous Drupal 7, il est désormais possible avec ce module de définir précisément ses propres états et transitions et même de définir plusieurs workflows différents car il est possible de choisir quels états seront accessibles en fonction du type de contenu.


Capture d'écran de l'interface de définition des états.

Capture d'écran de l'interface de définition des transitions entre les états.

Capture d'écran de l'interface de sélection des états pour le type de contenu "Article".

Date Range

Ce module fait revenir dans le cœur une fonctionnalité présente dans le module Date de Drupal 7. Elle consiste, pour un même champ de saisie de date, de permettre la saisie d'une date de début et d'une date de fin. Durant le développement de Drupal 8 et l'intégration de ce module dans le cœur, cette fonctionnalité avait été écartée sous prétexte qu'il suffisait de créer un second champ pour saisir la date de fin. Cependant, au fil du portage des modules exploitant ces données comme le module Calendar, les équipes se sont aperçues que ce choix était problématique et il a donc été décidé de réintégrer cette fonctionnalité dans le cœur pour cette version mineure.

Rien d'incroyable à montrer ici ; le module met à disposition un nouveau type de champ qui affichera deux widgets de saisie de date, respectant la configuration que vous auriez choisie comme pour un champ date classique.

Widget de saisie d'une date de début et de fin.

Outside-in

Il y a quelques mois, Dries, le créateur de Drupal, annoncait sur son blog vouloir moderniser l'expérience des éditeurs et site builders en améliorant la façon dont certains éléments sont administrés. Son billet se focalisait alors sur l'exemple des menus et des blocs qu'il aurait aimé rendre éditables directement via la partie publique du site, comme Drupal 8 le permet déjà pour les contenus via le module Quickedit. Entre le concept, appelé «outside-in», et la réalisation, le saut est immense mais, la communauté ayant bien réagi à cette idée, un groupe s'est organisé pour en planifier la réalisation. La tâche est loin d'être terminée mais cette version 8.2.0 a vu apparaître ses deux premières émanations : les modules Place Block et Settings Tray.

Place Block

Comme son nom l'indique, l'objectif de ce module est de simplifier le placement des blocs dans les régions. Une fois actif, il ajoute un bouton dans la barre d'administration qui permet de faire apparaître les régions existant dans le design et, pour chacune d'elles, d'y insérer un bloc. Une première fenêtre modale permet de choisir quel bloc insérer, et une seconde de le configurer plus finement. Actuellement, le module ne permet pas de déplacer les blocs ni de créer directement un nouveau bloc personnalisé dans les modales. Loin d'être satisfaisant, ce module a tout de même le mérite de poser les bases pour une fonctionnalité qui sera certainement très utile lorsqu'elle sera terminée.


Capture d'écran de l'interface de Drupal avec le mode "Place block" actif.

Capture d'écran de l'interface de Drupal une fois le bouton d'ajout de bloc pressé.

Capture d'écran de l'interface de Drupal une fois le choix d'un bloc effectué.

 

Settings Tray

Pour aller plus loin et permettre l'édition des paramètres des blocs présents sur la page, et même parfois de certains paramètres leur étant rattachés, c'est le module Settings Tray qu'il faut activer. Ce dernier donne une nouvelle dimension au bouton "Edit" de la barre d'administration en lui permettant, en plus de faire apparaître les icônes liées aux liens contextuels, de rendre tous les blocs de la page administrable en place. En cliquant sur un bloc, une barre latérale s'ouvre et permet d'éditer directement les options de base comme le titre et parfois plus. Par exemple, les blocs de menus exposeront les éléments présents dans le menu, ainsi que les options d'affichage telles que la profondeur maximale à afficher. Autre exemple, le bloc affichant le nom du site et le logo donne aussi la possibilité de modifier ces informations directement depuis la barre latérale alors qu'elles ne sont habituellement pas du tout exposées au niveau de la configuration des blocs.


Capture d'écran de l'interface de Drupal mettant en valeur les zones éditables grâce au module Settings Tray.

Capture d'écran de l'interface de Drupal avec la barre d'édition latérale ouverte dans le cas d'un menu.

Capture d'écran de l'interface de Drupal avec la barre d'édition latérale ouverte dans le cas du bloc "marque".

 

Autres améliorations diverses

Comme pour la version 8.1.0, cette nouvelle mouture contient des dizaines de corrections et d'améliorations diverses. On peut noter entres autres :

  • le passage du module expérimental Big Pipe d'alpha à bêta ;
  • l'amélioration de l'expérience d'édition par l'activation par défaut des révisions et la normalisation des modales de CKEditor ;
  • et la possibilité de supprimer facilement tous les contenus d'un type d'entité avant de désinstaller le module associé.Interface de désinstallation des modules faisant mention de la possibilité de supprimer tous les contenus liés.

Et pour les développeurs alors ?

Cette nouvelle version a été très orientée vers les web services (et ça continue, si l'on en croit l'actualité). Ainsi, outre le fait qu'il soit désormais plus simple d'utiliser des modes d'affichages pour les commentaires, l'accès REST aux entités de configuration a été amélioré et de nouveaux points d'accès ont été créés pour permettre à un utilisateur de s'authentifier, s'inscrire et se déconnecter. En bonus, la mise en cache des pages 404 et des fils d'Ariane a été améliorée pour éviter de saturer les serveurs sur des sites à fort trafic.

À l'heure où j'écris ces lignes, nous approchons de la bêta de Drupal 8.3.0 qui figera les fonctionnalités ajoutées dans la prochaine mouture et tout ce que l'on peut dire pour le moment c'est que c'est très prometteur ! Rendez-vous après le 5 avril pour faire le point !

 

Crédits : couverture créée par Sacha Chua, modifiée par Happyculture

Par flocondetoile
Adhérent

Utiliser la Cron API de Drupal 8

Nous avons vu dans un précédent billet comment nous pouvions générer automatiquement les styles d'images définis sur un site pour chaque image source téléversée. Nous allons poursuivre ce billet pour cette fois réaliser la même opération au moyen de la Cron API de Drupal 8, ce qui nous permet de désynchroniser ces opérations de masse, et qui donc peuvent être pénalisantes sur les performances ressenties, lors des actions réalisées par les utilisateurs.

Par flocondetoile
Adhérent

Utiliser la Cron API de Drupal 8

Nous avons vu dans un précédent billet comment nous pouvions générer automatiquement les styles d'images définis sur un site pour chaque image source téléversée. Nous allons poursuivre ce billet pour cette fois réaliser la même opération au moyen de la Cron API de Drupal 8, ce qui nous permet de désynchroniser ces opérations de masse, et qui donc peuvent être pénalisantes sur les performances ressenties, lors des actions réalisées par les utilisateurs.

Pages