Planète

Par pwetosaurus
Paul Playe

Déploiement de site Drupal sur la plateforme Openshift

La plateforme Openshift, présentée par ailleurs, permet de déployer en quelques clics une instance de Drupal, en version 7 ou en version 8.

Le but de cet article n'est pas de montrer comment choisir «Drupal» dans une liste d'applications, mais de montrer les différences dans la gestion d'un site Drupal dans le cloud de Red Hat.

Le Drupal étant packagé et prêt à l'emploi, on ne passe pas par les étapes classiques d'installation (Choix et configuration de la base de données, nom et mot de passe du compte d'administration…). Tout est généré à l'instanciation du Drupal et les informations d'authentification vous seront fournies à l'issue de la création du site. De même, vous n'avez pas à vous soucier de l'installation et de la configuration d'un SGBD (Ce sera par défaut du Mysql).

On peut se dire qu'il est à ce moment plus simple de n'installer qu'un environnement PHP le SGBD de notre choix et de faire une installation classique, mais la configuration de la base de données lors de l'installation de Drupal n'est pas simple, puisque les informations de connexion à la base de données se font par des variables d'environnement ($OPENSHIFT_MYSQL_DB_HOST, $OPENSHIFT_MYSQL_DB_PORT…etc…).

Un des avantages du cloud, c'est la scalabilité, mais dans le cas de Drupal l'application n'est pas scalable par défaut (comme pour les autres CMS disponibles en cartridges sur Openshift). Si vous voulez en savoir plus là dessus, le fichier README.md dv dépot utilisé par Openshift pour gérer sa version de Drupal présente quelques conseils pour rendre le site scalable.

Pour l'installation en elle même, il faut bien évidemment un compte Openshift actif (de plus les outils d'administration développés par Red Hat seront également nécessaires par la suite) et de se rendre dans l'interface de gestion des applications.

Les ressources disponibles et utilisées sont calculées en gears. Vous avez droit dans une utilisation gratuite, à trois small gears sachant que Drupal, PHP et mySql tiennent sur un seul gear. Si vous avez un gear de disponible, vous pouvez aller sur la liste des applications disponibles en appuyant sur le bouton dédié «Add Application…».

Dans la liste des applications disponibles, dans la section «Instant App» vous trouverez Drupal 7 (car il est maintenu par Openshift), et pour Drupal 8, il vous faudra chercher dans la section «PHP».

Il faut garder à l'esprit que le dépot utilisé par Openshift pour déployer le Drupal ne permet pas de bénéficier des alertes de mises à jour de sécurité et qu'il faut donc suivre soit même les sorties de correctifs pour les déployer par soi même.

En sélectionnant «Drupal 7» ou «Drupal 8», nous allons pouvoir configurer notre application, notamment son nom, puis les versions des dépendances de Drupal (versions de mySql et de PHP). Je recommande de ne pas toucher au choix du dépot d'origine duquel proviendra le code source de l'application.

 

Plus qu'à appuyer sur le «Create Application» et attendre (le déploiement peu prendre quelques minutes) la mise en place et la configuration du Drupal.

La page suivante nous offre les identifiants générés pour l'administration du site ainsi que les identifiants d'accès à la base de données.

Une des grosses différences entre le déploiement d'un Drupal de cette façon et une installation une installation d'un espace de travail sur Openshift, c'est la gestion via git qui est différente. Si nous n'avions déployé qu'un environnement de travail, nous aurions eu un dépôt à la racine de notre application sur lequel travailler. Dans le cas d'une installation de Drupal, nous avons notre application qui se trouve en dehors du dépôt.

Mais un autre outil de travail va nous permettre de mettre en place des modules contribués sans avoir à passer par l'interface d'administration, Drush.

Openshift nous authorise en effet une connexion SSH avec notre application, et tout passe par les outils développés par Red Hat.

 

[paul@localhost ~]$ rhc setup
OpenShift Client Tools (RHC) Setup Wizard

This wizard will help you upload your SSH keys, set your application namespace,
and check that other programs like Git are properly installed.

If you have your own OpenShift server, you can specify it now. Just hit enter to
use the server for OpenShift Online: openshift.redhat.com.
Enter the server hostname: |openshift.redhat.com|

