Planète

Par juliendubreuil
julien dubreuil
Drupal since 2009

Drupal 8, la métamorphose du CMS

Drupal 8, la métamorphose du CMS

C’est indéniable le web bouge et c’est certainement l’une des industries ou les outils évoluent aussi vite et sont aussi éphémères, ce qui est à la mode aujourd’hui ne le sera potentiellement plus demain. Le monde des CMS/CMF n’est pas épargné et subit son lot d’évolutions. Le problème n’est plus de savoir si telle ou telle fonctionnalité existe mais bel est bien de savoir si l’outil est capable de communiquer et de s’intégrer avec d’autres applications. Cette mutation du web a permis l’apparition de nouveaux usages tels que les SPA (single Page Application) ou MBaaS (Mobile Backend as a Service) dont le but est d’afficher des données dans un front web désolidarisé du backend.

Dans les articles précédents sur l’évolution des sites web et sur pourquoi Drupal 8 a subit une telle évolution Frédéric G. Marand et moi avons évoqué les applications orientées composants ou services. Par le passé, Drupal a prouvé qu’il était un excellent système de stockage de données et qu’il était capable d’exposer ces informations. Drupal 8 ira plus loin en intégrant cette capacité à s’associer de façon transparente avec d’autres applications externes à son coeur.

Drupal 8, l’impact sur les applications futures

L’application monolithique est un grand classique pour les projets réalisés avec Drupal, pour autant ce n’est pas parce qu’on peut tout faire avec que c’est une forcément une bonne idée. Est-ce que si votre boulanger se mettait à vendre des voitures et des outils de bricolage dans sa boutique vous ne trouveriez pas ça étrange ?

Comme l’a dit Frédéric, l’heure de gloire de la publication simple est derrière nous, aujourd’hui les attentes du marketing portent sur la personnalisation de l’expérience utilisateur en fonction des données acquises. Cela implique que les utilisateurs soient connectés et aient une identité persistante multisupport. On parle alors de session multi-device qui permet de reprendre la navigation ou encore vos achats là où vous en étiez et ce quel que soit le support.

Or lorsque Drupal fabrique ses pages pour un utilisateur connecté (pages générées à la volée et non chargées depuis le cache) cela consomme beaucoup de ressources. Il est rare de voir des pages de front web fabriquées avec moins de 50 requêtes SQL et autant de chargements de cache. Drupal est un outil performant pour la gestion de contenus néanmoins il n’est pas réputé pour ses performances d’affichage (cas pour un Drupal de base sans optimisation).

Ainsi la partie affichage à l’utilisateur final est susceptible d’être déplacé hors de Drupal en tant qu’application distincte basée sur des Javascript tels que AngularJs ou React afin de servir à la fois du web et du mobile qui ne cesse de grandir. C’est ce que l’on appelle le « headless Drupal ». Laissons à Drupal ce qu’il sait très bien faire, stocker et manipuler les données et déportons le front vers des technologies plus souple et plus rapide à mettre en place. Pour vous donner un exemple d’utilisation, on pourrait créer un B.O. unifié pour vos utilisateurs qui centraliserait vos contenus et vos produits puis différents sites web ayant chacun une thématique particulière qui viendraient consommer un webservice de façon à proposer des contenus ou produits à l’utilisateur.

Ainsi il faudra repenser Drupal comme un service de backend utilisé par des applications tiers qui consommeront des webservices pour servir l’expérience utilisateur, tout en gardant des temps de réponses performant grâce à la paralellisation.

Cette séparation entre le front et le back de l’application va nous offrir l’opportunité de raccourcir les cycles de développement et augmenter son efficacité tout en utilisant les dernières technologies et methodologies. La mutation de Drupal en API de contenus va permettre de réduire les problématiques multi-devices que l’on rencontre couramment.

Drupal 8 est à un point important de son évolution, ça passe où ça casse. Cette métamorphose à venir est de loin la plus grosse refonte qui ait été faite. Et vous, comment voyez-vous le futur des applications Drupal ? Comment comptez-vous vous y prendre ?

Par juliendubreuil
julien dubreuil
Drupal since 2009

Drupal 8, la refonte majeure

Drupal 8, la refonte majeure

Comme les Frameworks, Drupal a évolué tout au long de ces dernières années afin de suivre la demande et les tendances. Ces ajouts de fonctionnalités ont considérablement fait augmenter sa taille et complexifié l’outil. Toutefois, Drupal ne devrait plus être considéré comme un CMS mais comme un CMF (Content Management Framework). En fait c’est le cas depuis la version 4.7 avec l’apparition de CCK, la form API et views.

Pourquoi une telle refonte ?

Quand on regarde un peu sous le capot on s’aperçoit qu’il y a énormément de composants et librairies externes utilisés dans cette nouvelle version. Côté PHP pur, c’en est fini de la programmation procédurale qui rebutait tant de développeurs, aujourd’hui Drupal est pleinement orienté objet avec l’utilisation des Namespaces, des Traits et j’en passe. L’interopérabilité des composants a grandement été facilitée grâce aux standards du FIG avec PSR-4 (PSR-0), PSR-3 ainsi que Composer.

