Magento 2 : ce qui va changer !

Magento 2 : ce qui va changer !

Magento 2, théoriquement prévue pour fin 2012 / début 2013, sera la deuxième version majeure de cette solution e-Commerce open-source lancée début 2008, dont la popularité n’a cessée de croître depuis. A ce jour, voici quelques chiffres clés sur Magento :

  • Plus de 4 000 000 de téléchargements
  • 100 000 marchands utilisent Magento à travers le monde
  • Environ 5 500 extensions sur Magento Connect

Pour autant ce n’est pas tant l’aspect commercial et populaire qui va nous intéresser dans cet article mais plutôt le contenu technique de Magento. Vous n’êtes pas sans savoir que Magento est avant tout :

  1. Un socle technique, utilisant le Zend Framework comme une librairie, et en conservant certains aspects (convention de nommage, structure de dossiers, ré-implémentation, …). La grande majorité de ce couplage est réalisée dans les 2 modules que je nommerais “cœur” de Magento, à savoir Mage_Core et Mage_Page.
  2. Une solution e-Commerce, dont les modules coeurs sont Mage_Catalog (et ses dérivés CatalogSearch, …), Mage_Customer, Mage_Checkout et Mage_Sales

Avec plusieurs dizaines de développeurs et 4 ans d’âge, Magento se traîne des casseroles… C’est pourquoi Magento Inc (l’éditeur) a pris parti de développer Magento 2, deuxième version majeure de son produit, qui sera avant tout un refactoring technique de l’actuelle version.

Ce que cet article va montrer :

1. Les nouveautés introduites avec Magento 2

Une des faiblesses de Magento vient du fait que vous trouverez difficilement une documentation officielle technique de référence pour ce produit. Bien sûr, de bons sites, tutoriels et formations Magento existent mais seul un œil averti pourra différencier le bon du moins bon sur ce qui est proposé comme étant une réponse technique. En réponse, Magento Inc met à disposition un Wiki. Serait-ce une première étape vers une documentation de référence, ne serait-ce que pour Magento 2 ?

Une nouveauté qui intéressera surtout les intégrateurs cette fois-ci, plutôt que de manipuler les fichiers de layouts pour positionner les différents blocks sur les pages du site (ce qui peut être fastidieux), Magento va proposer une interface WYSIWYG (à la Drupal) permettant de positionner les blocks plus simplement.

Magento 1.X permet au niveau de sa construction package/thème d’aller jusqu’à trois niveaux de cascades (utile pour éviter le redondance entre templates, css ….). Même si a priori cela est suffisant dans la plupart des cas, Magento 2 va encore plus loin et proposera une infinité de niveaux de cascades.

Magento 2 fournira une meilleure gestion de l’organisation du file system sur les ressources publiques (ayant pour but de faciliter la gestion de droits du serveur WEB), avec la création d’un dossier pub, à la racine de l’application, dans lequel nous retrouverons entres autres les ressources js, media, errors….

2. Problèmes des versions 1.X et solutions apportées par Magento 2

2.1 Problèmes de couplages fort entre modules

Etat actuel sous Magento 1.x

Parmi les exemples les plus frappants de ce problème, nous ne pouvons pas séparer à l’heure actuelle le module Mage_Catalog du module Mage_Checkout notamment à cause de cette dépendance :

Exemple de couplage fort dans Magento

Un autre exemple de ce problème est l’existence du module Mage_Adminhtml qui contient le comportement admin de quasiment tous les modules du noyau, ce qui va à l’encontre même de la conception modulaire.

Ce qui est attendu avec Magento 2

Une approche orientée composants : c’est à dire que chaque composant sera une agrégation de plusieurs modules fonctionnels fortement couplés entre eux (Mage_Catalog, Mage_CatalogSearch…) d’un côté et (Mage_Checkout, Mage_Sales….) d’autre part.

Ce n’est pas encore le cas à l’heure où cet article est publié, mais le module Mage_Adminhtml devrait être éclaté dans chacun des modules adaptés.

2.2 Lourdeurs de gestion des traductions

Etat en version Magento 1.X

Si l’on a 2 vues magasins Magento avec la même locale (fr_FR), il faudra traduire 2 fois les champs produits/catégories pour chaque vue magasin, (si la configuration par défaut n’est pas fr_FR)