You can add more servers later using 'rhc server'.

Using an existing token for drupal@paulplaye.fr to login to
openshift.redhat.com

Saving configuration to /home/paul/.openshift/express.conf ... done

Checking for git ... found git version 1.9.3

Checking common problems .. done

Checking for a domain ... osaurus

Checking for applications ... found 1

  drupal http://drupal-osaurus.rhcloud.com/

  You are using 1 of 3 total gears
  The following gear sizes are available to you: small

Your client tools are now configured.
[paul@localhost ~]$ rhc ssh drupal
Connecting to caf02300020a548a0d635973@drupal-osaurus.rhcloud.com ...

    *********************************************************************

    You are accessing a service that is for use only by authorized users.
    If you do not have authorization, discontinue use at once.
    Any use of the services is subject to the applicable terms of the
    agreement which can be found at:
    https://www.openshift.com/legal

    *********************************************************************

    Welcome to OpenShift shell

    This shell will assist you in managing OpenShift applications.

    !!! IMPORTANT !!! IMPORTANT !!! IMPORTANT !!!
    Shell access is quite powerful and it is possible for you to
    accidentally damage your application.  Proceed with care!
    If worse comes to worst, destroy your application with "rhc app delete"
    and recreate it
    !!! IMPORTANT !!! IMPORTANT !!! IMPORTANT !!!

    Type "help" for more info.


[enlightened-oise.rhcloud.com caf02300020a548a0d635973]\> drush cc all
'all' cache was cleared.                                             [success]
[enlightened-oise.rhcloud.com caf02300020a548a0d635973]\>

 

Nous avons donc un Drupal fonctionnel, mais qui n'est pas — pour le moment — très pratique pour développer thèmes et modules, et je ne désespère pas de pouvoir revenir là dessus plus en avant prochainement, certaines bidouilles pouvant nous permettre de tout de même y arriver…

Par Marc Delnatte
Akabia

Varnish et le balisage ESI

L’ESI (Edge Side Includes) est un balisage supporté par Varnish. Cela permet de cacher des blocs avec différents temps de vie (=TTL).

Par exemple, la page suivante dispose de différents blocs dont la plupart peuvent être mis en cache. Cependant, le bloc “Welcome” ou “Shopping cart” va lui être bien spécifique à chaque utilisateur et ne doit donc pas être mis en cache.

Par Marc Delnatte
Akabia

Installation de Varnish sur un site Drupal

Varnish est l’un des systèmes de cache les plus répandus à ce jour sur les sites à fort trafic. Il joue le rôle de “reverse proxy”. C’est à dire qu’il écoute les requêtes des utilisateurs et les transmet au serveur (dans la plupart des cas Apache/Nginx). Dans le cas où plusieurs utilisateurs demande la même requête, il va stocker cette requête si il en a les droits et la distribuer directement aux utilisateurs.

Par vincent59
Vincent Liefooghe

Créer un compte Admin par le code sur Drupal et Wordpress

Il est parfois intéressant de pouvoir se créer un compte avec les droits "Administrateur" sur un CMS Drupal ou Wordpress.

Par exemple si on récupère en infogérance un site internet développé par un client, qui n'a pas forcément envie de vous communiquer ses identifiants.

