Si, comme moi, vous en avez marre de chercher le code d’un pays pour programmer vos modules, configurer vos modes de livraison ou vérifier votre configuration stockée en base de données, vous allez gagner des heures de travail !

Magentips vous offre un moteur de recherche des pays.

Quelles sont les données exploitées ?

• Code du pays au format ISO 3166-1 alpha-2, utilisé par Magento
• Nom du pays en français
• Nom du pays en anglais
• Zones géographiques du pays (continent, outre-mer, Zone Euro)

Que peut-on faire avec ?

• Chercher un mot parmi les données
• Filtrer la liste grâce à une sélection rapide d’une zone (bloc à gauche)
• Trier la liste sur n’importe quelle colonne

« C’est tout ? » Oui, c’est tout, mais, à l’usage, calculez le temps gagné !

Amusez-vous bien !

Je vois passer beaucoup de messages dans les forums et les blogs sur des blocages de certaines fonctionnalités de l’interface d’administration de Magento, en particulier depuis la sortie de Magento Community Edition 1.4.

Ils sont essentiellement dus au décalage entre les éléments nouveaux ou modifiés du backend et ceux traduits par l’extension qui gère la langue française.

Il faut laisser le temps à SeL de mettre à jour les traductions et publier une nouvelle version de l’extension (je sais que tu y travailles dur, SeL ).

D’ici là, il y a un moyen tout simple de contourner le problème : en pied de page du backend, vous avez le choix de la langue. Choisissez l’anglais américain et tout fonctionnera à merveille !

Bien entendu, cette manipulation ne modifie pas l’affichage des vues du frontend. Et quand vous mettrez à jour l’extension de la langue française, vous n’aurez rien d’autre à faire que de repasser le backend en français.

Ouf ! Rien de perdu.

Par contre, la comparaison 1.3.2.4 / 1.4.0.0 n’a pu être ajoutée, en raison d’un nombre trop important de modifications dans le code source entre les deux versions. Cela aurait rendu le comparateur illisible, donc inexploitable.

Parmi les petits trucs qu’il vaut mieux ne pas oublier sur un serveur à fort trafic, il y a la purge des sessions Magento. Si vous choisissez de stocker les sessions utilisateurs dans des fichiers (l’autre option étant de les stocker dans la base de données), ils viendront s’ajouter les uns après les autres dans le dossier var/session de Magento, sans jamais être supprimés.

Le problème, c’est qu’un serveur, même puissant et bien optimisé, accepte mal plusieurs millions de fichiers dans un seul dossier. Il devient même impossible de faire une simple commande ls pour lister son contenu : le serveur vous rendra la main plusieurs heures après… s’il y parvient !

Il faut donc purger les fichiers de sessions régulièrement. Les plus pressés feront un simple rm -rf du dossier session. C’est basique mais un peu brutal. Les utilisateurs et clients connectés ne vont pas forcément apprécier la perte de leur session et des commandes en cours…

J’ai eu le cas aujourd’hui sur un serveur dont la purge n’avait pas été mise en place. Avant de l’ajouter, j’ai vérifié que je pouvais gagner les longues minutes de purge de plus d’un millions de fichiers en supprimant directement le dossier session. Un rapide contrôle du trafic, des sessions et des commandes en cours : aïe, il y a trop de monde. Environ 200 sessions probables (selon temps de visite moyen) avec un taux de transformation de 6% et un panier moyen de 90€, ça me donne… 1080 € de pertes pour une simple commande rm -rf ! Un peu cher, je trouve. J’exécute donc une purge par date de fichiers et je laisse faire le serveur :

find . -atime +1 | xargs rm -f

90 minutes plus tard, tous les fichiers non utilisés depuis 48h sont supprimés (oui, +1 donne bien 2 jours, et non 1…). Je n’en ai plus « que » quelques milliers. Il reste à automatiser cette commande via crontab (en ajoutant les chemins absolus, bien entendu) et le tour est joué.

Sauf qu’il y a encore moyen d’améliorer tout ça, comme par exemple monter le dossier var de Magento en RAM. On gagne énormément en performances sur la gestions des sessions et du cache. Mais c’est une autre histoire…

Au passage , cette petite anecdote montre aussi qu’il ne faut jamais perdre de vue le métier de son client ou employeur. Certaines opérations menées sans réflexion et sans contrôle peuvent rapidement coûter très cher sur un site e-commerce. Il faut avoir en permanence le réflex d’évaluer la perte d’exploitation liée à une opération, même minime. En fin de mois, le cumul peut représenter bien plus que le salaire perçu…

Si l’activation du flat catalog est à peu près évidente (nous allons voir ça ci-après), il faut comprendre ce que fait Magento lorsqu’il crée les tables MySQL des produits à plat. Et on constate vite que, si on ne touche pas au paramétrage des attributs, on n’obtient pas du tout le résultat escompté !

