Magento 2 : ce qui va changer !

Magento 2 : ce qui va changer !

Mise à jour 02.12.14 : retrouvez les dernières actualités de Magento 2 avec la conférence vidéo de notre expert Gabriel BOUHATOUS lors du Bargento 2014 « Magento 2 : is « to migrate or not to migrate » the right question ? » ainsi que sa présentation lors de la MageConf, journée dédiée aux développeurs Magento, « Magento 2 : au-delà du changement de version, un changement de paradigme ? »

[toc ordered_list= »1,2,3″]

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 :

Mage::getSingleton('checkout/session')
=> Mage::getSingleton('Mage_Checkout_Model_Session')

 

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 :)