Si on a accès au serveur (ce qui est le cas quand on l'exploite), ceci est facilement faisable via quelques lignes de code.

Sous Drupal

Par défaut, si on a fait une installation avec le profil Standard, le rôle administrateur a le role-id 3. Par contre, un utilisateur qui fait partie du rôle administrateur n'a pas forcément autant de privilèges que le UserID 1, qui est vraiment "Super Admin" et qui peut outrepasser tous les droits.

Il suffit donc de créer un fichier php, puis de se positionner dans le root Drupal, et de lancer le script via :

php /chemin/vers/monscript.php

Avec monscript.php qui contient :

<?php
// Create Drupal Admin User
// run this file from Drupal root directory
// fichier a lancer à partir du répertoire racine de Drupal

define('DRUPAL_ROOT', getcwd());
$_SERVER['REMOTE_ADDR']="127.0.0.1";

include_once DRUPAL_ROOT . '/includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

$username = 'SuperAdmin';
$password = 'Passw0rd';
$email = 'me@mydomain.com';

$new_user = array(
  'name' => $username,
  'pass' => $password,
  'mail' => $email,
  'status' => 1,
  'init' => $email,
  'roles' => array(
    DRUPAL_AUTHENTICATED_RID => 'authenticated user',
    3 => 'administrator',
  ),
);

$newUser=user_load_by_name($username);
if($newUser) {
  echo "Sorry, user '",$username,"' already exists with ID ",$newUser->uid," !",PHP_EOL;
}
else
{
  $newUser=user_save('', $new_user);
  echo "New User ID = ",$newUser->uid,PHP_EOL;
}
?>

Ensuite il suffit de se connecter au site avec le login SuperAdmin et le mot de passe Passw0rd.

Sous Wordpress

Sous Wordpress, le rôle administrator  est prédéfini, et permet d'avoir les droits d'administration.

De la même manière qu'avec Drupal, il suffit de créer un fichier php, et de le lancer à partir du répertoire racine du site Wordpress.

Le contenu du fichier php est le suivant :

<?php
// Create a Wordpress Admin User
// run this file from Wordpress root directory
// fichier a lancer à partir du répertoire racine de Wordpress

$WPHOME=getcwd();
require_once( $WPHOME . '/wp-load.php' );

$username = 'SuperAdmin';
$password = 'Passw0rd';
$email = 'me@mydomain.com';

if (username_exists($username) == null && email_exists($email) == false) {
  $user_id = wp_create_user( $username, $password, $email );
  $user = get_user_by( 'id', $user_id );
  $user->remove_role( 'subscriber' );
  $user->add_role( 'administrator' );
}
else
{
  echo "$username exists ! Quit...",PHP_EOL;
}
?>

Conclusion

L'avantage de ces solutions c'est qu'on passe par les API / fonctions des CMS, et qu'il ne faut pas connaître les identifiants de la base de données. Sachant que si on a accès au système de fichiers, il est facile de récupérer les identifiants, soit dans sites/default/settings.php pour Drupal, soit dans wp-config.php pour Wordpress.

Ceci met aussi en lumière la nécessité de protéger et de mettre à jour son CMS, pour éviter qu'un internaute ne puisse lancer à distance ce genre de fichier !

 

Catégorie: 


Tag: 

Par vincent59
Vincent Liefooghe

Trucs & astuces Drupal

Quelques trucs et astuces qui peuvent rendre la vie un peu plus simple lorsqu'on travaille sur Drupal. 

Catégorie: 

Par Simon Georges
Simon Georges

10 modules Drupal que vous n'utilisez (peut-être) pas assez

Dans l'équipe Drupal de Makina Corpus, nous avons l'opportunité de travailler sur de nombreux projets de toutes les tailles. A ce titre, nous avons l'occasion d'expérimenter pas mal de modules dans des contextes différents, il était temps de vous en faire éventuellement découvrir quelques uns.

Par benftwc

Les mille-et-unes façons de reset un password sous Drupal

Comment efficacement et simplement reset un password sous Drupal

Quelques fois, souvent même, en testant ou développant ses sites, il peut arriver que l’on ai besoin de reset le password d’un utilisateur, pour ce faire, voici un concentré de solutions, toutes testées et fiables :)

# Avoir un lien de connection en Administrateur
drush uli

# Modifier le mot de passe de l'utilisateur choisit
drush upwd [user] --password="newpassword"

# Dans le repertoire courant de votre site
php scripts/password-hash.sh 'drupal'
# Utilisez le résultat (un password hashé)
drush sql-cli
update users set name='admin', pass='[votre hash ici]' where uid=1;
quit

# Obtenir un lien d'oublis de mot de passe
drush php-eval 'echo user_pass_reset_url(user_load(1));'

Sur Drupal 6, la seule façon dont je me souvienne :

drush sql-cli
# ou
mysql -u -p <drupal_db>
# ---
UPDATE users SET name='admin', pass=md5('drupal') WHERE uid=1;

The post Les mille-et-unes façons de reset un password sous Drupal appeared first on Benftwc.

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

L’avenir des applications webs, des développeurs et des DSI

L’avenir des applications webs, des développeurs et des DSI