Modèle EAV et flat catalog

Ce qui fait la souplesse de Magento, c’est la gestion de ses attributs par un modèle EAV. Chaque entité (produit, client, commande, etc.) est composée d’attributs (prix, couleur, pays, etc.) qui ont chacun une valeur (« 100 € », « vert », « France »). Comme un site évolue vite, on doit pouvoir ajouter ou retirer des attributs aux entités. Le modèle EAV est conçu pour cela, il permet de gérer facilement des attributs et leurs valeurs, sans modifier la structure de la base de données et sans écrire une seule ligne de code.

C’est un avantage énorme, mais il y a une contrainte de taille : quand Magento doit récupérer une entité (un produit par exemple), il doit parcourir un nombre important de tables dans la base de données pour assembler les valeurs des attributs et reconstituer l’information. Quand il faut afficher une page de catégorie avec 50 produits qui disposent chacun de 50 attributs, on arrive vite à la limite du tolérable. Comme le temps de réponse d’un site est le critère numéro 1 dans le succès d’un site e-commerce, il fallait trouver une réponse. Vous en réviez ? Magento le fait !

Pour accélérer les requêtes en lecture sur la base de données, Magento va construire de nouvelles tables dont chaque champ (ou colonne) représentera un attribut et chaque enregistrement (ou ligne) les valeurs des attributs d’une entité. C’est simple et rapide !

Bien entendu, si le catalogue est modifié, les tables doivent être reconstruites pour stocker les nouvelles informations. On ne met donc en œuvre des entités plates que si les valeurs ne changent pas tout le temps. Inutile d’y chercher les stocks ou les prix remisés par exemple.

Construire le flat catalog

Maintenant que les concepts de base sont posés, il faut savoir une chose : le flat catalog n’existe pas par défaut. Il faut donc le créer soit même depuis l’interface d’administration.

Pour créer un flat catalog :

• Menu Système > Gestion du cache
  
  Il faut d’abord construire les tables dans MySQL, grâce à ces boutons. On a le choix d’aplatir les catégories, les produits ou les deux.
• Menu Système > Configuration > Catalogue > Frontend
  
  Si nous ne construisons pas les tables via la gestion du cache, ces deux options sont indisponibles. Mais comme nous l’avons fait, nous avons maintenant le choix d’utiliser le flat catalog sur le frontend. Pourquoi faire compliqué alors qu’une seule étape pourrait suffire ? Simplement parce que Magento peut gérer plusieurs sites. On peut avoir un flat catalog sur un site et pas sur l’autre.
• Menu Système > Gestion du cache
  Oui, il faut y revenir pour ajouter nos entités (catégories et/ou produits) dans les tables à plat.

C’est tout. Mais est-ce suffisant ? Pas du tout ! Si on analyse les tables créées, on s’aperçoit vite que tous les attributs n’y sont pas, en particulier ceux spécifiques au site.

Si nous voulons afficher des valeurs d’attributs sans tuer les performances du serveur, il faut les ajouter à la structure des tables à plat. Pas de panique, inutile de faire ce sale boulot par des requêtes SQL hasardeuses. Magento a tout prévu… sauf de documenter ce détail essentiel !

Définir les attributs à aplatir

Quand nous demandons la construction du flat catalog, Magento utilise l’Indexer du module Catalog qui contient des contrôles sur la configuration des attributs (fichier Mage\Catalog\Model\Resource\Eav\Mysql4\Product\Flat\Indexer.php). Il contrôle notamment l’état du paramètre used_in_product_listing. S’il est égal à 1, l’attribut est intégré au flat catalog.

Reste à savoir d’où vient cet état. Une petite recherche (merci nWire !) et le voici, caché dans la configuration d’attribut (fichier Adminhtml\Block\Catalog\Product\Attribute\Edit\Tab\Main.php). On a la solution.

Pour ajouter un attribut dans le flat catalog :

• Menu Catalogue > Attributs > Gérer les attributs
  Sélectionner l’attribut à « aplatir ».
• Volet Propriétés du front-office
  
  C’est là que se cache l’option. Il faut choisir Oui et sauvegarder l’attribut.
• Menu Système > Gestion du cache
  On reconstruit le cache.

Le résultat est nettement meilleur. J’ai maintenant mon attribut dans mon flat catalog (ici manufacturer). Et un mystère de moins !

Le Bargento 3, c’est dans 2 jours ! La journée s’annonce exceptionnelle avec plus de 300 participants, l’inauguration de la Magento Academy, un concours de programmation de widgets, des présentations d’extensions… Entre conférences, ateliers et discussions de couloir, je ne vois pas comment tout va tenir en 10h de temps, mais c’est la magie de l’événement.

Cette fois-ci, je n’anime pas d’atelier, mais j’accompagnerai l’AFUP, partenaire de l’événement, et son président, Xavier Gorse, pour organiser la journée et accueillir les participants.

