Prestashop 1.7 : Nos premiers tests

ps17

Depuis quelques semaines déjà, Prestashop a publié officiellement la version 1.7. Il était alors temps d’effectuer quelques tests sur cette version finale afin de pouvoir vous conseiller au mieux sur les choix à prendre suite à cette mise à jour majeure de la solution E-commerce.

1.7 : Mise à jour majeure ?

On aurait presque était favorable à une version 2.0 plutôt qu’une nomenclature en 1.7 tant les modifications sont importantes.
En effet, l’intégration du framework Symfony à Prestashop est une excellente chose. C’est un framework très abouti et très puissant qui impose de suivre les bonnes pratiques de développement.

Cela a donc conduit les équipes de Prestashop à trouver un juste milieu entre le retravaille en profondeur du coeur de la solution ou bien un travail plus progressif. La seconde option a été choisie, notamment pour conserver au maximum la compatibilité avec les modules développés pour les version 1.6.

Cela a été également l’occasion de revoir complètement l’architecture des thèmes et pour le plus grand bonheur des développeurs, la création des thèmes enfants !

L’intégration du moteur de template Twig est aussi une grande avancé,e de par ses fonctionnalités abouties et ses performances.
Cette réécriture en profondeur des thèmes, vous vous en doutez, n’est pas sans conséquences ! Et oui, les thèmes 1.6 ne sont pas du tout compatible avec cette nouvelle version de Prestashop. L’occasion peut-être de rafraichir l’image de votre société ?

Compatibilité des modules

Une grande rétro-compatibilité des modules 1.6 a été conservé avec cette montée de version. Cependant, tout module de paiement nécessiteront une mise à jour au niveau des points d’accroches ainsi que du fonctionnement post page de validation.

D’où le manque cruel de modules de paiement compatible avec cette sortie de la 1.7 !

Problèmes rencontrés

Edition de fiches produits

Globalement, l’interface est assez intéressante. Réorganisée en profondeur, elle répond mieux aux attentes des e-commerçants dans leurs tâches quotidienne d’édition des produits. Cependant, nous avons rencontré quelques soucis majeurs lors de modification de ces produits !

Perte d’indexation à l’enregistrement

Et oui, lors de l’enregistrement de chaque produit, il s’avérait que celui-ci n’était plus considéré comme indexé par le moteur de recherche.
Nous avons corrigé ce problème de comportement en surchargeant le controleur « AdminProductController » dans sa méthode « postProcess ».

Un défaut de mise à jour de l’attribut « indexed » est en cause.

Impact de prix des déclinaisons

Un gros point noir concerne l’édition des impacts de prix des déclinaisons. Si certains d’entre vous ont testé l’administration, ils se sont peut-être rendu compte que les impact de prix doivent absolument être renseignée en utilisant une « VIRGULE » comme séparateur de décimale, mais pourquoi ce choix ??

C’est un choix assez incompréhensible qui en plus est la cause de bien des problèmes !

Et oui, comme nous l’avons vu les prix doivent être renseignés avec des virgules et non pas des points comme dans le reste du monde, or lors de l’envoi des données du formulaire à l’enregistrement des produits, les équipes de Prestashop ont ajouté un traitement javascript qui vient substituer la virgule pour la remplacer par un point.

Si ce traitement n’est pas fait, à la récupération des données côté serveur un traitement est effectué afin de caster les données de ce formulaire et ainsi de contrôler ce qui a été envoyé. C’est très bien pour la sécurité mais dans notre cas si vous castez ceci « 2,34 » en nombre flottant vous obtiendrez « 2 » car la virgule ne définie pas un nombre flottant.

Malheureusement, ce traitement javascript avant envoi du formulaire ne fonctionne que si vous modifiez les tarifs d’impact. Si vous enregistrez votre produit sans effectuer de modification sur ces produits, alors les virgules ne sont pas modifiée en point et vous vous retrouvez avec tous les impacts de prix sans partie décimale !

Vous vous dites : facile, il suffit de modifier pour utiliser des « . » à la place des virgules lorsque l’on renseigne les prix ?

Et bien non, nous avons regardé le code javascript associé à cette page et nous pouvons vous dire qu’il est sacrément dense….2000 lignes de code javascript pour cette partie.
Effectivement, il est bien plus propre qu’avant puisqu’il y a utilisation de classes, mais 2000 lignes…

Nous avons donc contourné le problème autrement ! Ce qui nous permet de renseigner des tarifs aussi bien avec des points qu’avec des virgules.

 

Traduction des modules

Travaillant sur la version 1.7.0.2, nous avions besoin d’effectuer des traductions sur nos modules développés.

Simple non ? rendez-vous dans la page International > Traduction et là ! Et bien non, pas de menu pour traduire les modules…