Il y a un mois de cela, lors de l’appel aux sessions pour Drupagora j’ai proposé plusieurs sujets en relation avec le thème de l’année qui était le E-commerce, malheureusement aucune session n’a passé la sélection. Néanmoins le comité de pilotage est revenu vers moi en me demandant de parler de l’avenir de Drupal, de l’impact sur le développement web et du futur des applications.

Dans ce sujet on ne peut plus vaste, qui touche à la fois à Drupal, aux technologies actuelles et à l’architecture logicielle j’ai souhaité ne pas uniquement donner mon point de vue et c’est pourquoi j’ai demandé à Frédéric G. Marand de co-animer cette session avec moi afin d’être le plus proche de la réalité. Difficile de trouver mieux comme co-présentateur en terme d’expérience et de contribution que ce soit dans la communauté Drupal ou ailleurs.

Nous avons donc passé quelques heures à confronter nos idées et points de vues afin de présenter notre vision du futur. Voici la synthèse de notre session résumée en quelques billets de blog :

La présentation de notre session :

Par benftwc

Installer Drush avec Composer

Drush est un outil indispensable pour développer sous drupal, il permet de contrôler son instance de site via le terminal pour les taches quotidiennes sur un site : téléchargement, activation de modules, vidage de cache, mise à jours de modules ou du core… Une fois que l’on y a goûté, on ne peut plus s’en passer.

Il existe un tas de méthode pour installer drush et il est parfois difficile de s’y retrouver : via les dépôts, PEAR, installation manuelle… Mais maintenant le moyen de plus simple est d’utiliser composer.

Si vous n’avez pas composer d’installé :

curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer

Ensuite on peut installer Drush :

Pour la version 6 (compatible avec drupal 6 et 7) :

composer global require drush/drush:6.*

Pour la version 7-dev (compatible avec drupal 6, 7 et 8, mais en cours de développement) :

composer global require drush/drush:dev-master

La documentation complete de Drush ayant subi une mise à jour, voici son url : http://www.drushcommands.com/
Personnellement j’utilise la version 6 de drush en production et la version 7 en local, me permettant de l’utiliser sur Drupal 8.

Si vous souhaitez participer au projet, je vous invite à vous rendre sur leur repos github/a>.

Vous pouvez également consulter mon précédent article traitant de Drush ici :)

The post Installer Drush avec Composer appeared first on Benftwc.

Par cutesquirrel
Etienne

Drupal 7 : regénérer sa cron_key en cas de problème

Au secours ! ma cron_key a disparu !! Dernièrement, ayant des soucis de crons, j’ai suivi des tas de forums disant comment s’en sortir. Sauf que parmi les manip, j’ai viré toutes les variables commençant par cron_ … Donc dedans, il y avait la cron_key ! Des modules existent vous permettant de le faire, mais […]

Industrialisation et multi-sites avec Drupal

Porte usine

Créer une usine à sites ou pouvoir industrialiser la création d'un site Internet est une problématique souvent rencontrée pour développer sa présence Internet. Drupal permet d'industrialiser la production de sites internet et nous offre comme d'habitude plusieurs solutions pour y parvenir. Faisons un tour d'horizon des principaux moyens de mettre en place une présence en ligne massive avec Drupal, et quels sont les avantages et inconvénients de chacune des architectures possibles.

Thème 
Industrialisation
Drupal
multi-site
usine à site

Par Artusamak
Julien Dubois

Inclure du javascript en Drupal 8

Inclure du javascript en Drupal 8

Drupal 8 continue son avancée et les questions se font de plus en plus pressantes quant à son utilisation.

Des pistes de réponse existent et plus récemment Bluespark a mis en ligne le status du top 100 des modules qui permet de se rendre compte de la situation de la contribution.

Le rapport avec javascript vous me direz ? Et bien, il se trouve que pas mal de modules servant à intégrer des librairies tierces sont absents (Views slideshow, Lightbox, Superfish, jCarousel). Alors comment s'en servir quand même dans Drupal 8 ?

Pour l'exemple j'ai voulu utiliser Masonry sur une vue.

Comme précisé dans notre liste des changements en Drupal 8, la solution de remplacement à drupal_add_js est "d'attacher" son fichier à un render array.

