Résolution du bug du panier vide dans un cas précis

[unita]

Bonjour à tous,

 

J'avais laché l'affaire depuis des mois. Mais finalement, le site de mon épouse a perdu trop de commandes à cause du fameux bug du panier qui se vide aléatoirement. Beaucoup d'experts sont passés sur les forums, les pistes étaient les cookies, la géolocalisation, certains modules foireux, les www devant l'url...

 

J'ai donc décidé de faire un nouveau site en 1.7 avant de changer éventuellement de crèmerie (wizishop, magento, pas encore décidé) mais quand j'ai vu la tronche de prestashop 1.7, ses modules absents (commentaires clients, même pas intégré, une honte...) et vu que je me suis fais arnaquer par les Appolo thèmes (à éviter !!!), j'ai insisté pour presta 1.6 qui par défaut a un design correct pour peu qu'on foute le nez dans les css.

 

Je suis expert SQL et data à la base, c'est donc de ce côté que j'ai fouillé pour le bug du panier vide, qui touche un paquet de boutiques, et j'ai remarqué, surtout des vieilles, qui ont migré de version. J'ai donc minutieusement tout vérifié, les imports prestashop, pour trouver une solution au bug qui touche notre boutique depuis des mois. Il ne s'agit pas d'un bug prestashop, c'est un bug d'intégration et de "reprise de boutique", mais je pousse mon coup de gueule contre prestashop tout de même, qui pousse vers le business de l'open source (quelle blague, vachement gratuit...) : j'en veux pour preuve qu'on peut importer des produits, catégories (et que c'est mal foutu...) mais pas les commandes ?! C'est du foutage de gueule, j'hésite pas une seconde à le dire, comptablement parlant, c'est pas aux normes....

 