La version 1.7.04 ayant été releasée aujourd’hui, nous avons effectué l’upgrade (qui a fonctionné sous windows mais pas sur serveur linux) et le menu de traduction des modules est apparu ! Nous n’étions pas fou, il manquait bien quelque-chose 🙂

 

Performances

Un des avantages de Symfony est sa précompilation, et ses mises en cache importantes ce qui a pour effet d’améliorer de façon importante les performances. Nous n’avons pas encore pu effectuer de benchmark sur des gros catalogues de produits mais malheureusement la structure de la base de données n’a pas était revue…ainsi les même problèmes de performance seront toujours présents notamment sur les pages catégories qui font toujours appel à une requête bourrée de jointures ouvertes et qui est très consommatrice.

Allez, la voici :

$sql = 'SELECT p.*, product_shop.*, stock.out_of_stock, IFNULL(stock.quantity, 0) AS quantity'.(Combination::isFeatureActive() ? ', IFNULL(product_attribute_shop.id_product_attribute, 0) AS id_product_attribute,
                    product_attribute_shop.minimal_quantity AS product_attribute_minimal_quantity' : '').', pl.`description`, pl.`description_short`, pl.`available_now`,
                    pl.`available_later`, pl.`link_rewrite`, pl.`meta_description`, pl.`meta_keywords`, pl.`meta_title`, pl.`name`, image_shop.`id_image` id_image,
                    il.`legend` as legend, m.`name` AS manufacturer_name, cl.`name` AS category_default,
                    DATEDIFF(product_shop.`date_add`, DATE_SUB("'.date('Y-m-d').' 00:00:00",
                    INTERVAL '.(int) $nbDaysNewProduct.' DAY)) > 0 AS new, product_shop.price AS orderprice
                FROM `'._DB_PREFIX_.'category_product` cp
                LEFT JOIN `'._DB_PREFIX_.'product` p
                    ON p.`id_product` = cp.`id_product`
                '.Shop::addSqlAssociation('product', 'p').
                (Combination::isFeatureActive() ? ' LEFT JOIN `'._DB_PREFIX_.'product_attribute_shop` product_attribute_shop
                ON (p.`id_product` = product_attribute_shop.`id_product` AND product_attribute_shop.`default_on` = 1 AND product_attribute_shop.id_shop='.(int) $context->shop->id.')':'').'
                '.Product::sqlStock('p', 0).'
                LEFT JOIN `'._DB_PREFIX_.'category_lang` cl
                    ON (product_shop.`id_category_default` = cl.`id_category`
                    AND cl.`id_lang` = '.(int) $idLang.Shop::addSqlRestrictionOnLang('cl').')
                LEFT JOIN `'._DB_PREFIX_.'product_lang` pl
                    ON (p.`id_product` = pl.`id_product`
                    AND pl.`id_lang` = '.(int) $idLang.Shop::addSqlRestrictionOnLang('pl').')
                LEFT JOIN `'._DB_PREFIX_.'image_shop` image_shop
                    ON (image_shop.`id_product` = p.`id_product` AND image_shop.cover=1 AND image_shop.id_shop='.(int)$context->shop->id.')
                LEFT JOIN `'._DB_PREFIX_.'image_lang` il
                    ON (image_shop.`id_image` = il.`id_image`
                    AND il.`id_lang` = '.(int) $idLang.')
                LEFT JOIN `'._DB_PREFIX_.'manufacturer` m
                    ON m.`id_manufacturer` = p.`id_manufacturer`
                WHERE product_shop.`id_shop` = '.(int) $context->shop->id.'
                    AND cp.`id_category` = '.(int) $this->id
                    .($active ? ' AND product_shop.`active` = 1' : '')
                    .($front ? ' AND product_shop.`visibility` IN ("both", "catalog")' : '')
                    .($idSupplier ? ' AND p.id_supplier = '.(int)$idSupplier : '');

Conclusion

La conclusion est assez simple : pour utiliser Prestashop 1.7 en production, il est trop tôt puisque des améliorations sont nécessaires à son bon fonctionnement, ainsi que pour laisser le temps aux développeurs de mettre à jour leurs modules.

Néanmoins, cette version 1.7 reste extrêmement prometteuse mais un peu jeune 😉
Bravo à l’équipe Prestashop qui sont en train de corriger ces erreurs de jeunesse de la solution !

Pour le moment, nous recommandons à nos clients de rester sur la version 1.6.

Pour toute question ou information n’hésitez pas à nous contacter par chat ou email via le formulaire

2 thoughts on “Prestashop 1.7 : Nos premiers tests

  • Bonjour,
    Nous le contournons en effectuant un traitement sur les variables reçues.
    Nous pouvons vous proposer la prestation de mise en place du correctif si vous le souhaitez.

    Meilleurs voeux 2018,
    Renaud.

Comments are closed.