Le processus de traduction des mails est lourd et fastidieux si l’on applique toutes les étapes via l’admin.

Trop de façons multiples de renseigner les traductions et le manque de point central fait qu’une erreur de traduction peut devenir pénible à localiser et corriger (dans Magento il faut traduire les modules, les thèmes, le contenu cms, les entités produits catégories, les options d’attributs….)

Ce qui est attendu sous Magento 2

Les traductions pour les entités produits et catégories devrait être gérées par locale et non plus par store_views : espérons alors qu’il n’y aura pas de duplications de traductions (par exemple, entre fr_FR et fr_BE).

Pour les autres problèmes, aucune solution n’est a priori avancée pour le moment.

2.3 Impossibilité de gérer plusieurs SGBD

Etat actuel sous Magento 1.x

Vous l’avez probablement remarqué : dans les versions de Magento jusqu’aux versions 1.7.x, il existait une forte dépendance des couches ressources et des scripts à MySQL. En effet, les scripts étaient tous préfixés par mysql4-, et on retrouvait cette convention dans le nommage des ressources (et collections). Depuis la version 1.7 de Magento est apparue une surcouche, visant à remplacer les scripts et les ressources par une “ressource-db” générique notamment, puisque la construction du SQL sera déléguée aux couches basses du ZF (Zend_Db_XXX), donc indépendante du SGBD choisi. Le piège étant alors de ne pas mettre du code SQL potentiellement spécifique à un SGBD (insert on duplicate key par ex.) dans une ressource nommée de façon générique : c’est pour cela que l’ancienne notation restera toujours disponible, notamment pour y insérer du SQL spécifique.

Ce qui est attendu sous Magento 2

Le travail effectué en amont permettra à la version 2 de Magento de proposer en standard l’utilisation de :

  • Mysql
  • Oracle
  • MsSQL

2.4 L’utilisation de jQuery n’est pas conseillée sur les versions 1.X

Etat actuel sous Magento 1.x

Il est reconnu que jQuery a actuellement plus d’avance en termes de performances, communauté, librairies et modules disponibles sur le web que prototype et scriptacoulous. Cependant en 2008, lors de la création de Magento, c’était moins évident et Magento Inc a pris le parti d’implanter ces 2 dernières librairies. Ceci n’est pas sans effet puisque installer jQuery va donner une lourdeur supplémentaire au site (une librairie de + à charger), d’autant que certaines fonctionnalités de jQuery sont redondantes avec Prototype. Bref, la communauté veut du jQuery !

Ce qui est attendu sous Magento 2

Et elle l’aura puisqu’en v2, jQuery sera le framework installé en standard.

2.5 Les tests unitaires et Magento

Etat actuel sous Magento 1.x

A l’heure actuelle, sans aller jusqu’à une méthodologie “test-driven development”, il est très fortement apprécié par les prestataires comme les clients de mettre en place des tests (unitaires, d’intégration…), qui donnent de la robustesse à l’application et évitent lors de futures MAJ du produit de mauvaises surprises (régressions).

Cette mise en place de tests est d’autant plus appréciée par ceux qui souhaitent distribuer du Magento à grande échelle (industrialisation) ou qui ont une étape de construction de projets en différentes versions. Pour ceux qui feront un projet en One-Shot, comme c’est le cas de beaucoup de petites agences, le surcoût de mise en place de tests sera à mon avis superflu.

Bon, c’est pas le tout, mais vous avez dû voir que dans Magento, il n’y a  rien qui se rapproche de près ou de loin à des tests, pas même la présence d’un dossier test (même vide :p…)

Ce qui est attendu sous Magento 2

En version 2, va apparaitre un dossier dev/tests dans lequel seront implémentés quatre types de tests coté PHP + 1 coté JS.

  • intégration
  • unitaire
  • performance
  • static (ces tests vont mesurer la bonne santé du code (complexité cyclomatique, checkstyle etc…))

Tests dans Magento 2 : intégration, unitaires, ...

2.6 Où sont les fichiers de vues ?

Etat actuel sous Magento 1.x

A l’heure actuelle, vous avez dû constater que pour déployer un module, il faut distribuer d’une part le code du module app/code/[local|community]/MyNamesapce/MyModule/…. et d’autre part, si votre module doit afficher quelque chose, distribuer dans app/design/frontend/package/theme/ les ressources (layouts et templates) de votre module. Le tout sans parler des emails, qui eux sont positionnés dans app/locale/template/emails… Ceci a plusieurs effets :

  • Lourdeur de déploiement de fichiers
  • Doit-on dans le cas d’un module communautaire distribuer les ressources dans base/default ou default/default ?

Ce qui est attendu sous Magento 2

Chaque module embarquera ses fichiers de vues (layout.xml, templates, emails) dans un dossier view. Ce dossier view des modules sera l’équivalent au niveau du fallback de base/default qui lui est supprimé.

Vues dans Magento 2

2.7 Du code inutile ou commenté

Etat actuel sous Magento 1.x

Vous avez dû voir dans certaines classes de vilains bouts de codes commentés. Par exemple dans Mage_Checkout_Model_Type_Onepage où vous trouvez en fin de fichier pour une version 1.7 de Magento environ 200 lignes de codes commentées.

Ce qui est attendu sous Magento 2

Nettoyage du code inutile (deprecated) et commenté dans la prochaine version. Cela est rendu possible notamment grâce au fait qu’il est convenu qu’il n’y aura pas de compatibilité ascendante directe entre les versions 1.X et 2 de Magento (la compatibilité pourra être assurée au moins via des scripts sur les versions du core).

2.8 Les Patterns Factory de Magento

Etat actuel sous Magento 1.x

Voici à quoi ressemble une instanciation standard de classes dans Magento :

Instanciation de classes sous Magento

Vous constaterez que la chaîne de caractère passée en paramètre des patterns factory (ici helper et model), n’est pas des plus facile à traiter. En effet, il faut retrouver le nom de la classe via une gymnastique avec les fichiers de config, puis valider les rewrite (éventuellement checker que le module est actif ou non), puis enfin sortir une instance… C’est plus lourd en terme de traitements (pas de beaucoup mais quand même) et surtout plus difficile à appréhender pour le nouveau développeur.

Ce qui est attendu sous Magento 2

Les patterns factory de Magento prendront en paramètre le nom de la classe complet et non plus une chaine de caractère à mapper via la config.

Nous aurons donc :

 

2.9 L’EAV

Etat actuel sous Magento 1.x

Vous l’aurez constaté, l’EAV est bien présent dans la modélisation des données de Magento. Les entités catalog_product, catalog_categroy, customer, et customer_address sont en effet bien représentées sous ce modèle.

Cependant, peut-on considérer que les avantages de l’EAV (structure de table fixe), est vraiment nécessaire à une problématique e-Commerce où 90 à 95% de la modélisation de ces entités est fixée dès le départ ?

Et cela induit de nombreux problèmes : complexité d’accès au tables, performances en écriture comme en lecture, nécessité de construire des tables d’index parfois très couteuses à construire si on fait n’importe quoi dans son BO…

Ce qui est attendu sous Magento 2

Malheureusement ici, pas de changements prévus a priori.

3. Compatibilité ascendante Magento 1.X vers Magento 2 ?

Eh bien, la réponse est oui et non, en effet Magento mettra à disposition des scripts permettant de modifier le code des modules, permettant de les faire passer d’une version 1.X à une version 2, mais certains refactoring très impactant comme le passage de prototype à jQuery nécessiteront de l’huile de coude pour que la migration se passe bien.

4. Ce qui pourrait aussi être fait dans Magento 2…

Magento 2 devrait conserver certains problèmes de Magento 1.

Nous pourrions citer, en vrac :

  • Le fait que Magento n’ait pas une architecture technique orientée service (de fait la sauvegarde produit et son implémentation des contrôles métiers se trouvent à plusieurs endroit dans le code, dans la couche Adminhtml, dans la couche Api, Api2, dans la couche des anciens importdataflow et dans la couche des nouveaux imports : module ImportExport)
  • Si Magento avait utilisé des fichiers de config en php et non en xml cela aurait accéléré la lecture des configs. De plus APC peut mettre en cache le bytecode compilé de structure simple (tableaux) en mémoire.
  • Pour le moment il est impossible d’activer/désactiver des modules en fonction de contextes (sites web), il n’y a même aucune interface ergonomique dans l’admin, le Downloader ne pemettant que l’installation/désinstallation de modules