Bref, c'est un déphasage entre les tables ps_cart et d' id_cart de ps_orders qui fout le bordel. En français : si vous avez importé vos commandes, à l'aide d'un module, de sql (ce que j'avais fait) ou que vous avez utilisé un module de nettoyage qui a nettoyé les paniers, alors vous avez touché des données qui auraient du être protégées par de l'intégrité référentielle de base de données MySQL, ce que prestashop n'a pas fait (allez y messieurs, il est temps !).

 

Le bug du panier vide se produit dans le cas suivant :

1/ vous créez un panier (vous cliquez sur le bouton "ajouter au panier"), cela crée un enregistrement dans la table ps_cart

2/ si l'id_cart précédemment créé existe déjà dans l'id_cart de la table ps_orders, quand vous validez le panier ajax, youpi !! Vous obtenez un panier vide !!

 

Une requête simple comme bonjour est à passer pour corriger ce problème. Je la teste ce soir sur notre site de production et je vous tiens au courant. Et je vous la donne (ceux qui ont compris sauront l'écrire).

 

@ très vite.

Edited July 27, 2017 by unita (see edit history)

[Eolia]

Le module de nettoyage ne crée pas ce problème.

 

La table ps_cart a un autoincrément donc à moins de faire un truncate à l'arrache ou d'utiliser des modules foireux qui permettent "d’effacer" les commandes, ce n'est pas possible qu'il y ait collision d'id.

 

Pour info, à chaque fois que j'ai dû chercher la cause d'un cookie qui se barre ou d'un panier qui se vide la raison était toujours externe à Prestashop.

Soit une intervention directe en bdd, soit un upgrade foiré mal restauré, soit un module tiers.

[doekia]

Prestahop n'est pas tout blanc mais, là, un expert base de données SQL que tu dis. ... Désolé pour toi j'ai revendu mon vieux J7 baraque à frite.

[unita]

Voici la requête, je viens de refaire au moins 30 tests concluants sur mon site de prod. Pour moi ce foutu bug est corrigé. Voici la requête :

 

update

    ps_orders

set

    ps_orders.id_cart = 1

where

    ps_orders.id_cart > (select max(id_cart) from ps_cart) ;

 

Ce qui signifie : 

Pour toutes les commandes que vous avez reprises d'un ancien prestashop, et qui avaient un numéro de panier déjà renseigné, et supérieur au numéro de panier en cours, on force la valeur  1. Vous n'aurez plus de numéro de panier qui provoquera le panier vide.

 

Dans l'absolu, si vous importez manuellement vos commandes, importez également les paniers ! 

 

 

[unita]

Le module de nettoyage ne crée pas ce problème.

 

La table ps_cart a un autoincrément donc à moins de faire un truncate à l'arrache ou d'utiliser des modules foireux qui permettent "d’effacer" les commandes, ce n'est pas possible qu'il y ait collision d'id.

 

Pour info, à chaque fois que j'ai dû chercher la cause d'un cookie qui se barre ou d'un panier qui se vide la raison était toujours externe à Prestashop.

Soit une intervention directe en bdd, soit un upgrade foiré mal restauré, soit un module tiers.

 

Oui je confirme, Prestashop natif n'est pas en cause... Je ne suis pas choqué que le programme d'affichage du panier affiche un panier vide s'il le trouve déjà dans une commande précédente, sans le détail du panier...

 

C'est bien une intervention "humaine" qui est la cause de ce bug, que je suis le premier à avoir généré. Il ne peut pas y avoir collision d'id, certes... Mais on fait commetn pour upgrader une boutique de version de prestashop avec le module d'upgrade qui marche pas de 1.4 à 1.6 par exemple ? On fait comme on peut, y'a pas de doc, pas de module magique... Alors on fait quelques conneries j'en conviens....

 

Je suis juste vénère, car rien n'est fait pour migrer des boutiques, alors que le modèle de données n'a pas énormément bougé entre 1.4 et 1.7. Normal, je sais, c'est du logiciel libre, du business... Vénère mais content d'avoir surmonté ce bug ! ;-)

Edited July 27, 2017 by unita (see edit history)

[doekia]

Tu n'as rien surmonté du tout.

Tu viens d'inventer un nouveau bug que personne n'ira idée de chercher car ça n'arrive pas (c'est ça que tu appelle de l'intégrité de données).

Tes client doivent être content sur leurs factures

Et avec ce genre de manip qui fusille la base de données, ne t'étonne pas que l'outil de mise à jour plante.

Je migre 100% des boutiques avec les outils Prestashop que si tu avais à peine cherché à faire fonctionner plus que d'inventer des manip de clown t'aurais donné ample satisfaction.

Quand à prétendre que le schéma a à peine changé depuis les 1.4, on voit bien là toute ton expertise sql.

 

L'intégrité de données n'a pas obligation d'être dans le schéma, certaines règles d'ailleurs ne pourraient y être représenté. Je ne me rappelle d'aussi loin que j'aille, aucune version permettant la suppression de panier liés (voire pas du tout pour les vielles version). Et ont poussé comme des champignons des codes écris par le Kévin du coin pour faire ce que le code refusait de faire. Que se passera-t-il si la base de données renforce l'intégrité? La même chose. Au prétexte de n'avoir rien compris et de ne pouvoir "bidouiller" à loisir dans la bdd, ils feront sauter les contraintes.

L'intégrité d'un export n'existe que si l'on prend tout le modèle. Toi tu pinailles et pioche ce que bon te semble et ensuite tu couines parce que ça ne marche pas.

 

Non seulement c'est pathétique mais j'exhorte quiconque sans réelle connaissance du sujet à fuir ce topic et ta soit disant solution. 

Edited July 28, 2017 by doekia (see edit history)

[Eolia]

 

Voici la requête, je viens de refaire au moins 30 tests concluants sur mon site de prod. Pour moi ce foutu bug est corrigé. Voici la requête :

 

update

    ps_orders

set

    ps_orders.id_cart = 1

where

    ps_orders.id_cart > (select max(id_cart) from ps_cart) ;

 

Ce qui signifie : 

Pour toutes les commandes que vous avez reprises d'un ancien prestashop, et qui avaient un numéro de panier déjà renseigné, et supérieur au numéro de panier en cours, on force la valeur  1. Vous n'aurez plus de numéro de panier qui provoquera le panier vide.

 

Dans l'absolu, si vous importez manuellement vos commandes, importez également les paniers ! 

 

Là tu m'inquiètes sérieusement si tu es "expert SQL"...

 

Que devient la consistance des commandes si elles ont toute le même panier de référence ? Et les taxes ? Et les transporteurs ? Et les adresses ? Et les ID produits ?

 

Bien sûr que si il est possible d'importer tous les éléments que l'on veut d'une version Prestashop à une autre, il suffit juste de respecter les schémas ce qui devrait être une évidence pour ton niveau "d'expertise".

 

Une commande, c'est 20 tables et les dépendances qui vont avec. Donc soit on fait n'importe quoi à la kikoulol, soit on sait et on le fait de manière rationnelle et réfléchie.

 

Mais en aucun cas ta "solution" n'en est une car elle fait n'importe quoi et Prestashop va y perdre ses petits.

 

Avis aux lecteurs, ne tentez pas ce genre de manip qui est plus une bidouille qu'autre chose et mettra votre shop en carafe.

[unita]

Excusez-moi messieurs, j'ai bien dit dans un cas précis, et oui je reconnais que j'ai moi-même généré le bug. Si vous pensez que la solution est dangereuse, faites supprimer le post, je sais pas moi... 

 

Mais si d'autre personnes sont dans le même cas que moi, à savoir :

 

Migration de prestashop, avec reprise des commandes sans avoir repris les paniers (pourquoi pas, les paniers, fonctionnellement nous on n'avait pas besoin de les reprendre, c'était notre besoin, on fait pas de stats dessus), alors on a forcément le bug du panier vide, qui se produits systématiquement lorsque le ps_cart.id_cart existe déjà dans le ps_orders.id_cart.

 

La requête que j'ai faite va mettre à jour (excusez moi, je l'ai mal expliqué) les id_cart des vieilles commandes, celles qui ont eu lieu avant la migration et qui avaient un numéro forcément supérieur à l'auto incrément de la nouvelle table ps_cart, et cette requête fait en sorte que le cas de bug décrit n'est plus possible. Je n'ai plus les données initiales des paniers d'avant migration, je n'ai donc pas d'autre choix que de mettre une valeur fictive (1) pour l'identifiant des paniers. 

 

