Nous vous invitons à consulter le numéro d’août de PHP Solutions avec le dossier sur Drupal et Magento : http://phpsolmag.org/drupal-et-magento-creez-votre-plateforme-e-commerce/.

Au sommaire du numéro courant :

• POO en PHP et nouveautés apportées par PHP 5.4 .
• Drupal et Magento deux géants pour une plateforme e-commerce / m-commerce complète.
• Facebook : Créer vos applications au bout des doigts.
• Générer des classeurs pour tableur avec PHPExcel.
• Les solutions pour booster WordPress.
• PC ASUS G73S.

Bonne lecture !

http://phpsolmag.org/drupal-et-magento-creez-votre-plateforme-e-commerce/

Cette demande est récurrente et tout à fait légitime. La réalisation d’un gros projet Drupal n’est pas simple et l’équipe en charge du site, après notre intervention, aura à comprendre le fonctionnement de l’ensemble pour faire évoluer le site. Une simple formation Drupal de quelques jours ne suffira pas.

Nous avons pratiqué avec succés ce mode de fonctionnement à plusieurs reprises et voici ce qui marche et ce qui pose problème lors d’un transfet de compétences Drupal.

Ce qu’il faut absolument faire :

• Commencer par une formation Drupal AVANT le début du projet, pour tous les membres du projet coté client.
• Intégrer les équipes dès la phase de spécifications fonctionnelles
• Mettre en place un espace de travail unique (Redmine / GIT ou SVN / Serveur de développement)
• Repérer le meilleur élément et le designer RAPIDEMENT comme team leader coté client (attention, ce point est à prévoir avec l’équipe dirigeante du client en amont du projet)
• Toujours donner de vraie tâches (pas de politique “bac à sable”)
• Avoir le même niveau d’exigence qualité pour l’équipe du client que pour la vôtre
• Faire des revues de code régulières et toujours suivies de sprint de refactoring
• Cultiver l’esprit d’équipe. Organiser une petite soirée, un verre après le boulot, un déjeuner ou dinner, il faut que le courant passe !

Ce qu’il ne faut surtout pas faire :

• Laisser les équipes se débrouiller seules pendant trop longtemps, si non refactoring de leur code sera trop long
• Infantiliser les développeurs : ils ne sont certes pas des experts Drupal, mais ils connaissent le “métier” de leur site bien mieux que vous !
• Jamais donner des taches structurantes au début du projet. Souvent des taches ’simples’ sont tentantes (créer une taxonomie ou des types de contenus, …) mais gare à tout ce qui touche à la structure : type de contenus, taxonomies, panels… Une erreur à ce niveau est vite arrivée et peut couter cher sur un projet Drupal. Préférez, dans l’ordre d’apprentissage : la migration du contenu, theming des noeuds, puis celles des views, construction des views / panels secondaires, enfin fonctionnalités entières…
• Mal/peu communiquer. La complexité de votre nouvelle équipe Drupal, fait qu’il faut sur-communiquer.
• Mettre un chef de projet junior ou non technique. Le chef de projets Drupal doit être un expert, maitrisant parfaitement l’outil mais étant suffisamment pédagogue pour transmettre ses connaissances aux développeurs.

Dans sa présentation d’ouverture de la DrupalCon à Chicago, Dries a présenté sa vision de Drupal 8. Les points clefs sont :

• Connecté & interopérable
• Mobile
• Avec un (vrai) système de gestion des configurations
• Doté du “content staging”

De mon point de vu l’essentiel sera la mise en place d’un vrai système de configuration et de gestion du content staging. Par ailleurs, les deux fonctionnalités sont liées.

Aujourd’hui, la configuration de Drupal est une notion floue. On a settings.php, on a la configuration des modules dans le back-office qui est stockée soit dans des tables crées par les modules soit dans les variables Drupal. Et puis il y a ces modules dont on ne sait s’il s’agit de configuration ou de contenu : Views, Panels, …

Greg Dunlap a proposé une vision et la conversation qui a suivi sa présentation a été très intéressante. Voici donc un appercu de ce que devrait être la configuration dans Drupal 8 :

• Intégration de certaines fonctionnalités “Features” dans le core
• Gestion globalisée des UUIDs (point crucial pour le content staging également)
• Une API dédiée (Settings API ?)
• Stockage de la configuration dans un fichier structuré (JSON vs XML). JSON semble mieux placé : plus performant, moins verbeux, ne nécessitant pas de DTD pour être lu, il s’adapte mieux à la structure modulaire de Drupal.
• Un fichier de log avec tous les changements effectués - on peut alors imaginer de rejouer le log pour reproduire une config OU jouer le log à l’envers pour défaire une config (vrai gros plus par rapport à aujourd’hui)
• Gestion des dépendances entre les items de la configuration (à la manière des dépendances des modules)