Mais on peut aussi passer par la déclaration d'une librairie en créant un fichier <mondulename>.libraries.yml à la racine de son module.

jquery.masonry: # the machine name of library.
  version: 2.1 # the version of the library.
  js:
    /libraries/masonry/jquery.masonry.min.js: {} # path to js the source with additional parameters.
  dependencies:
    - core/jquery # required dependencies.

Ensuite il suffit "d'attacher" la librairie à un render array de la page (ici celui de la vue).

function happyculture_views_pre_render($view) {
  if ($view->storage->id == 'realisations') {
    $view->element['#attached']['library'][] = 'happyculture/jquery.masonry';
    $view->element['#attached']['library'][] = 'happyculture/happyculture.masonry';
  }
}

Cela à l'avantage de permettre la déclaration de dépendances et facilite une inclusion plus fine des librairies dans les pages nécessaires. De plus, cela rend plus simple la suppression de l'injection d'une librairie en cas de besoin.

Ensuite, on peut faire de même avec son code javascript en rajoutant son fichier custom dans le fichier <mondulename>.libraries.yml.

happyculture.masonry:
  version: 1.0
  js:
    happyculture.masonry.js: {}
  dependencies:
    - happyculture/jquery.masonry

Et le code en fonction de la librairie dans le fichier déclaré, ici happyculture.masonry.js qui sera placé à la racine de mon module.

(function ($) {
  "use strict";
  Drupal.behaviors.masonViews = {
    attach: function (context) {
      $('.view-realisations .view-content').masonry({
        itemSelector : '.views-row'
      });
    }
  };
})(jQuery);

Pour plus d'informations voir la doc officielle sur : https://www.drupal.org/node/2274843 et le change record associé https://www.drupal.org/node/2169605

Par Kgaut
Kevin Gautreau

À la découverte de Drupal 8 - #4 - Kint, ou le var_dump sous stéroides !

Si vous êtes développeur Drupal 7, vous connaissez certainement la librairie Krumo, qui permet d'afficher le contenu d'une variable de manière beaucoup plus pratique que le traditionnel var_dump, cette fonction n'étant pas native, mais fournie par le module Devel.

Rendu de Krumo

Rendu de Krumo

La librairie krumo n'étant plus maintenue, il a été proposé de la remplacer pour Drupal 8 par Kint.

Kint fonctionne de la même manière que krumo, mais propose de nouvelles fonctionnalitées bien utiles.

Il est toujours compris dans le module devel, au sein du sous-module "kint".

Une fois le module activé, on appelle la fonction en lui passant en paramètre la variable dont on veut afficher le contenu :

kint($form);

Voici ce que cela donne :

Rendu de kint

Et c'est pas fini! kint propose aussi la documentation des objets instanciés que l'on croise ainsi que leurs méthodes :

Affichage d'informations sur l'objet

Bref, un outil bien utile pour le développement !

Tags: 

Par Kgaut
Kevin Gautreau

À la découverte de Drupal 8 - #3 - Populer une entitée lors de l'installation

Le HOOK_install existe encore dans drupal 8, et il est donc possible d'en profiter pour populer automatiquement notre type d'entité lorsque l'on install le module qui la contient.

Toujours dans mon projet de site de pronostics, j'ai un type d'entité "Sport" qui contiendra l'ensemble des sports qui pourront caractériser une compétition.

Sachant que ces sports ne varient pas vraiment, je peux les créer dès l'installation.

Pour cela dans mon module mespronos_sports, je crée un fichier mespronos_sports.install avec à l'intérieur :

function mespronos_sports_install() {
  $entity = entity_create('sport', array(
    'created' => time(),
    'changed' => time(),
    'user_id' => 1,
    'name' => 'Football'
  ));
  $entity->save();

  $entity = entity_create('sport', array(
    'created' => time(),
    'changed' => time(),
    'user_id' => 1,
    'name' => 'Rugby'
  ));
  $entity->save();
}

On donne le nom du type d'entité que l'on veut créer et ensuite on passe un tableau avec l'ensemble des attributs de l'entité que l'on veut créer.

Et une fois le module installé :

Les sports sont créés !

Les sports sont créés !