Alors oui, je suis probablement un clown de prestashop dans la mesure où je travaille sur le sujet 2 semaines par an, mais dans le cas précis de notre boutique (c'est repris dans le titre du topic), cela résout notre problème de panier vide.

 

Et oui, je conseille aux gens qui font des migrations d'uitliser les modules adéquats, mais dans notre cas précis, il fallait faire un export de données, modifier ces données en masse, et les réimporter, nous n'avons donc pas utilisé ces modules, à tort sans doute...

 

Maintenant, je vais m'occuper de l'étiquetage des commandes, car nous n'avons pas pu faire fonctionner correctement le logiciel de la poste, expeditor et le lien avec le module expeditor.net.

 

 

 

[doekia]

Bricolette est dans un bateau.

On pouvait récréer les paniers à partir des orders, order_detail, order_carrier, ... maintenant non tu n'a plus que du gloubiboulga

 

Dépêche toi donc de comprendre comment marche expeditor-inet, il est supprimé dans le mois prochain

[unita]

Bricolette est dans un bateau.

On pouvait récréer les paniers à partir des orders, order_detail, order_carrier, ... maintenant non tu n'a plus que du gloubiboulga

 

Dépêche toi donc de comprendre comment marche expeditor-inet, il est supprimé dans le mois prochain

 

 

Merci pour l'information. Pourriez-vous me préciser par quoi ce module est remplacé ? Avez-vous un conseil pour le choix d'un module ? Merci à vous.

[doekia]

Demande à ton commercial laposte

[unita]

Demande à ton commercial laposte

 

Merci pour le conseil, ils n'en savent rien, rien sur le site, aucun mail reçu...

 

Et je vous remercie pour le nom Bricolette...