Le principal point d’attention devrait, à mon sens, être la capacité à debugger la config de manière efficace. Il ne faut pas tomber dans le principal défaut de Magento (ou presque tout se fait par des fichiers de conf XML énormes) où l’on cherche pendant des heures cette majuscule à la place de la minuscule qu’on aurait oublié quelque part…

En tous cas, si Drupal est doté d’un FICHIER de configuration, ce sera un pas gigantesque vers le monde de l’entreprise. En effet, avec un système de déploiement & staging nickel, Drupal pourra prendre la place de bon nombre d’outils qui occupent aujourd’hui les SI des grandes entreprises dans le monde.

L’autre point crucial dans Drupal 8 est le content staging.

Aujourd’hui si vous voulez exporter vos contenus de production sur votre plateforme de développement ou si vous souhaitez créer vos contenus sur une plateforme de pré-production et les déployer en production d’un coup, après validation, c’est pénible et demande des rustines un peu partout.

Le graal du content staging (et donc du contenu exportable, duplicable, replicable, ….) est la mise en place des UUID. Les UUIDs (Universal Unique IDentifier) sont connus du monde informatique depuis très longtemps et sont utilisés un peu partout (Base de registre de votre Windows est basée sur les GUID, une version légèrement différente des UUID). L’idée majeure d’un UUID est qu’il est (presque) unique (probabilité de colision après génération de 68 milliards de UUID est seulement de 4 × 10⁻¹⁶ )

Le principal problème, avec le Drupal 5, 6 ou 7 est que tout est basé sur le NID. Or les NID sont générés par l’autoincrement de MySQL (ou les séquences Oracle :). Ils sont uniques à une base donnée. Si vous exportez les contenus vers un nouvel environnement, de nouveaux NID seront générés et les liens éventuels (Taxonomie, Node Reference, etc…) seront perdus.

En revanche si chaque contenu était identifié par un UUID et que les liens sont posées sur les UUID plutot que sur les NIDs les contenus sont exportables.

Il est évident que toucher aux NID est très touchy dans Drupal, je pense que les UUID auront une existence parallele aux NIDs utilisés lors des exports uniquement.

Et c’est la qu’on retrouve Features, avec un projet interessant : http://drupal.org/project/uuid_features qui pourrait montrer ce que serait le content staging en D8.

Bonne nouvelle supplémentaire, le magazine en question est en téléchargement gratuit !

http://download.phpsolmag.org/fr/Magento_et_Drupal_PHP_07_2010_8.pdf

Lisez en page 21 !.

http://www.editions-cigale.com/

Les Editions La Cigale sont spécialisés dans la vente de supports d’apprentissage de la lecture pour les professeurs d’école. Le site propose, outre la partie boutique, des ressources audio, vidéo et PDF (en prévisualisation Flash) ainsi qu’un blog. Le choix de Drupal s’est donc naturellement imposé pour la réalisation du site. Nous avions envisagé la mise en place de Ubertcart, pour la partie boutique en ligne, sauf qu’après une démonstration des possiblités de l’outil, et ce meme après l’installation de plusieurs modules complémentaires, le client n’était pas du tout satisfait.

En revanche, montrer le back-office de Magento a provoqué le déclic, le fonctionnalités et l’erognomie de Magento correspondant exactement aux besoins du client.

Le lancement de ce site, nous permet de démontrer, une fois de plus, l’utilité de la solution Drupal + Magento. Le webmaster du site travaille dans le back-office Drupal, met en ligne les contenus vidéo, audio et PDF. Il gére également le blog et les mises en avant éditoriales. Les équipes commerciales, quant à elles, travaillent dans le back-office Magento et s’occupent des ventes et de la logistique.

En effet, outre la gestion simple des ventes, Magento propose un outil complet s’approchant d’un mini-ERP.

Magento seul pose souvent des petits problèmes de performances, le site des éditions la cigale tourne sur une seule machine avec 2Go de RAM et un seul CPU. La puissance du moteur de cache de Drupal permet d’obtenir des performances correctes sur une machine très petite.

Enfin, je trouve ce site beau. Il est original et l’intégration montre qu’il n’y a pas de limitations graphiques pour la réalisation d’un site Drupal.

Le principe est simple : un Apache SOLR hébergé sur le cloud Amazon EC2.

Nous avons travaillé depuis plusieurs mois pour mettre en place une architecture d’haute disponibilité avec une optimisation des ressources EC2, pour en optimiser les coûts. Coté Drupal, rien de particulier à faire, car on se base sur le module Apache SOLR de base.

Les fonctionnalités d’Adyax Search

• Moteur basé sur Apache Lucene SOLR
• Lemmatisation des expressions françaises
• Recherche par facettes
• Recherche par catégories
• Liberté totale sur le paramétrage de la pertinence, catégories, types de contenus
• Indexation de fichiers PDF, XLS, DOC, RTF…
• Rapidité d’execution des requêtes
• Rapidité d’indexation

Adyax Cloud Search vs Apache SOLR installé chez vous

Haute disponibilité et gestion des piques de trafic :

• Le service de recherche est hébergé sur la plateforme Amazon EC2, ce qui offre un taux de disponibilité de 99,95%
• Par ailleurs grâce à notre système de load-balancing EC2 la plateforme est capable de prendre en charge n’importe quel pic de trafic

Economies importantes :

• Pas de frais d’infogérance
• Une intégration simplissime : vous activez un module Drupal et le moteur de recherche fonctionne !
• Vous ne payez que ce que vous consommez : pour tenir la charge durant les heures chargées ou lors d’un pic de trafic, vous ne payez que les ressources consommées, sans supporter le cout d’un matériel inutilisé le reste du temps
• Une structure de très prix simple
• Grace à un système de cache embarqué, les requêtes déjà effectuées ne sont pas payées !
• Totale transparence : une facture détaillée avec tous vos consommations mensuelles.

http://es.wfp.org/

Pour l’instant seule la version espagnole a été migrée (les autres langues allant vers les anciennes versions, en attendant la migration de tous les sites).

La principale difficulté aura été de gérer les fontes non standard pour les titres. Il a été particulièrement difficile de trouver une fonte qui corresponde graphiquement et qui contienne tous les jeux de caractères (coréen, russe, arabe, français, chinois….)

L’autre tâche complexe est liée au fait que les différentes sous-organisations ne rédigent pas le même volume de contenu, il a fallu donc adapter les pages d’accueil des différentes langues en fonction de la quantité de contenu disponible.

Longue vie à cette belle association qui oeuvre chaque jour contre la faim dans le monde.

WFP un site avec une dizaine de langues sous Drupal

Tendance confirmée, Wordpress, Drupal & Joomla! loin devant

On remarque aussi que Joomla! est devant Drupal sur pas mal de critères. Je ne suis pas vraiment étonné de ce positionnement, Drupal reste surtout utilisé par des professionnel pour des sites importants. On voit d’ailleurs, que le rapport place ezPublish & Typo3 loin derrière, alors que ces CMS sont souvent des concurrents sérieux de Drupal sur les appels d’offres d’envergure.

En revanche, petite surprise, Drupal est largement en tête pour les mesures de marque.

CMS sur le micro-blogging, domination écrasante des 3 leaders

Par ailleurs, et cela confirme mon sentiment vis-à-vis des divers CMS,  Drupal est devant Joomla!, Typo, ezPublish en termes de qualité. En effet, les personnes ont généralement tendance à préférer Drupal, une fois le logiciel installé et utilisé.

Rouge = negatif, Vert = positif

Petite difficulté - la gestion du menu assez imposant et très sympa avec des images et pas mal de contenu. Ici on massivement utilisé Views, le menu classique de Drupal étant laissé pour la gestion des liens dans le footer.

La gestion de l’agenda et des inscriptions utilise le module Sign-up. L’export PDF de tous les articles du site est assuré par le module Print avec l’utilisation d’un template spécial, adapté à l’impression.

Après plusieurs mois d’efforts, les deux cotés du tunnel se sont enfin rejoint : un module Magento pour Drupal et une extension Drupal pour Magento.

En installant les deux, vous aurez la possibilité d’utiliser Magento comme back office de gestion de votre boutique et Drupal pour le front office.

Les avantages de cette solution sont nombreux :

• Totale souplesse sur le contenu : vous n’êtes plus limités par les lacunes ‘CMS’ de Magento. Vous bénéficiez de la toute puissance de Drupal pour gérer votre contenu, promouvoir vos produits et construire des solution eCommerce aussi complexes que vous le souhaitez
• Puissance de Magento : s’il existe des modules eCommerce pour Drupal (Ubercart, eCommerce), il n’en reste pas moins des extension du CMS. Les interfaces et fonctionnalités ne peuvent pas concurrencer Magento, surtout pour des sites d’envergure.
• Sécurité : les deux plateformes (front & back) peuvent résider sur deux serveurs distincts, le back n’est jamais directement atteint par les internautes. Enfin, une faille sur le front ne remet pas en danger l’intégralité de votre solution, votre catalogue, prix, règles de gestion et, surtout, vos clients sont protégés sur le back, éventuellement derrière un parfeu.
• Optimisation : Magento a souvent péché par la lenteur, ce qui n’est pas le cas de Drupal. Séparer les briques front & back permet d’optimiser l’utilisation des ressources, mais surtout offre une opportunité simple de mise en place d’architectures hautement distribuées (rien ne vous empêche d’avoir 3 front office Drupal avec 1 back office Magento.)

Modules Drupal : http://www.drupal.org/project/magento
Extension Magento : http://www.magentocommerce.com/extension/1020/drupal