Test Prestashop 1.7

Config basique :
PrestaShop v1.7.0.0 Beta1
Windows 10 (Intel i5, 8 Go RAM)
WAMP

INSTALL :
L’archive se compose d’un index.php et d’un zip.
Essai pour essai, après avoir configuré mon serveur j’ai lancé le fichier php.
J’ai été agréablement surprise de ne rien avoir à faire d’autres : le script dézippe l’archive, ce qui règle le problème d’envoi de milliers de fichiers par ftp quand on n’a pas accès au serveur autrement que par ftp.
Puis on arrive sur un écran de bienvenue
FireShot Screen Capture #060 - 'Assistant d'installation' - prestashop_17_install_index_php

Puis écran de la licence (OSL 3.0), puis un écran infos de la boutique (nom, pays, compte admin…), puis l’écran de config de la base de données :
FireShot Screen Capture #061 - 'Assistant d'installation' - prestashop_17_install_index_php

Puis l’écran d’installation, avec l’avancement des étapes qui est bien indiqué visuellement.
Là il y a ajout des produits de démo (je n’ai pas vu où on pouvait désactiver cette option).
Et ça passe directement à l’écran de fin d’installation (d’où l’absence de capture de l’écran précédent) :
FireShot Screen Capture #062 - 'Assistant d'installation' - prestashop_17_install_index_php

Comme d’hab on nous demande de supprimer le dossier install, je vais juste le renommer.

Hop voici la page d’accueil de ma nouvelle boutique :
FireShot Screen Capture #063 - 'test' - prestashop_17

Bon ben déjà ça marche, et c’est propre.
Passons à l’admin :
– l’écran d’identification ne diffère pas vraiment pas rapport à la 1.6
– Après l’identification, j’ai un pingouin qui s’appelle Preston qui me propose de me guider. Je vais passer pour le moment…
Voici la tableau de bord principal :
FireShot Screen Capture #064 - 'Tableau de Bord • test' - prestashop_17_admin700dnhrsw_index_php_controller=AdminDashboard&token=6cd23070673f7b08b4b90

Ce qui me frappe c’est la réorganisation du menu en 3 parties : SELL / IMPROVE / CONFIGURE
Bienvenue en 2016 🙂
On a un petit on/off pour le mode démo au niveau chiffres, ce qui est sympa.

Sur l’écran Commandes pas de grands changements.
Rentrons dans le catalogue…
C’est sur une fiche produit qu’il y a une différence :
FireShot Screen Capture #065 - 'Produits • test' - prestashop_17_admin700dnhrsw_product_form_1#tab-step1
Bon alors là sur cette capture comme les menus gauche et bas sont sticky ça fait bizarre mais aucun problème à l’écran.
Donc nous arrivons sur la présentation des photos, ce qui est un peu le nerf de la guerre donc c’est sympa et ça permet une reconnaissance immédiate du produit. A noter qu’on peut ajouter une légende aux photos. Si le clic sur le fond du container des photos pouvait non pas ouvrir l’upload mais fermer les petites fenêtres d’option de photo ce serait ergonomiquement bien (j’aime pas cliquer sur les croix, c’est super long par rapport à « cliquer ailleurs et ça ferme la modale », et c’est tellement mieux que je pense que ça rentre dans les usages).
Sur la même page et de manière assez simple sont présentés :
– les descriptions courtes et longues
– les caractéristiques (pré-définies, seules les valeurs peuvent être custom à ce niveau)
– la marque
– l’ajout rapide de produits liés
Sur la partie droite :
– Le choix produits normal / produits avec déclinaisons (ce qui change le reste)
– la quantité (produit simple uniquement)
– le prix HT et TTC
– le taux de TVA (parmi ceux pré-définis)
– les catégories avec : une recherche (problème de background transparent sur les résultats), les catégories du produit sous forme de tags, l’arborescence des catégories avec des cases à cocher, et même l’ajout de nouvelles catégories… que demande le peuple !
Et tout ça en ajax, plus précisément sans rechargement de page, j’ai plus d’un client qui baverait si je leur faisait cette démo 😉
Et quand on enregistre (bouton SAVE menu du bas), ça RESTE SUR LE MEME PAGE ! Enfin ils ont arrêté de faire semblant de deviner où l’admin voulait aller après…

Autres onglets :
– Quantités (produit « simple ») : gestion du comportement si pas de stock, minimum de commandes, label, date de disponibilité

– Déclinaison (produit avec déclinaison) : FireShot Screen Capture #066 - 'Produits • test' - prestashop_17_admin700dnhrsw_product_form_1#tab-step3
Je pense que c’est Work In Progress, en tout cas ça en donne l’impression. Il manque des cases « tout sélectionner » sur les différents attributs à combiner.
J’ai testé la génération avec 2×2 valeurs et ça marche bien, puis on retrouve pour chaque déclinaison les infos de quantité, date dispo, quantité minimum, ref, impact de prix HT, TTC, unité et en gros, impact poids, ISBN, EAN, UPC, et la gestion de plusieurs images par combinaison.

– Shipping : taille, poids, coût spécifique et transporteur(s) (si custom)

– Prix : on retrouve les infos basiques + un prix par unité (on peut mettre ce qu’on veut « kilo », « litre »…), le flag « promo », les prix spécifiques (par devise, pays, groupe client, client(s), déclinaisons, dates) et la gestion de priorités de ces règles.

– SEO : meta title si différent du product name, meta description si différent de la description courte, url rewritée, et une gestion de redirection si produit plus valable (c’est cool ça !) : par défaut 404, ou vers un autre produit en 301 ou en 302 !

– Options : Visibilité et disponibilité avec une case cross-canal « web only (not sold in your retail store) », tags, condition du produit, ref, ISBN, UPC, EAN… Champs de personnalisation texte ou fichier (multiples), fichiers joints, fournisseurs, références fournisseurs.

Pour en finir avec ce premier test, je vois rapidement que :
– la partie SAV se transforme tout doucement en mini-zendesk, ce qui sera suffisant pour de petites plateformes et ça c’est bien (j’ai dit mini hein, ok micro).
– sur la partie Modules et Services ça serait bien de ne pas avoir besoin de faire un autre clics pour arriver aux modules installés… et sinon l’affichage des modules a été pas mal modifié, il faudrait voir un prod si c’est mieux, plus ergonomique, plus rapide qu’actuellement, ça serait pas du luxe, surtout pour les dev.
– on peut créer des catégories de pages CMS.
– le positionnement des modules dans les hooks n’a pas changé.

Et… et il est temps d’aller se coucher 🙂

Bug Prestashop Google analytics commandes en double

Un debug qui vaut bien un article.

Prestashop 1.5.2
module gAnalytics 2.1.1
Commandes en doublon

Depuis plusieurs semaines sur le compte Analytics d’un client je voyais une commande en particulier qui était renvoyée régulièrement, plusieurs fois par jour, mais pas tout le temps.

1er debuggage corrigé par le nouvelle version du certes perfectible mais déjà excellent module gAnalytics pour Prestashop : les commandes pouvaient être envoyées plusieurs fois si le client se reconnectait sur la page de confirmation de commande. C’est bête hein, mais il faut faire une bonne petite routine pour éviter ça.

Avant cette correction c’était ainsi beaucoup de commandes qui étaient envoyées en plusieurs exemplaires (vive le taux de transformation).
Mais même après je voyais CETTE commande en particulier qui continuait à fausser énormément mes stats si bien que je devais segmenter mes rapports (avec id_transaction=…), mais je constatais alors que ça retirait aussi d’autres transactions.
A savoir que la segmentation d’un rapport porte sur les sessions répondant aux critères.
Une même session renvoyant une ancienne commande mais aussi des commandes du jour ? Comportement très étrange, je ne comprenais pas.

