Prestashop UPGRADE vers 1.6 [Résolu]

Prestashop UPGRADE vers 1.6 [KERNEL] Failles découvertes MAJ vers 2.6.16 (Résolu) » Forum - Mandriva / Mageia Upgrad vers win7 (Résolu) » Forum - Windows 7 Upgrade vers cette autre config utile ou pas (Résolu) » Forum - Matériel informatique Mozilla Firefox mise a jour vers 3.6.4 [Résolu] (Résolu) » Forum - Logiciels Mise à niveau 10.4.11 vers 10.6 (Résolu) » Forum - MacOS

Bonjour,
Après avoir upgradé Prestashop de la v. 1.5 vers la v. 1.6 au moyen du module 'one click Upgrade' un bug s'est créé. Ouverture du site (en front office) IMPOSSIBLE affichant une erreur 500, laquelle serait vraisemblablement consécutive à une requête SQL non aboutie qui est : Unknown column 'a.id_employee' in 'on clause'
J'ai noté que ce bug était récurrent dans la procédure d'upgrade. Mais je n'ai pas trouvé de réponse sur les forums ...
Je ne sais pas dans quelle(s) table(s) de la base SQL se situe le JOIN et quel script SQL lancer pour fixer le pbm.
Merci d'avance pour votre aide.

Forum

Prestashop UPGRADE vers 1.6 [KERNEL] Failles découvertes MAJ vers 2.6.16 (Résolu) » Forum - Mandriva / Mageia Upgrad vers win7 (Résolu) » Forum - Windows 7 Upgrade vers cette autre config utile ou pas (Résolu) » Forum - Matériel informatique Mozilla Firefox mise a jour vers 3.6.4 [Résolu] (Résolu) » Forum - Logiciels Mise à niveau 10.4.11 vers 10.6 (Résolu) » Forum - MacOS

Web: www.shapebootstrap.net

6 réponses

Marsh

NOVEMBER 9, 2013 AT 9:15 PM

Bonsoir,
Le problème sous prestashop, c'est qu'aucune version n'est terminée et debuggée avant de passer à la suivante.
Personnellement, je suis résolument resté à la version 1.4.9, qui fonctionne à peu près, sans jamais céder aux sirènes du "version stable disponible xxx ".
Je ne sais si je pourrais répondre à ta demande de façon satisfaisante .