Ainsi, plus besoin à chaque réinstallation de module, de re-créer les contenu, ce qui peut rapidement devenir long en cours de développement.

L'ensemble du code de mes modules est sur Github : https://github.com/kgaut/mespronos, le module ici en question est directement accessible là : https://github.com/kgaut/mespronos/tree/master/mespronos/custom/mesprono....

Résumé des épisodes précédents :

Tags: 

Par Kgaut
Kevin Gautreau

À la découverte de Drupal 8 - #2 : Création d'une entité avec fields

Suite de l'episode 1 : À la découverte de drupal 8 - #1 : Ma première entité

Aujourd'hui, nous continuons notre découverte de Drupal 8. Le but du jeu aujourd'hui est de créer une entité avec un champ personnalisé qui sera créé automatiquement lors de l'installation, via une grande nouveauté de Drupal 8, la gestion de la configuration.

Je continue mon site de pronostics pour l'occasion, c'est que l'euro 2016 arrive à grands pas ! Après l'entité League de l'épisode 1, nous allons cette fois gérer les équipes.Pourquoi je définie une équipe comme une entité et non pas un type de contenu ? Bonne question, pas vraiment de bonne réponse, c'est surtout car j'ai envie de jouer avec les entités !

Alors, comment est structurée une équipe ?

  • Id => La clé primaire
  • name => Le nom de l'équipe
  • logo => Le logo du club

Rien de bien compliqué pour les deux premiers attributs, ce seront des propriétés de base de mon entité. Le logo sera quand à lui un field, semblable à celui que l'on peut créer via l'interface d'administration, dans un type de contenu.

Création de l'entité

Comme dans l'épisode précédent, on va utiliser Console pour générer le module et l'entité.

On commence d'abord par vérifier s'il n'y a pas de mise à jours pour Console, on utilise pour ça composer. Via un terminal, à la racine de l'installation de Drupal :

composer update drupal/console
Mise à jour de console via composer

Mise à jour de console via composer

On génère maintenant le module mespronos_teams qui contiendra l'entité

bin/console generate:module
  • Nom du module : Mespronos Teams
  • Nom machine : mespronos_teams
  • Description : Gestion des équipes
  • Pas de contrôleur (on verra ça plus tard)

On génère maintenant l'entité

bin/console generate:entity:content
  • Nom de l'entité : Team
  • Nom machine : team

On active le module via l'administration.

Activation du module

Activation du module

Création du Champs

On peut maintenant ajouter des champs à notre entité via la field API (anciennement CCK dans Drupal 6, et dans le core depuis Drupal 7)

Via Gérer > Structure > Team Settings > Gérér les champs on créer un champ de type « image » dont le nom machine sera field_logo.

Field logo dans l'administration

Field logo dans l'administration

La configuration (CMI en action)

C'est super, on peut maintenant créer des équipes et leur affecter un logo. Par contre le soucis ici, c'est que si jamais je désactive mon module, je perds le champs que je viens de créer. Aussi, je ne peux pas en versionner la configuration, si jamais je viens la modifier plus tard. Mais heureusement pour nous l'initiative CMI « Configuration Management Initiative » a pensé à nous dans Drupal 8.

L'objectif de cette initiative est donc de pouvoir exporter toute la partie « configuration » de Drupal dans des fichiers YAML.

Via le fichier settings.php, on peut définir là où l'on veut stocker l'ensemble des fichiers YAML qui contiendront la configuration de drupal. Par défaut c'est dans un dossier dont le nom est généré aléatoirement dans le dossier /sites/monsites. Personnellement je préfère que ces éléments ne soient pas accessible sur internet, même si normalement le risque est minime. Pour cela à la fin du fichier settings.php je dé-commente et modifie les lignes suivantes :

$config_directories['active'] = '../config/active';
$config_directories['staging'] = '../config/staging';

On peut exporter d'un coup l'ensemble de la configuration de notre site via drush avec la commande config-export :

drush @monsite config-export

Fichiers de configuration

Fichiers de configuration

Revenons à nos moutons, nous allons donc chercher la configuration de notre field et l'intégré à notre module. Afin que lors de l'installation du module, le field soit automatiquement créé. La configuration du champs est répartie dans deux champs :

field.field.team.team.field_logo.yml
field.storage.team.field_logo.yml