Non, Drupal n’a pas été réécrit en Symfony2, mais des composants SF2 ont été utilisés dans Drupal 8. D’ailleurs il existe aussi des composants provenants de Zend Framework comme le rappelle Frédéric G. Marand lors de notre présentation.

D8 aurait pu faire le même choix d’architecture qui a été fait pour Wordpress 4. C’est à dire, ne rien casser et ne faire que des évolutions axées sur la partie fonctionnelle et éditoriale. Or c’est une refonte en profondeur qui a été faite, en rupture totale avec les précédentes éditions. Le but a été de créer un framework Full-stack en n’écrivant que le minimum de code tout en réutilisant les meilleurs composants disponibles. C’est pour cela que des librairies de code telles que Twig, Guzzle ou encore EasyRDF ont été intégrées. Le gain de temps à ne pas maintenir ces composants pourra être utilisé efficacement à la conception du coeur de Drupal.

Le ton est donné, la volonté de cette nouvelle version est de se professionnaliser et de ne plus être vue comme une simple platforme de blog mais bel et bien comme un framework pour réaliser des applications.

Drupal 8, la baffe

Il ne faut pas se leurrer, cette nouvelle version va tout chambouler. Bien plus complexe que les précédentes, il va falloir apprendre de nouvelles choses et comprendre les nouveaux paradigmes et composants avant de se sentir efficace.
Néanmoins sur le long terme, cela permettra de créer du code plus maintenable, plus facile à faire évoluer et beaucoup plus simple à déployer.

N’attendez pas pour regarder de près ce qui se cache dans cette nouvelle version, les changements sont tellement nombreux et majeurs que cela peut prendre du temps avant d’être pleinement opérationnel avec les différents composants et librairies intégrés à Drupal 8.

Faut-il avoir peur de Drupal 8 ?

Non, même si l’on parle beaucoup du loup sans le voir, il n’est pas à craindre, bien au contraire. Bien sûr cela voudra dire de passer par une nouvelle phase d’apprentissage mais cela est courant pour tout développeur et je ne connais pas de bon dev qui refuse d’apprendre quelque chose de nouveau. Cette nouvelle version, si elle est utilisée comme composant d’une application va nous permettre de réaliser des applications plus maintenables et plus fun à réaliser. Peut-être que cela deviendra le backend privilégié pour les applications SF2.
Personnellement j’ai vraiment hâte de travailler sur des projets orientés services ou composants avec Drupal 8 de façon à pouvoir utiliser d’autres technologies bien plus performantes là où Drupal n’est pas adapté.

Références et articles sur le sujet :

Par ftorregrosa
Florent Torregrosa

Adhésion en ligne : Commerce License

Adhésion en ligne : Commerce License

Soumis par ftorregrosa le dim, 21/12/2014 - 14:57.

Suite à l'article sur les adhésion en ligne pour le site Drupalfr.org, il m'a été suggéré de regarder le module Commerce License.

Ce module permet très bien de répondre à une problématique d'adhésion en ligne.

Voici son fonctionnement en quelques étapes :

Tags: 
Drupal
Étude de cas

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…

Tags: 
cloud
openshift
drupal

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

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 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
Drupal depuis plus de 10 ans, SEO depuis 3 ans

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

drupal
drupal 7

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 Simon Georges
Simon Georges
Drupal depuis plus de 10 ans, SEO depuis 3 ans

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

drupal
drupal 7

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 Mantalo Conseil
Agence web, Agence de Communication et Marketing en Dordogne (Aquitaine)

Un site marketing pour Foie gras Espinet

Un site dédié aux acheteurs professionnels

Ce site réalisé pour Foie Gras Espinet est un site marketing typiquement BtoB qui à l'image de son dirigeant, va à l'essentiel !

L'organisation et la fluidité du contenu ont nécessité une réflexion certaine... en même temps, on aime bien les dossiers un peu compliqués ! Pour le coup, nous étions comblés !

Plus sérieusement, l'enjeu était réellement de servir des scénarios simples d'accès aux visiteurs professionnels du site Foie Gras Espinet. Nous avons donc mis à contribution notre expérience et nos technologies pour parvenir à des tests utilisateurs conformes à ce que nous souhaitions : un accès rapide aux informations recherchées.

Drupal : un outil très structurant

L'une des particularités de Drupal est de faire interagir une infinité de termes de taxonomie dans autant de catégories souhaitées. La puissance structurelle est donc sans limite pour peu qu'on ait les idées claires. Le résultat est donc garanti si l'approche est professionnelle et que la maîtrise du concept est acquise.

Notre agence web investit depuis 2 ans dans l'appropriation de la technologie Drupal. Nous avons donc pu mettre à profit cet investissement pour réaliser aisément le site Espinet.

Mobile, valide, accessible, utile et agréable !

Ses caractéristiques étant communes à toutes nos réalisations, le site Espinet n'échappe bien évidemment pas à la règle !

Tags: 

Nous venons de vous convaincre qu'un résultat professionnel passe par une agence professionnelle ? Contactez-nous et travaillons ensemble sur la création ou refonte de votre site internet !

Par benftwc

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

blog
dev
dev
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
Drupal since 2009

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

blog
dev
drupal
drush

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.

Pages


M'abonner au flux RSS du planète