Prestashop UPGRADE vers 1.6
Résolu/Fermé
jeapy06
Messages postés
1
Date d'inscription
mercredi 27 juin 2018
Statut
Membre
Dernière intervention
27 juin 2018
-
27 juin 2018 à 15:52
Nyctaclope Messages postés 5315 Date d'inscription dimanche 6 avril 2008 Statut Membre Dernière intervention 11 décembre 2022 - 28 juin 2018 à 16:36
Nyctaclope Messages postés 5315 Date d'inscription dimanche 6 avril 2008 Statut Membre Dernière intervention 11 décembre 2022 - 28 juin 2018 à 16:36
A voir également:
- Erreur 500 prestashop 1.6
- Erreur 0x80070643 - Accueil - Windows
- Erreur 500 - Guide
- Erreur 0x80070643 Windows 10 : comment résoudre le problème de la mise à jour KB5001716 - Accueil - Windows
- Formate pour taxer client 500€ ✓ - Forum Matériel & Système
- Erreur 1001 outlook - Accueil - Bureautique
1 réponse
Nyctaclope
Messages postés
5315
Date d'inscription
dimanche 6 avril 2008
Statut
Membre
Dernière intervention
11 décembre 2022
1 253
Modifié le 27 juin 2018 à 23:00
Modifié le 27 juin 2018 à 23:00
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
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
28 juin 2018 à 09:05
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
28 juin 2018 à 11:01
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
Modifié le 28 juin 2018 à 14:55
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
28 juin 2018 à 15:47
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
28 juin 2018 à 16:36
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