Requête qui liste les paniers en back office

[DavidCKW]

Bonjour,

J'utilise Prestashop 1.7.8.6 depuis plusieurs mois, et il est hébergé chez o2 switch, chez qui j'ai d'autres serveurs avec d'autres Prestashop qui tournent sans aucun problème. Depuis quelques jours, lorsque l'on veut accéder à la liste des paniers, on tombe directement sur une erreur 500. Les limites du serveurs ne sont pas du tout atteintes et lorsque je me mets en Mode Debug, ça ne change rien, et je ne voit pas la moindre erreur php ni erreur de requête. Je n'ai donc aucun moyen de savoir ce qui se passe. 

Lorsque je vide la table ps_cart, alors, la page s'affiche bien (vide) en back office. Mais je voudrais que ça fonctionne avec l'historique des paniers (l'historique n'est pas très gros, environ 10000 lignes). Je suppose une erreur dans la table panier, mais je n'arrive pas à l'identifier.

Quelqu'un saurait-il quelle est la requête (ou à quel en droit elle est dans els fichiers) qui est utilisée pour lister les panier depuis la back office ? Ainsi, je pourrai tester de jouer directement la requête dans phpmyadmin, pour voir s'il y a un problème avec la requête ou les données ?

Sinon, auriez-vous une autre idée, d'où pourrait venir le fait que cette page soit devenue inaccessible, et comment pourrais je comprend d'où vient le problème (j'ai tenté en vidant les caches, et en debug, et je ne vois aucune erreur php sur le serveur).

 

Merci d'avance pour votre aide à percer ce mystère.

 

Bien cordialement.

 

[Eolia]

Bug connu.

Une adresse liée à un panier a été supprimée.

Normalement le mode debug (ou le error.log du serveur) affiche bien l'erreur.

[DavidCKW]

Oui effectivement, je suis déjà tombé sur ce bug de panier lié à une adresse inconnue. Mais dans ce cas, le mode debug affiche la requête en erreur, on l'on peut voir le panier ou l'adresse incriminée. Là le mode debug ne m'affiche rien du tout, c'est ça qui me chagrine...

 

[DavidCKW]

Oui effectivement, je suis déjà tombé sur ce bug de panier lié à une adresse inconnue. Mais dans ce cas, le mode debug affiche la requête en erreur, on l'on peut voir le panier ou l'adresse incriminée. Là le mode debug ne m'affiche rien du tout, c'est ça qui me chagrine...

Et ce qui est fou et incompréhensible, c'est que des fois lorsque j'actualise cette page, je me retrouve sur le site en erreur 404 (au lieu de rester sur le back office). Pourtant, j'ai désactivé le filtre des cookies qui peut desfois faire des déconnexion intempestives. Et en fait, je ne suis pas vraiment déconnecté car quand je reviens sur une url / admin, je suis à nouveau sur le back office.

Si vous avez des idées...

 

 

 

[DavidCKW]

Réponse à moi même :

Je pensais qu'il y avait un problème sur la table ps_cart mais en recherchant la requête utilisée pour afficher cette page, quelle ne fut pas ma surprise de découvrir que cette requête faisait une jointure avec la table ps_connexion :

LEFT JOIN (
            SELECT DISTINCT `id_guest`
            FROM `' . _DB_PREFIX_ . 'connections`
            WHERE
                TIME_TO_SEC(TIMEDIFF(\'' . pSQL(date('Y-m-d H:i:00', time())) . '\', `date_add`)) < 1800
       ) AS co ON co.`id_guest` = a.`id_guest`';

 

Cette table étant traditionnellement trop monstrueuse, c'est tout simplement Prestashop qui n'arrivait plus à aller au bout de sa requête. Et c'est pour ça, que je ne voyait aucune erreur, mise à par un blocage pour ressources insuffisantes. Dès que j'ai fait le vide dans la table ps_connexion, alors d'un coup, je n'ai plus eu aucun problème pour afficher mon listing de panier en back office. Je savais que cette table pouvait être source de rpoblèmes, mais je n'avait pas pensé qu'elle était en lien avec l'affichage des paniers en back office.

Mon problème étant résolu, je vais ferme ce ticket. Merci quand même à Eolia, d'avoir soumis une réponse à mon problème.

[Mediacom87]

Vous comprenez pourquoi j'utilise régulièrement mon module pour effacer les données inutiles et alléger la base.

[Eolia]

Il y a 11 heures, DavidCKW a dit :

Réponse à moi même :

Je pensais qu'il y avait un problème sur la table ps_cart mais en recherchant la requête utilisée pour afficher cette page, quelle ne fut pas ma surprise de découvrir que cette requête faisait une jointure avec la table ps_connexion :

LEFT JOIN (
            SELECT DISTINCT `id_guest`
            FROM `' . _DB_PREFIX_ . 'connections`
            WHERE
                TIME_TO_SEC(TIMEDIFF(\'' . pSQL(date('Y-m-d H:i:00', time())) . '\', `date_add`)) < 1800
       ) AS co ON co.`id_guest` = a.`id_guest`';

 

Cette table étant traditionnellement trop monstrueuse, c'est tout simplement Prestashop qui n'arrivait plus à aller au bout de sa requête. Et c'est pour ça, que je ne voyait aucune erreur, mise à par un blocage pour ressources insuffisantes. Dès que j'ai fait le vide dans la table ps_connexion, alors d'un coup, je n'ai plus eu aucun problème pour afficher mon listing de panier en back office. Je savais que cette table pouvait être source de rpoblèmes, mais je n'avait pas pensé qu'elle était en lien avec l'affichage des paniers en back office.

Mon problème étant résolu, je vais ferme ce ticket. Merci quand même à Eolia, d'avoir soumis une réponse à mon problème.

Donc là c'est plutôt un souci serveur alors car je n'ai jamais rencontré ce problème (et j'ai des clients qui on leur table connections qui tourne depuis 2012...)

Le croisement ne se fait que sur les connexions de moins d'une demi-heure donc il doit manquer un index dans votre table.

[DavidCKW]

Bonjour Eolia,

Merci pour vos retours précieux et significatifs de votre engagement pour aider les gens, et c'est vraiment appréciable. Pour la table ps_connexion, à priori les index sont bons. Après, le site en question à un trafic assez élevé (en ce moment 20 000 connexions par jour de moyenne), peut être est-ce une raison. Sinon je vais voir côté serveur, ou avec la version de prestashop utilisé, s'il n'y a pas des améliorations à faire en cas de très grande table ps_connexion (ppour l'instant depuis que je l'ai vidée et qu'elle se reremplit, je n'ai plus eu de problème).

Passez une bonne journée