Pour que ces fichiers soient pris en compte lors de l'installation il faut les placer dans un dossier config/install dans notre module :

Structure du module

Structure du module

On test en désinstallant notre module et le réinstallant, c'est ok, notre champs existe !

Field logo dans l'administration
Youpi Youhou !

C'est fini pour aujourd'hui, comme la dernière fois vous pouvez trouver l'ensemble de mes modules sur github à l'adresse suivante : https://github.com/kgaut/mespronos

N'hésitez-pas si vous avez des remarques ou des questions !

Tags: 

Créer un bloc Drupal 8 en quelques secondes

Photo d'un pic rocheux

Nous continuons d'explorer les possibilités offertes par le module Console et allons découvrir comment générer un bloc Drupal 8 en très peu de temps, puis à le personnaliser selon nos besoins.

Thème 
Drupal 8
Développement

Par Artusamak
Julien Dubois

Drupal et Scrum depuis les tranchées - Gérer le backlog du sprint

Drupal et Scrum depuis les tranchées - Gérer le backlog du sprint

Votre backlog de sprint est prêt, l'équipe s'est engagée à livrer le périmètre convenu et n'attend plus qu'une chose, poser les mains sur son clavier pour coder ! Lâchez les fauves, l'heure est venue de les laisser s'exprimer.

La prochaine grande étape du projet va résider dans le pilotage des deux ou trois semaines qui composent le sprint. L'équipe va passer beaucoup de temps avec le backlog du sprint, il doit respirer au rythme des commits et des échanges entre les équipiers. Une des valeurs importantes des méthodes agiles est l'auto-gestion, chaque personne doit être pro-active pour s'attribuer du travail et lever les obstacles qu'elle rencontre lors de la réalisation des stories techniques ou fonctionnelles. Il est capital qu'à chaque fois qu'une story est démarrée, change d'état pour être envoyée en testing ou se termine, le backlog du sprint soit mis à jour en conséquence. Le backlog permet d'un simple coup d'oeil de savoir qui travaille sur quoi et de suivre l'état d'avancement du sprint sans avoir à solliciter une personne.

Pour les gens pressés : TL;DR.

Identifier les goulots d'étranglement

Parfois l'équipe a beau se montrer concernée, elle a le sentiment de faire du sur place. Il y a 6 ou 7 stories qui n'arrivent pas à démarrer. Comment comprendre ce qui bloque ? Les stories pourront-elles vraiment être traitées dans ce sprint ? Pour répondre à ces questions, gardez le numéro de votre marabout préféré dans votre poche, on va plutôt chercher à répondre à cela de façon analytique.
Deux outils (au moins) sont à notre disposition pour mesurer notre activité, le burndown chart et le cumulative flow chart.

Le premier est une courbe illustrée ci-dessous sur laquelle on rapporte le nombre de jours écoulés en abscisse et le nombre de points de complexité en ordonnée. Chaque jour nous allons rapporter le nombre de points de complexité restant à faire. On démarre au premier jour à 120 si c'est la valeur de l'engagement de l'équipe et on soustrait tous les jours le nombre de points de complexité que l'équipe a réussi à fermer. Le but du jeu étant d'arriver à 0 avant le dernier jour du sprint. Cette courbe s'appelle un burdown si vous partez de 120 pour aller à 0, elle s'appelle un burnup si vous partez de 0 pour aller à 120 avant le dernier jour. On représente souvent le rythme idéal sur la courbe pour comparer la vitesse de progression réelle.

Crédits images : I8abug CC BY-SA 3.0 / Clarios Technologie

Oui mais voilà, le burndown ne montre pas tout, comment se rendre compte si de nombreuses stories sont coincées en attente de tests ou en attente de réponse ? Dans ce cas là nous devons nous appuyer sur un autre outil, le cumulative flow chart. Qu'est ce que c'est ? Ne faites pas cette tête, c'est très simple. Il s'agit un graphique qui représente le cumul des points de complexité pour toutes les stories du sprint. De cette façon vous savez si vous avez un grand écart entre le nombre de stories en cours de développement, de test ou en attente de réponse. Cela permet de repérer les goulots d'étranglement. Une image valant mille mots, en voici un exemple.