Le "JOIN" n'est pas une donnée dans une base sql, c'est un opérateur à insérer dans une requête sql qui cherche des données associées dans plusieurs "tables", le "JOIN" faisant liaison entre deux identifiants ( de même "valeur" dans deux tables différentes )
Ici, il semble qu'une requête ( je pense que tu ne la retrouveras jamais ) n'a pas trouvé de champ ( colonne ) nommé 'a.id_employee' ( code d'identification de "l'employé" à savoir l'un de ceux qui peuvent gérer le back-office )
Manifestement, il y a une erreur d'orthographe quelque part , le champ est évidemment "id_employee" que tu trouveras certainement dans la table "employee(s??)" de ta base.
Peut être qu'y créer un champ fictif 'a.id_employee' de même type que 'id_employee' résoudrait l'erreur en lui donnant de quoi "manger" le temps de l'update ..

Si tu peux accéder directement ( j'espère que oui ! ) au back-office comme admin, va à l'onglet "employés" où tu devrais déjà figurer en tant qu'administrateur, voir si tu n'y trouves pas un employé fictif fabriqué par l'update, nommé par exemple "John Doe", et tu le vires. Prends garde à ce qu'il reste au moins un employé administrateur, ou inscris toi au minimum ! ..

Va voir également à l'onglet "préférences", vérifier que ton site est bien activé ( Activer la boutique = oui ),
et profite-s-en pour inscrire ton IP à la rubrique voisine "IP de maintenance", cela devrait te permettre d'accéder quand même au front office, même en maintenance, ou même si bloqué ( du moins je l'espère ).

Quant à l'erreur 500, de mémoire il me semble que cela signifie que le serveur a rencontré une erreur inconnue. C'est fréquent dans prestashop, et très frustrant. De mémoire j'ai réussi à la contourner ( sans la résoudre ) en déroutant dans .HTACCESS l'erreur 500 vers une page 500-perso.php, qui je crois m'en souvenir renvoit vers la page précédemment visitée avant l'erreur ( je n'ai pas ici la possibilité d'aller voir le code que j'y ai écrit ).

Les infos données ici correspondent à ma version, il est possible qu'il y ait de petites différences, mais tu devrais pouvoir te débrouiller, du moins je l'espère ..

Quant au forum Prestashop, il résonne comme un appartement désespérément vide, mais de temps en temps cela marche ...

A+
Nyctaclope

Reply
réponses:
  • auteur

    Bonjour Nyctacope,
    Je te remercie d'avoir pris le temps de me répondre aussi largement. Je savais effectivement que le JOIN est un code qui lit diverses tables d'une base par rapport à des variables communes (tables liées). Tu as raison, je vais renommer la variable 'a.id_employee' en alias "raccourci" pour tester la requête SQL 'mauvaise) qui bloque le serveur par une base SQL instable.
    Pour le coup, même si je repointe la page 500 intégrée vers une page customisée 800-perso.php, étant donné que le site n'ouvre pas en front office, je n'aurai pas de changement.
    L'upgrade a été obligée à cause des nouveaux moteurs de PayPal (TLS2) sans quoi on ne peut plus utiliser ce module de paiement.
    La boutique s'ouvre parfaitement bien "en maintenance" preuve que le site upgradé est stable.
    Le pbm vient d'une ou plusieurs tables de la table SQL corrompue(s).
    Merci encore pour ton intervention.
    @+
    Jeapy06

  • Nyctaclope

    Re
    Peut être suffisait-il de simplement changer le module Paypal dans la version précédente ?
    J'ai déjà eu deux fois le problème quand Paypal a modifié ses protocoles.
    Il faut quelquefois patienter quelques semaines avant qu'une maj convenable du module paypal soit proposée dans addons.prestashop.com ..
    Sinon, peut être qu'une mise à jour manuelle fonctionnerait mieux que l'automatique, mais il faut reconnaître que c'est quelquefois la galère, avec le nettoyage que l'on doit faire ensuite sur les produits et commandes fictives rajoutés dans la base ..
    Egalement jeter un oeil dans le dossier "override", il se peut que le correctif soit déjà disponible, mais non activé, comme souvent ..
    Je te souhaite bon courage ! ..
    A+
    Nyctaclope

  • Nyctaclope

    Encore moi ..
    En récupérant les fichiers de ton site par ftp vers ton PC, il y a un excellent utilitaire ( grep windows ) qui te permet de rechercher une chaine ( par exemple 'a.id_employee' ) dans un groupe de dossiers de fichiers.
    https://windows-grep.en.uptodown.com/windows/download
    Il y a également Agent Ransack
    Evidemment cela mouline un certain temps, mais c'est efficace ..
    Tu devrais pouvoir trouver la requête ou le fichier fautif .. Après il faut interpréter ..
    id_employee devrait être localisée facilement, mais peut être pas a.id_employee si c'est obtenu quelque part par concaténation de chaines.
    Il me semble qu'il existait un dossier "sql", à ratisser en priorité, mais pas pu remettre le doigt sur son emplacement.

    Par ailleurs, si tu as accès au fichier .log de ton serveur , avec ton IP et la minute exacte de connexion au front office, tu devrais pouvoir identifier la page ayant provoqué l'erreur 500. Il faut bien sur que tu désactives d'abord momentanément ton IP de maintenance, pour que cela coince effectivement ..
    Il y a aussi les divers fichiers error.log de phpmyadmin et autres ..

    A+
    Nyctaclope

  • auteur

    Nyctaclope,

    Sympa de ta part de nous aiguiller sur plusieurs pistes.

    En fin de compte, on a fini par résoudre le pbm >> En fait un simple module, arrivé "automatiquement" lors de l'upgrade >> 1.6 sur l'ale site, a cré un conflit donc erreur 500.
    Donc après avoir testé les modules / Prestashop un par un et donc identifié ce module conflictuel, on l'a désactive et la boutique s'affiche désormais bien en front.

    Pour le nouveau protocole PayPal (TLS 1.2) qui sera impératif le 30 juin prochain, une fois le certificat SSL du serveur activé, on a configuré le TLS 1.2 / Paypal pour éviter tout blocage dès le 30/06.

    Merci encore pour tes suggestions toujours bonnes à savoir ...
    @+
    Jeapy06

  • Nyctaclope

    Parfait ! Heureux pour toi ..
    Et bonne route ..
    Peut être, pour d'autres lecteurs, mettre ton post en résolu ? cela se fait en revenant sur ton post initial ..
    A+
    Nyctaclope

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed