Installation » 

[FAQ] Problème de connexion à mon site Prestashop

Auteur
Message

Franck B.

Inscrit le : 04/12/2011

Messages : 458

Publié : 04/12/2011 12:09:21 "Citer"

Question fréquente de nos clients: Je n'arrive pas à me connecter à mon site Prestashop.
Voici la liste des problèmes connus et leur solution.

Franck B.

Inscrit le : 04/12/2011

Messages : 458

Publié : 04/12/2011 12:11:45 "Citer"

En premier lieu, lire ou relire le fichier lisezmoi.txt contenu dans le pack d'installation.
Comme l'indique ce guide, toujours commencer par installer le module de connexion. car quand vous aurez installé le module, en dessous du champ ou vous devez saisir une clé de cryptage, on vous redonne tous les paramètres pour réussir votre connexion. Vous ne pouvez pas ne pas y arriver en utilisant ces infos..

Erreurs fréquentes, causes connues et solutions:

  • Connexion ok, tout semble bon mais les tables restent vides:

-Mettre le répertoire /modules/sitologapplicationconnect (anciennement MPRApplicationsConnect) en 755 et son contenu en 644.
-Re-vérifiez le nom et le préfix de la base.
-Vérifiez que la valeur choisie pour id_lang correspond bien à une langue dans laquelle les noms des catégories et des produits sont documentés. Si vous avez un doute, mettre 0 dans ce champ (pour langue par défaut de votre boutique).
-Il est possible que votre serveur soit configuré avec des paramètres "mode security" qui bloque certaines requêtes envoyées par l'application. Pour contourner ce problème, cochez l'option "Cryptage des requêtes SQL avant envoi".

  • Les catégories s'affichent, mais pas les produits:

-Avez vous bien activé la liaison entre les deux tables, en cliquant sur le bouton représentant des engrenages ?
-Vieilles versions (avant V4): Case Prestashop version 1.4 mal cochée.
-Vérifiez que la valeur choisie pour id_lang correspond bien à une langue dans laquelle les noms des catégories et des produits sont documentés. Si vous avez un doute, mettre 0 dans ce champ (pour langue par défaut de votre boutique).
-Erreur très fréquente : n'avez vous pas laissé un pré-filtre activé sur la table des produits (champs au dessus de la table) ?
-Sur un hébergement OVH "Performance", essayez en désactivant le CDN.
-Le problème peut venir de "mode security" qui bloque certaines requêtes envoyées par l'application. Essayez en cochant l'option "Cryptage des requêtes SQL avant envoi", ce qui a pour résultat de contourner le Mode security.
Si le cochage de cette option bloque la connexion, il vous reste alors deux possibilités d'actions:
.Désactiver Mode Security via votre CPanel (ou demander à l'hébergeur de le faire pour vous ).
.Mieux mais infiniment plus technique, si cela vous est accessible, désactivez uniquement les règles de Mode Security qui bloquent l'affichage des produits, en analysant les logs du serveur . Voici par exemple un log montrant sur un serveur les deux règles de sécurité qu'il avait fallu désactiver pour corriger le problème:

ModSecurity: Access denied with code 403 (phase 2). Pattern match "(?:(?:alter|create|drop)[[:space:]].{1,100}(?:column|database|procedure|table) |delete[[:space:]] .{1,100}+ update [a-z0-9]+ set .{1,100}+=|union all select |bunionb.{1,100}?bselectb.{1,100}[a-z0-9]+ from |select (?:load_file|char ?()|(?:inse ..." at ARGS:requete. [file "/etc/apache2/modsecurity.d/rules/tortix/modsec/50_plesk_basic_asl_rules.conf"] [line "82"] [id "340144"] [rev "36"] [msg "Protected by Atomicorp.com Basic Non-Realtime WAF Rules: Generic SQL injection protection 2"] [data ""] [severity "CRITICAL"] [hostname "..."] [uri "/modules/sitologapplicationconnect/php4wduni.php"] [unique_id "WeXPrX......8AAAAE"]

ModSecurity: Access denied with code 403 (phase 2). Match of "rx (/install/index.php|/admin/fetch_data_af.php?action=create_txt_file_from_af_table$|/admin/structure/feeds/edit|^/([a-z]+/)?wp-admin/(?:admin|options-general).php?page=wpsc-settings)" against "REQUEST_URI" required. [file "/etc/apache2/modsecurity.d/rules/tortix/modsec/50_plesk_basic_asl_rules.conf"] [line "114"] [id "340159"] [rev "36"] [msg "Protected by Atomicorp.com Basic Non-Realtime WAF Rules: Generic SQL inline command protection (MM)"] [data "concat("] [severity "CRITICAL"] [hostname "..."] [uri "/modules/sitologapplicationconnect/php4wduni.php"] [unique_id "WeXQZX....mMAAAAO"]


  • Les catégories et les produits s'affichent, mais certains caractères (spéciaux, accentués,...) sont remplacés par des points d'interrogation (?) ou des caractère étranges:

-Si il s'agit du premier démarrage de l'application, de Merlin Backoffice en particulier, fermez complétement l'application et relancez la. Recommencez tant que le problème persiste.
-Si cela survient suite à une mise à jour de PrestaShop, désinstallez et réinstallez le module sitologapplicationconnect (anciennement MPRApplicationConnect)
-Si vous êtes en PS1.5 ou plus, ne cochez pas l'option "Forcer décodage et codage UTF8"
-Vérifier que le choix de l’alphabet est bien adapté aux caractères utilisés dans la langue par défaut
-Avant la version 6.1 de PP et 4.1 de PC, les module ne gèrent pas les bases codées en UNICODE. A partir de ces versions toujours choisir l'alphabet "UTF8 (UNICODE)"


  • Simple croix rouge, sans explication ou connexion ok de manière aléatoire. Et quand la connexion passe, on a rapidement ensuite des erreurs aléatoires, peut explicatives (une simple croix rouge, sans explication).

La croix rouge, sans plus d'info, signifie qu'une erreur SQL est arrivée, sans être due à l'applicatif.
On connait trois causes différentes:

1/Problème de stabilité de la connexion réseau, depuis le PC, jusqu'au serveur. Des time out ou des micro coupures de connexion arrivent de manière aléatoire, ce qui à pour effet de corrompre les requêtes SQL.
-Essayer depuis un autre PC et idéalement avec un autre câble réseau (pas de wifi)
-Regarder les logs coté serveur pour voir si il y a des micro coupures ou des time out.. Si c'est le cas, les résoudre avec l'aide de votre hébergeur.
-Vérifiez aussi que le paramétrage du serveur n'est pas trop restrictif sur le temps d'exécution et la longueur maximum des requêtes SQL.

2/Certains serveur sont protégés contre les attaques DDOS, via un firewall par exemple. Il arrive que ce type de protection fasse trop bien son travail et bloque également, de manière aléatoire, les requêtes SQL de notre application.
-2 choix possibles : mettre en veille la protection DDOS. Et en chercher une plus performante et paramétrable ou faire ajouter son IP adresse dans la liste blanche.
-Récemment (Q1 2018), un grand nombre d'utilisateurs hébergés chez O2Switch ont soudain eu ce problème, alors qu'il était absent auparavant. O2Switch affirme n'avoir rien changé dans leur réglages, mais ils ont confirmé que c'était bien leur Firewall qui bloquait la connexion pendant 10 minutes lorsqu'il confond les requêtes envoyé par PrestaPricing ou Merlin Backoffice, avec une attaque DDOS. Il suffit dans ce cas de fournir l'IP adresse (doit être fixe) de votre poste de travail à O2Switch et de leur demander de l'ajouter dans la liste blanche.

3/Certains anti virus comme Avira et Kaspersky, peuvent bloquer l’accès au réseau. Essayez dans un premier temps de désactiver la fonction "protection WEB ou WWW de ces anti virus", ou mieux excluez l'application de ce système de protection.

  • La connexion échoue (message d'erreur le signalant)

-Module de connexion (MPRApplicationsConnect auparavant, sitologapplicationconnect à présent) non ou mal installé ou trop ancien (toujours utiliser la dernière version disponible). Le désinstaller, le supprimer et le ré-installer.
-En particulier, il est très important de désinstaller le module de connexion avant de faire une migration de Prestashop et de le ré-installer sur la nouvelle version de PS. Ou de le ré-initialiser.
-Cas classique, mauvaise configuration du nom de domaine dans Prestashop. Chargez la page d'accueil du back office, si une erreur de configuration du nom de domaine est indiquée, corrigez la dans la page "préférences>SEO et URLs".
-Cas vicieux rencontré une fois, sur un Prestashop multi-boutiques : le module sitologapplicationconnect était installé et activé dans une seule des boutiques, et pas dans la boutique par défaut en particulier.
-URL incorrecte: Vérifiez l'url à saisir (fournie dans la fenêtre de configuration du module de connexion)
-En particulier en multi boutiques, bien mettre l'URL complet de la boutique par défaut. Si par exemple votre nom de domaine est http://mydomain.com et que vous avez trois boutiques et que l'adresse de celle par défaut est http://mydomain.com/shop1, c'est cette URL qu'il faut saisir.
-Ou si vous utilisez des sous domaines, inclure le sous domaine devant l'URL (même si le module sitologapplicationconnect ne l’inclut pas dans l'URL qu'il fourni.
-Avec Ps1.5 et + : ajoutez www. devant l'url fournie par le module ou au contraire retirez www. Cela peut être nécessaire lorsque votre domaine est redirigé.
-Clé incorrecte
-Le nom de la base contient des tirets (signe "moins"). Avec les anciennes versions de PrestaPricing et PrestaCatégories, mettre le nom de la base de données entre deux ` ` (ce n'est plus nécessaire avec les version de moins d'un an).
-Sur un serveur Linux, mettre le répertoire /modules/sitologapplicationconnect en 755 et son contenu en 644.
-Sur un serveur Windows, demandez à l'ingénieur système de donner des droits d'accès équivalent à ces dossiers et fichiers.
-Désactivez la protection web de votre anti-virus, ou mieux excluez l'application de ce système de protection.
-Si vous êtes sur un MAC, avec une émulation de Windows, vérifiez aussi que ce Windows à bien accès au réseau du MAC.
-Nouveau cas très technique apparu à partir de la version 6.0 et surtout sur la 6.1.1 et les beta jusqu'à la 6.1.3 incluse : certains serveurs exécutent mal les ordres PHP du type mb_ nécessaires pour le décryptage unicode des requêtes envoyées cryptées. Bref, ça refuse de se connecter (même en mode "non cryptées" qui n'agissait que sur les données descendantes) et il est très difficile de deviner ce qui se passe. Ce type de problème est à présent résolu à partir de la version beta 6.1.4 et le module de connexion en version 4.6.a, en choisissant le mode "Ni cryptées ni compressées" ou le mode "Compressées mais pas cryptées", qui évitent à présent le cryptage des requêtes montantes..
-Si dans la fenêtre jaune (visible si l'option "Tracer" est cochée), il est indiqué que le script php4wduni.php n'a pas été trouvé, cela indique que le module connecteur est encore dans une ancienne version (plus ancienne que 7.2.a), le mettre à jour.
-Un autre cas complexe apparu récemment : si des messages d'erreur SQL apparaissent, parlant de sql_mode, il faut la aussi mettre à jour le module connecteur et si le problème persiste, aller modifier les réglages de votre serveur SQL (via le PHP.INI par exemple, ou demander à l'hébergeur de le faire), pour affecter la valeur vide ("") au paramètre serveur sql_mode.
-Si votre serveur Apache est configuré sur PHP 7.0 ou ultérieur et que la trace de connexion indique une erreur 500, il est fort probable que le problème de connexion vienne du fait que l'extension PHP mysqli n'est pas activée. Deux solutions dans ce cas: Soit activer mysqli via le Cpanel de votre hébergement, soit mettre à jour le module connecteur en version 7.2.c minimum, qui supporte le protocole DPO (activé par défaut sur PHP 7.x).
-Récemment (Q1 2018), chez l'hébergeur Yoorshop, le passage à PHP7 a aussi provoqué des problèmes de connexion chez nombre d'entre vous. Encore une histoire de mysqli et nd_mysqli mal configurés de leur coté à cause de CloudLinux. Les contacter ils sauront quoi faire.
-Demandez à votre hébergeur ou Webmaster si a été mis en place une protection HTTPAcces (peut générer des message d'erreur du type "Authentification required..."). Si c'est le cas, demandez le nom d'utilisateur et le mot de passe nécessaires pour passer cette protection et les saisir dans les deux champs "Utilisateur HTTP" et "Mot de passe HTTP" dans la fenêtre de connexion.

  • Problèmes typiques chez OVH (serveurs mutualisés)

-Par défaut, OVH donne un droit d'acces 705 au répertoire /modules/sitologapplicationconnect. Cela n'est pas suffisant pour se connecter, il faut le passer en 755
-Quand on le passe en 755 avec Filezilla, tout semble pris en compte, mais souvent chez OVH, ce n'est pas le cas. Si on regarde de nouveau le droit d’accès du dossier il est toujours en 705. Je ne sais pas si c'est une protection ou un bug. Heureusement il existe une astuce : sélectionnez le dossier /modules/ et changer les droits en 755 de manière récursives de tous ses sous répertoires. C'est un peu long mais ça fonctionne.
-Depuis peu, OVH propose souvent des SQL privés, dont l'adresse complète contient un numéro de port, comme (un chiffre placé après un "deux points") . Les versions avant la 4.6.e de sitologapplicationconnect ne tenaient pas compte du numéro de port et ne permettent donc pas la connexion. Upgradez ce module en 4.6.e ou ultérieur.

  • La recherche de connexion http reste bloquée de longues minutes, puis un message d'erreur indiquant que le serveur n'a pas répondu (time out) apparaît.

-Vérifiez l'URL.
-Essayez avec et sans www.
-Cas de plus en plus fréquent: Il s'agit d'un blocage de l'accès réseau sortant par l'antivirus ("Protection WEB"). Assez classique avec Avira et AVG. Désactivez la protection web de ce dernier, ou mieux excluez l'application de ce système de protection.
-Si l’adresse du serveur SQL contient un numéro de port (finit par deux point et un numéro), il est nécessaire d'utiliser la version 4.6.e ou ultérieure du module sitologapplicationconnect.

  • La vérification de la licence échoue après une vingtaine de secondes, puis la connexion à votre serveur échoue également. Cela indique soit que le PC est sans réseau, soit que le logiciel n'a pas accès au réseau.

-Vérifiez votre connexion réseau.
-Si possible passez en réseau filaire (jusqu'à 5x plus rapide ensuite)
-Si votre box ou votre réseau local intègre un serveur Proxy, configurez l'onglet "Proxy" de l'application avec le user et mot de passe de ce proxy (voir ci dessous).
-Fermez l'application et relancez la, mais cette fois en tant qu'administrateur (clic droit sur l'icône, puis choisir "Exécuter en tant qu'administrateur")
-Voir aussi cet article dédié au problème de vérification de la licence.

  • Erreur fatale ligne 35...

-Re-vérifiez le nom et préfix de la base

  • Message d'erreur "Error: PS version cannot be read" ("Erreur: Le numéro de version de Prestashop n'a pas été trouvé dans la base.)

Causes possibles :
-A peu près tous les autres cas évoqués plus haut peuvent aboutir à cette erreur.
-Mauvais paramètres saisis, comme l'e-mail et mot de passe de connexion au back office.
-Mauvaise installation du module de connexion (il doit rajouter le numéro de la base dans la table « configuration »)
-Un pare feux coté serveur empêche l'accès à la base.
-Un cas classique, sur une plateforme PS1.5 et +, en multi-boutiques: Vérifiez que l'alias de l'URL de la boutique principale, déclarée dans les paramètres multi-boutiques du back office, pointe bien vers le vrai non de domaine du "site" (même nom de domaine que pour le back office).
Sinon, lorsque PrestaPricing/PrestaCatégories/AutoPresta essaient de se connecter en appelant un script PHP du module sitologapplicationconnect (anciennement MPRApplicationConnect), Prestashop redirige (via l'alias) l'URL et le script n'est pas trouvé. La connexion est indiquée comme réussie dans la fenêtre de log, mais elle échoue au moment de lire la table 'Configuration".
-Nouveau cas très technique apparu à partir de la version 6.0 et surtout sur la 6.1.1 et les beta jusqu'à la 6.1.3 incluse : certains serveurs exécutent mal les ordres PHP du type mb_ nécessaires pour le décryptage unicode des requêtes envoyées cryptées. Bref, ça refuse de se connecter (même en mode "non cryptées" qui n'agissait que sur les données descendantes) et il est très difficile de deviner ce qui se passe.
-Version trop ancienne du module sitologapplicationconnect.

Solutions:
-Vérifiez l'e-mail et mot de passe de connexion au back office.
-Désinstallez, SUPPRIMEZ LE REPERTOIRE sitologapplicationconnect, et réinstallez le module de connexion V4.6.a (ou plus récent), configurez. Ré-essayez.
-Vérifiez que la table configuration de votre base de données contient bien une ligne nommée "MPR_PS_Version" et ayant pour valeur la version de votre Prestashop, 5 chiffres sans les "points. Exemple 14510 pour la version 1.4.5.1. Si ce paramètre n'est pas présent, le rajouter manuellement.
-En particulier avec PS1.5: Rajoutez ou au contraire retirez www. devant l'url fournie par le module. Cela peut être nécessaire lorsque votre domaine est redirigé.
-En multi boutiques, bien mettre l'URL complet de la boutique par défaut. Si par exemple votre nom de domaine est http://mydomain.com et que vous avez trois boutiques et que l'adresse de celle par défaut est http://mydomain.com/shop1, c'est cette URL qu'il faut saisir.
-Vérifiez aussi les droits d'accès aux dossiers, comme expliqué un peu plus haut.
-Si cela survient suite à une mise à jour de PrestaShop, désinstallez et réinstallez le module sitologapplicationconnect.
-Nouveau cas à partir de la version 6 et du passage à l'UNICODE. Pour utiliser le mode "Données cryptées", il faut que le module PHP "mbstring" soit activé sur le serveur (voir ici : http://php.net/manual/fr/mbstring.installation.php)
-Passez à la version beta 6.1.4 et le module de connexion en version 4.6.e, en choisissant le mode "Ni cryptées ni compressées" ou le mode "Compressées mais pas cryptées", qui évitent à présent le cryptage des requêtes montantes..

  • Message d'erreur "Erreur SQL "SET NAMES_UTF8..."

Causes possibles :
-Problème d’accès à la base du fait d'un mauvais paramétrage du fichier setting.inc.php dans le dossier config de PrestaShop. Pour le paramètre Host, remplacez localhost par l'address IP locale du serveur SQL (souvent 127.0.0.1)


  • Message d'erreur "SQL Error "Check your syntax near SHOW TABLES ..."

Cause possible : Problème de cryptage ou décryptage des requêtes.
Solution: Remplacer la clé de cryptage par une autre valeur (coté module de connexion et coté application), en respectant bien les consignes fournies concernant le nombre de caractères et les caractères autorisés.
Essayez avec la valeur par défaut (AABBCC...HH)

  • Cas assez rare: Si votre serveur demande de s'identifier pour accéder aux pages, avec un nom d'utilisateur et un mot de passe http, il faut préciser ces paramètres à PrestaPricing ou PrestaCatégories.

Avant les versions 5 et 3 respectives, ceci ce fait en remplaçant l'URL par cette chaine de caractères: utilisateur:motdepasse@URLsanshttp

Ex, si l'url donnée par le module de connexion est http://mondomaine.com/boutique/, que mon logon est Toto et le mot de passe est monpass, saisir:
toto:monpass@mondomaine.com/boutique/

Dans les versions actuelles, la fenêtre de connexion est enrichie de deux nouveaux champs, permettant de rentrer l'utilisateur et mot de passe http éventuels. Donc plus besoin de modifier l'URL.

  • Connexion internet passant par un serveur Proxy

Si votre connexion internet est réalisée au travers d'un serveur Proxy, vous pouvez configurer nos applications pour établir automatiquement la connexion. Pour ceci, simplement remplir les paramètres demandés (adresse du serveur proxy, loggin...) dans l'onglet Proxy de la fenêtre de connexion.

  • Erreur SQL concernant id_tax

Cela peut se produire après avoir changé de version de Prestashop, sans avoir désinstallé au préalable le module de connexion. Le désactiver, le désinstaller, le supprimer et le réinstaller complétement.

  • Erreur serveur 500

-Problème de droits d'accès au dossier du module de connexion (voir plus haut)
-Désactiver le mode safe_mode dans le panneau d'administration du serveur.

  • Echec de connexion sur un serveur local (avec EasyPHP par exemple)

Selon la configuration de Easy PHP, il faut parfois rajouter le numéro du port dans l'URL fournie par le module.
Ex:
Le module sitologapplicationconnect vous indique d'utiliser cette URL: www.mondomaine.com/mondossier/
Utilisez à la place www.mondomaine.com:8080/mondossier/ (si 8080 est le port utilisé par EasyPHP)

  • Sur un serveur Prestabox, impossible d'installer le module de connexion

Il n'y a pas de solution connue (hormis passer par "Modules Manager", autre module qui n'est plus installable non plus, mais l'était à une époque en passant par les thèmes), Prestashop a blindé cette solution, pour empêcher toute installation de modules non inclus par défaut dans leur offre.
No comment.
Pourtant, nous avons pu le vérifier sur un Prestabox équipé de "Modules Manager", PrestaPricing fonctionne très bien sur cette plateforme, une fois installé.

  • Erreur à la ligne 18 du traitement Méthode URLDecrypte.
    Vous avez appelé la fonction Caract.
    Le code ASCII spécifié (-83) est invalide. Il doit être compris entre 0 et 255.

Deux causes connues:
-Fichier ovhconfig.php, forçant l'activation de php en 5.5 qui plante. Repasser en PHP 5.4 résout le problème.
-Le message d’erreur indique une difficulté du serveur à crypter / décrypter les données.
Dans ce cas de figure, essayez dans un premier temps de simplement modifier la clé de cryptage, dans le module MPR et dans PrestaPricing. Essayez par exemple avec la valeur par défaut AABBCCDDEEFFGGHH.

  • A partir de la version 1.6.0.13 de Prestashop, plantage de la page "Modules" dans le back office, indiquant que le nom du module MPRApplicationConnect est incorrect.

Cela est du au fait qu'à partir de cette version de PS, les noms des modules ne doivent pas contenir de lettre majuscule.
Le module MPRApplicationConnect n'est donc plus compatible. Je l'ai remplacé par le module sitologapplicationconnect qu'il faut installer à la place.
Pour fonctionner avec ce module, j'ai recompilé et mis en ligne de nouvelles versions de PrestaPricing (6.0.6), PrestaCatégories (4.0.4) et AutoPresta (2.5.0).
Attention, la rétro compatibilté n'a pas pu être conservée. Les anciennes versions de ces modules ne peuvent pas être utilisés avec ce Prestashop et les suivantes à venir.

  • Impossible d'installer le module MPRApplicationConnect ou son remplaçant sitologapplicationconnect dans le back office de Prestashop CLOUD.

C'est normal car ces modules ne sont pas disponibles sur PrestaAddons.
Mais ce n'est pas un problème, car depuis la version 4.2 de ces modules, ils n'ont plus besoin d'être installés pour fonctionner. Lire ou relire le guide d'installation lisez-moi.txt fourni avec votre application.

  • La connexion se passe bien, mais au moment d'ouvrir la fenêtre principale l'application plante après avoir indiqué qu'il manque l'éditeur HTML CKEditor.

Installez la dernière version du module connecteur, c'est lui qui fournit cet éditeur.
Cochez l'option "HTTPS" (la décocher si cela empêche la connexion). Saisir éventuellement le info de login HTTPS dans les paramètres avancés.

Franck B.

Inscrit le : 04/12/2011

Messages : 458

Publié : 07/05/2012 10:26:01 "Citer"

Quote André :
J'ai ce message d'erreur lorsque j'essaie de me connecter: Une croix rouge me disant que la connexion est impossible et que je dois vérifier la version du module MPR


Problème résolu, il s'agissait simplement d'une erreur de frappe d'un des paramètres (nom de la base de données).

Je me permet donc de redonner le conseil déjà avancé plus haut: Pour éviter les erreurs de saisie des paramètres (URL, nom et préfixe de la base de données, clé de cryptage), faire simplement des copiers-collers de ceux-ci depuis la fenêtre de configuration du module MPRApplicationConnect, vers les champs de PrestaPricing, PrestaCatégories ou AutoPresta.

90% des problèmes de connexion qui me sont remontés sont en effet résolus de cette manière, car dus à une erreur de frappe.
6% sont résolus en changeant les droits d’accès du répertoire MPRApplicationConnect en 755 (si vous êtes chez OVH)
3% en mettant le nom de la base de données entre deux ` (PrestaCatégories uniquement)
1% seulement des cas ont une autre cause.

Franck

Franck B.

Inscrit le : 04/12/2011

Messages : 458

Publié : 27/07/2012 18:24:26 "Citer"

Quote Alexandre B. :
Bonjour,

je viens de télécharge le logiciel et j'ai suivi pas à pas votre tutoriel. Malgré cela, je suis toujours dans l'impossibilité d'utiliser prestapricing. Voici ce qu'il me dit:

Quelqu'un peut-il m'aider?

Merci d'avance


Bonjour,

Cette erreur est causée par une incoherence dans la base de données, comme une catégories sans parent. Cela peut se corriger avec prestacategories.
Avec un clic droit sur la ligne des titres des colonnes, faites apparaître les colonnesid parent et niveau et vérifiez et corriger leur valeur si qcq chose estincoherent.
Ou m'appeler des mon retour dimanche ou lundi,pour que je corrige votre base pour vous.

Crdlt
Franck

Franck B.

Inscrit le : 04/12/2011

Messages : 458

Publié : 02/08/2012 10:12:07 "Citer"

Quote Moïse M. :
Bonjour, je suis chez ovh en mutu....j' ai installé desinstallé réinstallé trois fois le module verifié reverifié la syntaxe des parametres de connexion .....impossible de me connecter à ma BDD avec le client ....
j' ai ce message d' erreur :
22:44:56:62 SQLError: SQL: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SHKaWnZt]~Y€dc&d`xeal~_folX' at line 1SHKaWnZt]~Y€dc&d`xeal~_folX
A l' aide svp !


Moïse, ce type d'erreur est typique d'une erreur de saisi ou de choix de la clé de cryptage, dans la page de configuration du module MPRApplicationConnect (backoffice, onglet modules, autres modules).
Petit rappel des consignes:
-Minimum 12 caractères
-Maximum 16 caractères
-Tout en majuscules
-Que des lettres, pas de chiffre
-Aucun caractère spécial, tiret, accent...
-Aucun espace

[Edit]Moïse à modifié sa clé et le problème est corrigé.

Luc A.

Inscrit le : 16/01/2015

Messages : 1

Publié : 02/03/2015 22:42:45 "Citer"

Hello, depuis que j'ai installé la nouvelle version de prestashop PAF voilà les erreurs que j'ai.... Est ce quelqu'un peut m'aider

sinon je vais devoir ré installer l'ancien version pfffff

Franck B.

Inscrit le : 04/12/2011

Messages : 458

Publié : 03/03/2015 10:36:17 "Citer"

Bonjour Luc,

Ces erreurs, spécifiques à la version 1.6.0.13 de Prestashop, sont dues au fait que Prestashop à changé les rêgles concernant les noms des modules.

J'ai travaillé dessus tout le week end et ai mis en ligne hier une nouvelle version de PrestaPricing, PrestaCatégories, AutoPresta compatibles avec ce PS.

Pour cela, j'ai du aussi renommer le module MPRApplicationConnect. Il faut le désinstaller (ou supprimer toute trace de ce module dans la table "ps_modules" de la base) et supprimer ce dossier, puis installer à la place le nouveau module sitologapplicationconnect (fourni avec les nouvelles versions).

Crdlt
Franck

Fabrice B.

Inscrit le : 13/07/2014

Messages : 4

Publié : 07/03/2015 16:40:15 "Citer"

Bonjour

Vous parlez de l'erreur un peu plus haut :

Mais je ne peux pas lancé le logiciel prestapricing et catégories

Que puis je faire ?

Voici le message


Erreur à la ligne 18 du traitement Méthode URLDecrypte.
Vous avez appelé la fonction Caract.
Le code ASCII spécifié (-65) est invalide.
Il doit être compris entre 0 et 255.

Fabrice B.

Inscrit le : 13/07/2014

Messages : 4

Publié : 07/03/2015 16:41:57 "Citer"

PS : j'ai bien mis en place les nouvelles versions

Fabrice B.

Inscrit le : 13/07/2014

Messages : 4

Publié : 07/03/2015 16:46:39 "Citer"

version PHP PHP: Version 5.5.9-1ubuntu4.6

Mais je ne peux pas changer le php

Franck B.

Inscrit le : 04/12/2011

Messages : 458

Publié : 07/03/2015 18:55:11 "Citer"

Bonjour Fabrice,

Votre serveur ne supporte pas le mode "crypté". Dans ce cas de figure, passez le niveau d'interface en "complète" et choisir l'option "Compressées mais non cryptées" ou encore "Ni encryptées ni compressées".

Si cela ne fonctionne toujours pas, m'appeler.

Crdl
Franck

Fabrice B.

Inscrit le : 13/07/2014

Messages : 4

Publié : 07/03/2015 23:00:57 "Citer"

Merci bcp tous fonctionne bien et bravo pour vos logiciel

Franck B.

Inscrit le : 04/12/2011

Messages : 458

Publié : 17/03/2015 15:53:29 "Citer"

Bonjour Fabrice,

Désolé pour cette réponse tardive (pour un support instantané je recommande encore une fois de mon contacter par tchat, mail ou tel, le forum est plus adapté aux questions génériques qu'aux cas particuliers).

Ce message indique que la fonction de cryptage des données ne fonctionne pas avec votre serveur. Essayez dans un premier temps avec une autre valeur pour la clé de cryptage et si cela ne change rien, choisir un des deux autres modes proposés, comme "Compressées mais non cryptées".

Crdlt
Franck

Franck B.

Inscrit le : 04/12/2011

Messages : 458

Publié : 25/05/2015 11:56:47 "Citer"

Pour info, la dernière version de PP (6.6.1) et de PC (4.1.1), avec leur module sitologapplicationconnect en version 4.5.e sont compatibles avec les dernières versions de PHP (utilisent l'API MySQLi_).

Si vous avez un soucis de connexion malgré cela, merci de me contacter en privé pour une séance de support avec partage d'écran.

Crdlt
Franck

Navid A.

Inscrit le : 07/05/2015

Messages : 1

Publié : 17/03/2016 19:52:38 "Citer"

How to connect PrestaPricing/PrestaCategories to IP address?

In a temporary e-commerce, without the domain, I needed to use the IP address to connect PrestaPricing.
In the URL box, I typed 212.239.234.142 but it did not work... PrestaPricing didn't like it!!
My temporary shop doesn't have a URL htttp:www.myshop.com but just an IP address, but PrestaShop can not connect to the PrestaShop e-commerce with the IP address only.

The solution is to cheat PrestaPricing by changing your hosts file, here is a explanation how to modify your hosts filehttps://support.rackspace.com/how-to/modify-your-hosts-file/ (remember to open the editor as administrator).

Now back to PrestaPricing, add normally the domain name in the URL box .... et voilà...you are connected!!

good luck
Navid

Franck B.

Inscrit le : 04/12/2011

Messages : 458

Publié : 17/03/2016 20:43:49 "Citer"

Thank you Navid for sharing this alternative solution.

As mentionned to you, on my side it did not need to edit the host, it did work with IP addresses exactly like with an url.

It even works from a Windows session using Parallels Desktop on a MAC, to connect to a site installed in the virtual Apache server of the same MAC. In such case I use the IP address of the MAC itself.

But your solution is worth trying for all others having difficulties to make it works natively.

Rgds
Franck

Jonathan R.

Inscrit le : 02/06/2014

Messages : 1

Publié : 16/11/2018 19:19:18 "Citer"

Bonjour,

Nous avons une ancienne version de Prestashop (1.6.0.6) ainsi que de prestasPricing (5.4.1.d).
Le serveur était sous PHP 5.4. Nous avons changé de serveur avec un PHP 7.0.26.
Prestashop fonctionne bien mais impossible de reconnecter PrestaPricing.

Nous avons le msg suivant :

Quote :

19:17:03:83 Préparation des variables
19:17:03:83 Définition préfixe table
19:17:03:96 Vérification de la validité de la licence terminée, validité=1.
19:17:03:97 Connexion SQL
19:17:03:97 SQLError:Le serveur ne répond pas. Y a-t'il un serveur HTTP sur la machine cible ?Un problème a été détecté pendant l'envoi d'informations sur la socket.


Avez-vous une idée du blocage ?
Bien cordialement,
Bertrand


Recherche dans le blog

PayPal