Pour en savoir plus, vous pouvez suivre le développement de Magento 2 sur Github, regarder cette vidéo intéressante d’un architecte Magento Inc., accéder au wiki Magento 2 ou réagir dans les commentaires :)

Un ping pour “Magento 2 : ce qui va changer !

24 commentaires pour “Magento 2 : ce qui va changer !

  1. Merci beaucoup pour toutes ces précisions ! Par contre je suis pas emballé par JQuery moi :’) Mais je constate que la tendance pour beaucoup est de migrer progressivement vers jQuery ou Mootools. Les 20 mois qui se sont écoulés entre la 1.6 et la 1.7 ont contribué à inciter les développeurs à se tourner vers autre chose… Dommage car Prototype reste pour moi le framework ultime (notamment pour les classes et la syntaxe). Une chose est sûre, il va me manquer dans Magento :)

    • Merci pour ton avis, de même, je me suis bien habitué à Prototype avec le temps, par contre en formation, les intégrateurs et développeurs que l’on forme ont tendance à bien regretter de pas avoir jQuery en standard. Du coup on a vu quelques équipes s’atteler à faire leur propre template base/default utilisant jQuery (et parfois même basé sur de l’html5).

    • Effectivement. Une migration d’une 1.x vers une autre 1.x n’est déjà pas simple même avec un projet justifiant d’une bonne implémentation, dans les standards Magento et avec une cohérence globale de réalisation. Alors migrer un projet bancal 1.x vers une 2.x à mon avis ça va engendrer pas mal de refontes !

  2. Merci pour l’article, ce comparatif apporte davantage de clarté sur la V2.
    En tant que développeur front le passage à jQuery est une excellente nouvelle, en espérant que la sortie coïncide avec la publication de jQuery 2 qui promet d’être très performant.

  3. merci pour toutes ces infos; à vous lire, les améliorations et surtout les coûts de migration imposent une certaine patience pour tout nouveau projet d’e-commerce. Est-ce une bonne clé de lecture?

    • Dans le cadre de nos travaux avec les équipes projets que nous accompagnons en conseil, il arrive de mettre à jour des coeurs Magento. Au plus cela a jusqu’à présent pris 2 jours (sur un projet bien conçu et développé). Par rapport à la quantité de changements dans Magento 2 cela représenterait plus de travail mais pour autant je n’irais pas jusqu’à dire, personnellement, qu’il faut mettre en pause un projet dans l’attente de Magento 2. Et puis la date de sortie reste une date de sortie théorique, et donc attendre une sortie stable n’est pertinent que si l’échéance du projet n’est vraiment pas proche :-) (d’autant qu’une fois la version stable sortie, il faut toujours se donner quelques semaines de battement pour tester, analyser les feedbacks de la communauté, appliquer d’éventuels patchs, …)

  4. Pour l’avoir fait plusieurs fois (mise à jour d’une installation Magento CE 1.4 vers 1.6 et EE 1.3 vers 1.7), la mise à jour complète d’une installation demande bien plus de 2 jours.

    En effet, en fonction du nombre de modules “custom” créés, l’ensemble des surcharges doivent être revalidées manuellement.
    De plus, Magento 1.x ne disposant pas de tests unitaires, une grosse batterie de tests doivent être effectuées manuellement sur l’installation après sa mise à jour afin de s’assurer qu’aucune régression n’est présente (création de compte, passage de commande etc.).
    La mise en production d’une mise à jour n’est également pas des plus simples, et demande de la préparation et donc du temps.

    D’après mon expérience, une mise à jour d’une boutique de taille moyenne (10-15 modules “custom”) demande au moins 10 jours.

  5. Bonjour Anthony,

    Merci pour votre contribution sur le sujet. Certains sites Magento peuvent effectivement demander une telle durée, en fonction des différents points à vérifier, et de l’implémentation du projet. Il est même parfois préférable, nous le constatons sur certains audits Magento, de repartir de zéro. Notez que mon indication portait sur une migration en local, au cours d’un projet donc sans déploiement.

    Permettez-moi de profiter de vos indications pour fournir quelques préconisations permettant de réduire ce temps.

    1. Concernant les surcharges

    1. Veiller à ce que les personnalisations liées à des modules soient toujours implémentées via les fichiers de layout de ceux-ci, et non via le local.xml ou les fichiers de layout originaux.
    2. Lorsqu’un comportement lié à une vue (classe block) est à modifier, changer le type spécifié dans le layout permet mécaniquement d’éviter une instruction de rewrite (la nouvelle classe étend alors la classe originale, mais une telle vérification de compatibilité lors d’une mise à jour est rapide).
    3. Lorsqu’un comportement lié à une vue (fichier de template) doit être modifié de manière significative, il est parfois plus intéressant de développer une méthode répondant au besoin dans le helper d’un nouveau module spécifique. La nouvelle méthode, basée sur des méthodes invariables du coeur, ne nécessite alors qu’une très rapide vérification lors d’une mise à jour.
    4. Evidemment, placer des observers sur les événements appropriés permet généralement de réduire la quantité de code spécifique, et donc, cela réduit le temps nécessaire à la mise à jour au final.
    5. Au delà des observers, l’utilisation des pratiques appropriées à chaque développement permet également de réduire la quantité de code spécifique (backend models, …).

    2. Concernant les tests unitaires
    Bien que Magento 1.x ne soit pas conçu pour être testable unitairement, le module de test développé par Ecomdev permet de mettre en place les tests les plus importants.

    3. Concernant les tests fonctionnels
    Les procédures manuelles de vérification du bon fonctionnement d’un site sont laborieuses et chronophages. Il me semble que c’est ce point qui allonge particulièrement la durée de test amenant la migration à finalement durer 10 jours ou plus. La réalisation de tests fonctionnels peut être automatisée. Le plus simple peut être de créer des scénarii avec Selenium IDE pour les rejouer sur le navigateur. L’étape suivante consiste à les jouer avec Selenium Core. Il y a plus poussé mais d’une manière générale l’automatisation des tests fonctionnels est “rentable” pour une équipe projet comme pour un développeur seul.

    4. Conception, conception, conception…
    Il est entendu que la conception a un rôle crucial, puisqu’elle garantit un volume de code à la fois faible et strictement nécessaire. Mécaniquement : moins de code nécessaire = moins à produire sur le projet = moins à tester = migration plus rapide.

    D’autres bonnes pratiques et méthodes de travail pourraient être citées, cela serait peut-être l’occasion d’un nouvel article.
    Si d’autres lecteurs ont des conseils à ajouter, je les invite à réagir ;-).
    Merci beaucoup pour votre retour en tout cas !

  6. Merci à vous pour cet article et pour ces conseils concernant les tests fonctionnels qui me seront sans doute très utiles!

    Un point important qu’il faut également souligner, selon moi, concerne la gestion des thèmes (fallback), notamment pour les versions Entreprise, qui permettent également, lorsqu’elle est faite intelligemment, d’alléger le travail de mise à jour.

    En effet, il est nécessaire d’éviter à tout pris éviter de travailler dans les thèmes par défaut (“base/default”, “default/default” etc.) qui seront écrasés lors de chaque mise à jour.
    Préférez, pour les versions communautaires, créer votre thème “custom” dans le package “default” (“default/custom”) ou sous la forme d’un nouveau package (“custom/default”).
    Cette architecture vous permettra de profiter du système de “fallback” de Magento, vous évitant de re-créer dans votre thème l’ensemble des templates / layouts XML par défaut de Magento.
    Pour toute mise en forme “custom”, non liée à un module, travaillez un maximum à l’aide du ficher “local.xml” (et non des fichiers “checkout.xml”, “sales.xml”, “catalog.xml” etc.).

    Pour les versions Entreprise, un nouveau thème “custom” peut être créé dans le package “enterprise” (“enterprise/custom”) ou sous la forme d’un nouveau package. Dans ce cas précis, et Magento n’étant pas capable de distinguer un package “enterprise” d’un package “community”, l’architecture optimale, à mon sens, est la suivante:
    * custom/default: lien symbolique/copie vers le thème “enterprise/default”
    * custom/custom: thème custom

  7. Il est clair que les interventions sur le design représentant une bonne partie du travail, mieux elles sont réalisées, plus rapides sont les mises à jour.

    En revanche la stratégie que vous recommandez est à mettre au regard du volume de changements à effectuer au niveau du design, et du contexte du projet.

    Baser un travail d’intégration spécifique sur base/default est intéressant si et seulement si les personnalisations sont relativement peu importantes et qu’un maquettage complet peut être réalisé en modifiant, disons une dizaine de layout et une vingtaine de fichiers de template.

    Au delà, il me semble plus intéressant de capitaliser sur son propre base/default, lequel serait, par exemple en html5/jQuery. Pour une agence comme pour un développeur indépendant, cela permet de rendre “natives” des personnalisations qui sont alors disponibles quelque soit le projet. Les intégrations graphiques peuvent alors être réalisées dans un client/default surchargeant le base/default.

    Sur des personnalisations graphiques importantes, nous avons remarqué que ce système est plus efficace car il permet aux intégrateurs et aux développeurs de savoir plus rapidement quels fichiers éditer.

    De plus, dans le cadre de mises à jour, il me semble que l’on peut ignorer l’upgrade sur base/default, dans la mesure où les corrections HTML/CSS/JS sont a priori inutiles (s’il y avait un bug, il aurait été remarqué sur l’intégration spécifique). Quant aux nouveaux fichiers de design liés à des nouvelles fonctionnalités, ceux-ci sont alors à déployer manuellement dans le “base/default” modifié.

    Un autre intérêt de la modification de base/default dans le cadre d’un gros projet : cela évite de se retrouver avec un fichier local.xml très volumineux, mais peu efficace. Un exemple : nous intégrons la V2 du site de l’e-Commerce Academy sur une plateforme Magento (:-D), avec un academy/default venant en surcharge du base/default original (non modifié). Résultat : pour retirer les blocs inutiles présents dans le design natif, on se retrouve vite avec des dizaines de lignes d’instructions removeItem, remove, unsetChild, unsetChildren, … pas top ;-)

  8. Et quant est-il des fonctionnalités CMS beaucoup trop limitées actuellement et dont la coexistence avec les fonctions e-commerce est devenue un MUST pour pas mal d’e-commerçants. Vague sur laquelle surfent RBS Change et Drupal Commerce pour se positionner comme une solution unique pour résoudre ces deux aspects ?

  9. Bonjour,

    J’ai été formé par la Magento Academy sur la 1.4. est ce que vous proposez des formations de mise à niveau pour Magento 2, et si oui combien de jours faut-il compter ?

  10. Bonjour,

    Je viens de lire ce superbe article écrit le 16 août 2012!!!!, et le truc qui me choque (personnellement), c’est qu’on est aujourd’hui le 17 janvier 2014! et toujours pas de Magento 2. Ce qui me choque c’est que personne a posé de question là dessus quoi.

    Alors serait-il possible de me dire, si quelqu’un en sait plus, quand sortira Magento 2? Pourquoi ce retard d’une année (pour l’instant…)?

    Ce serait vraiment très gentil de me répondre avec le plus de précision possible, parce que je souhaite créer un site e-commerce, et je recherche et m’interroge beaucoup sur quel produit choisir. (Parce que je vois bien que d’une fois choisi, on le garde… On en change pas facilement)
    Je souhaite bien sûr que mon projet fonctionne du tonnerre, et s’il venait à grandir (beaucoup), je souhaite que le CMS choisi supporte la charge.
    Et MON problème est que:
    - Prestashop m’avait tapé à l’oeil au départ, mais après renseignement, je vois qu’il y a beaucoup de bug et que la solution n’est pas stable (et que leur récent positionnement ne va rien arranger). Donc abandonné on dira…
    - RBS Change m’intéresse énormément, mais je préfère utiliser la version 4 qui…. a du retard…..
    - Magento m’avait l’air trop compliqué, mais après renseignement ça va, mais pareil…. je préfère direct utiliser la version 2.
    - OpenCart m’a l’air stable, mais peut-être trop limité….

    Au secours! Merci de vos réponse… ^^

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">