Malgré ces annonces étourdissantes, il manquait un truc… Un truc que je n’ai pas trouvé en 2 ans d’existence de Magento. Comme j’ai du mal à travailler sans, j’ai fini par m’y mettre et un premier jet sera disponible dans quelques jours : un Guide de référence Magento.

Et comme Magento évolue très vite, il ne s’agit pas d’un livre en papier mais d’une application web qui utilise des technologies sémantiques. Première brique, le référentiel des fonctionnalités de Magento Community Edition permet de trouver n’importe quelle information détaillée concernant une fonctionnalité de Magento (comme par exemple, où elle se situe dans l’interface d’administration). Comme il a pour but d’aider les utilisateurs au quotidien, les outils proposés sont adaptés à une recherche rapide :

• Recherche plein texte
• Filtres à facettes hiérarchiques (plus fort que Magento !)
• Tris dynamiques
• Groupement des résultats

Qu’obtient-on à la sortie ? Un peu ce qu’on veut en fait. Quelques exemples :

• Je souhaite caler toutes les adresses e-mail de Magento. Je tape « e-mail » dans le moteur de recherche et j’obtiens toutes les fonctionnalités qui ont un rapport avec les e-mails.
• Je souhaite paramétrer ce qui concerne le profil local de la plate-forme. Je sélectionne le groupe fonctionnel « Internationalisation / Localisation » et j’ai la liste complète des points à traiter (voir écran ci-dessous).
• Je souhaite connaître toutes les fonctionnalités attachées à un menu Magento. Je choisis une entrée de menu Magento dans le filtre hiérarchique correspondant et j’ai une liste exhaustive.
• J’ai besoin de détails sur une fonctionnalité. J’ouvre le panneau des détails et je sais tout.
• Je souhaite avoir la liste de tous les boutons de l’interface d’administration de Magento. Je choisis l’élément IHM « bouton » comme filtre. Bon là, je ne vois pas à quoi cela peut servir mais ça sait le faire !

En résumé, c’est un outil très souple et rapide qui saura s’adapter à vos recherches. Dans un premier temps, le contenu sera assez léger, mais le but est de l’alimenter au fur et à mesure des retours d’expérience. J’ai même prévu des liens avec les meilleures astuces liées à une fonctionnalité de Magento !

C’est Noël avant l’heure. Pour la plaisir (et le buzz !), une petite copie d’écran :

A lundi pour une petite démo ?

Au rythme des versions de Magento, il devient difficile de suivre les modifications apportées au code source. Pourtant, ce suivi est obligatoire pour garantir la compatibilité des extensions ou des thèmes avec une nouvelle version.

Pour les extensions, les développeurs ont l’habitude de suivre les feuilles de route et les changelogs. Une nouvelle version de Magento appelle donc une nouvelle version de l’extension. C’est habituel.

Il en est tout autrement pour les thèmes. Chaque thème est souvent spécifique à un site e-commerce. En cas de mise à jour de Magento, il est possible que le thème par défaut change. Il faut donc répercuter ces modifications sur le thème spécifique, sinon c’est bugs garantis ! Et comme Magento regorge de fonctions Javascript et Ajax, il est parfois pénible de tout passer en revue.

Alors pour vous faciliter la tâche, je mets à disposition un « Comparateur des versions stables de Magento Community Edition ». Cet outil répertorie toutes les modifications du code source de Magento entre deux versions stables. C’est visuel, exhaustif et rapidement accessible. Le genre de truc qu’on utilise plusieurs fois par jour…

N’hésitez pas à donner votre avis pour améliorer la chose. Et après, j’ai des trucs encore plus dingues dans les cartons !

Détail d’un fichier modifié entre deux versions Magento, avec mise en évidence des lignes.

Si on utilise le profil d’importation CSV standard de Magento, un fichier de comptes clients contient une ligne par compte avec l’ensemble des valeurs de ses attributs. Parmi ces champs, se trouve l’état d’abonnement à la newsletter. Lors d’une migration d’un site existant vers une plate-forme Magento, il est donc possible d’avoir des milliers de comptes dont la majorité sont abonnés à la newsletter.

Pendant l’importation de ces données, Magento utilise son modèle métier pour valider chaque ligne et réaliser l’action adéquate : création ou modification. Le problème pour les nouveaux comptes ou pour ceux dont l’abonnement à la newsletter change, c’est qu’ils seront traités comme le fait l’interface d’administration : un message sera envoyé au client pour l’avertir du changement d’état de l’abonnement.

Si votre fichier contient 50000 comptes, ce sont potentiellement 50000 e-mails qui partent lors de l’importation ! Retours garanties…

Donc si vous faites des importations de comptes clients, prenez vos précautions (en coupant le serveur SMTP par exemple), surtout si l’importation se répète plusieurs fois par jour lors des tests fonctionnels ou des tests de charge. Situation vécue…