Crédit image : Clarios Technologie

Dans l'exemple présenté, on ne voit à aucun moment une masse prendre le dessus sur l'autre, s'il y avait une prédominance du testing on demanderait à l'équipe de donner un coup de main en testing afin de fermer des stories avant d'en commencer d'autres. Le but étant je vous le rappelle de livrer le plus de valeur ajoutée possible. Avoir des stories commencées mais non terminées ne nous avancerait pas.

Quel flux de travail pour mes stories ?

Un point important pour que l'équipe avance sans à-coups est qu'elle connaisse le flux de travail que les stories doivent suivent. Il n'y a pas UN flux de travail à suivre, c'est à vous de l'adapter au projet et à l'équipe mais je vais vous présenter les états qui composent celui que l'on suit chez Happyculture.

  • A faire : Etat par défaut d'une story.
  • En cours : Utilisé dès qu'un développeur choisi de travailler sur une story.
  • Résolu : Sert à indiquer que les développements sont terminés mais pas encore disponibles pour être testés, la story reste assignée au développeur tant qu'elle n'est pas prête à être testée. Cela nous sert principalement à cause de la revue de code, une fonctionnalité n'est pas disponible sur les environnements de test tant qu'elle n'a pas été intégrée au dépôt principal.
  • Besoin d'informations : Un développeur a une question sur un point précis ou le product owner pendant ses tests veut vérifier quelque chose. La personne qui se voit assignée la tache est celle qui doit répondre à la question.
  • A tester : La story est prête à être testée, le lien vers la page précise et les instructions pour clore la tache sont précisées en même temps que la story est assignée au product owner.
  • Fermé : Tout le monde a bien fait son travail, la story fonctionne comme prévu.

Comment gérer les demandes à côté ?

Il peut arriver au cours des tests de stories que le / la product owner tombe sur un bug d'intégration ou sur une phrase à reformuler. Pour gérer ces demandes particulières nous ne ré-ouvrons pas des stories qui auraient pu être candidates à recevoir ces demandes, on s'appuie plutôt sur une story particulière qui se promène de sprint en sprint et qui est un agrégat de toutes les petits demandes du genre. L'équipe y consacre quelques points de complexité à chaque sprint selon les priorités. Si certaines taches sont plus grosses, on ouvre une story dédiée qui sera intégrée au sprint suivant si nécessaire.

Au final, le backlog du sprint est au cœur de l'activité, il permet de s'assurer que tout le monde avance sur ses stories et permet de constater qu'aucun goulot d'étranglement ne se forme, si tel est le cas il est de la responsabilité de l'équipe de trouver les solutions, le scrum quotidien est là pour ça.

TL;DR

  • Le backlog du sprint doit à tout moment résumer l'état réel du projet
  • C'est l'équipe qui met à jour le backlog
  • Le burndown ou burnup combiné au cumulative flow chart permet de contrôler finement le rythme d'avancée de l'équipe
  • Si des goulots d'étranglement apparaissent, l'équipe réagit
  • L'équipe connaît et suit un flux de travail clair
  • Si des demandes non prévues se présentent on les regroupe au sein d'une story spéciale
Par Kgaut
Kevin Gautreau

Installer drush sous linux via composer

Drush est un outil indispensable pour développer sous drupal, il permet de contrôler son instance de site via le terminal pour les taches quotidiennes sur un site : téléchargement, activation de modules, vidage de cache, mise à jours de modules ou du core... Une fois que l'on y a goûté, on ne peut plus s'en passer.

Il existe un tas de méthode pour installer drush et il est parfois difficile de s'y retrouver : via les dépôts, PEAR, installation manuelle... Mais maintenant le moyen de plus simple est d'utiliser composer.

Si vous n'avez pas composer d'installé :

curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer

Ensuite on peut installer Drush :

Pour la version 6 (compatible avec drupal 6 et 7) :

composer global require drush/drush:6.*

Pour la version 7-dev (compatible avec drupal 6, 7 et 8, mais en cours de développement) :

composer global require drush/drush:dev-master

Personnellement j'utilise la version 7 de drush (vu que je commence à faire mumuse avec la version 8 de drupal)

Quelques liens sur drush que je vous conseille :

Tags: 

Pages