En isolant bien ce segment sur une seule journée pour plus de visibilité, j’ai pu afficher les pages vues dans le détail de cette session.
Et là j’ai constaté qu’il s’agissait d’une session admin. (L’admin envoie des stats analytics ?! Me dis-je d’un coup, interloquée que j’étais)
J’ai affiché une des pages vues incriminée et ouvert le code source… Et là stupeur je vois de mes yeux vus qu’effectivement la dite transaction est envoyée, le code analytics est là et… je viens donc de renvoyer la transaction à Analytics, super.

Et je décide donc d’aller debugger le module, screugneugneu.
J’avais bien sûr parcouru depuis plusieurs semaines le web à la recherche d’autres gentils développeurs qui auraient trouvé des solutions mais je n’ai rien trouvé à part des « oui moi aussi j’ai le même problème et je ne trouve pas de solution »

Mais là j’en avais juste marre.
Donc, pour résumer :
– Il y a une table [ps_]ganalytics qui enregistre -tout bêtement- les transactions à envoyer ou envoyées à GA.
– Il y a une colonne ‘sent’ qui passe de 0 à 1 lorsque la transaction est envoyée (au cas où elle n’aurait pas été envoyée par l’internaute lui même s’il n’a pas afficher la page de confirmation de commande, problème très courant) et avec un timestamp
– Dans le hook du header de l’admin s’exécute ceci :
1. select les transactions dans [ps_]ganalytics qui sont à sent=0 enregistrées il y a plus de 30 mn (le DATE_ADD(date_add, INTERVAL 30 minute) < NOW() )
2. envoie ces commandes à GA (addtrans)
3. update [ps_]ganalytics : met date_add = NOW() (et sent=1 sans doute quelque part à un moment donné…) pour ces id_transaction et avec LIMIT 1

La cause de nos soucis CAR :
– ma screugneugneu commande était en DOUBLON dans cette table [ps_]ganalytics
– une ligne avec sent à 0, une ligne avec sent à 1
– DONC il prenait la commande, il la renvoyait à GA, et… il updatait une ligne car la requête porte sur l’id_transaction et non l’id_google_analytics qui est la clé primaire ET qu’il y a ce LIMIT 1 donc au hasard il prenait la ligne qui était déjà à sent=1
– donc il y avait toujours la ligne avec sent=0
– donc il recommençait à l’envoyer encore et encore…

Résolution du problème : supprimer la ligne avec sent=0 dans la table [ps_]ganalytics, c’est tout.
Et pourquoi pas modifier les requêtes de ganalytics.php > hookBackOfficeHeader() et de controllers\admin\AdminGanalyticsAjax.php en retirant les LIMIT 1 si le coeur vous en dit.

CONCLUSION :
Si vous avez des commandes qui ne cessent de s’envoyer, que vous avez bien la dernière version du module ganalytics (2.1.1 ou supérieur) : vérifiez que vous n’avez pas des commandes en doublons dans la table [ps_]ganalytics. Voici une requête pour cela :
SELECT count(*), id_order from ps_ganalytics group by id_order having count(*)>1
Si c’est le cas et qu’il s’agit comme par miracle des commandes qui vous embêtent sur GA, bha supprimez les lignes des doublons qui ont sent à 0.

Et pourquoi pas si le coeur vous en dit supprimer les LIMIT 1 des requêtes UPDATE dans
– \modules\ganalytics\ganalytics.php > hookBackOfficeHeader()
– \modules\ganalytics\controllers\admin\AdminGanalyticsAjax.php

ps : Si vous avez un problème inverse, c’est-à-dire des commandes qui ne sont pas envoyées à Google Analytics, quelque soit votre site, CMS ou outil de développement, pratiquement tous les services de paiement en ligne incluent maintenant une option pour renvoyer directement l’internaute sur le site après avoir payé.
Ce qui a pour conséquence qu’il affiche la page de confirmation de commande, qui peut envoyer le bon code à GA lié à la bonne session.
Je gère cette problématique depuis 15 ans ! Sur Paypal il y a une option, et les modules bancaires proposent aussi cette option, souvent appelée la redirection automatique. Parlez-en à… qui de droit (ou à moi si vous vous sentez seuls !)

Ogone Prestashop