Forum sur l'installation du module PrestaShop PrestaPricing »
[FAQ] Problème de connexion à mon site Prestashop
| Auteur | Message |
|---|---|
|
Sitolog Inscrit le : 04/12/2011 Messages : 524 |
|
|
Sitolog Inscrit le : 04/12/2011 Messages : 524 |
-Merlin indique que la licence n'est pas valide. Cela peut se produire lors de la 1ere connexion alors que la licence est parfaitement valide. Fermez et redémarrez Merlin pour corriger ce problème. -Module de connexion (MPRApplicationsConnect auparavant, puis sitologapplicationconnect et à présent sitologconnector) 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 sitologconnector é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 sitologconnector ne l’inclut pas dans l'URL qu'il indique. -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é de cryptage saisie incorrecte (particulièrement sensible lorsque l'on change de version du connecteur). Il peut arriver que plusieurs valeurs différentes de clé soient stockées dans la base. Essayez avec la valeur par défaut AABBCCDDEEFFGGHH, mais aussi avec votre valeur perso si vous l'aviez déjà changée, même si le connecteur vous indique qu'il voit la valeur par défaut. -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/sitologconnector 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. -Sous linux, il peut aussi arriver que le propriétaire de ce même dossier ne soit pas le bon. Il faut dans ce cas utiliser la commande linux "chown -R nomuser nomdossier" pour lui attribuer un propriétaire ayant suffisamment de droits d'accès. -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. Il peut être utile de redémarrer le MAC pour résoudre ce problème. -Nouveau cas très technique apparu à partir de la version 6.0 et surtout sur la 6.1.1 et les béta jusqu'à la 6.1.3 incluse, puis de nouveau avec Merlin à partir de la 1.4 : 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 avait été 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. Cette option n'étant plus possible avec Merlin 1.4 pour des raisons de sécurité, le problème ne peut être corrigé qu'en demandant à votre Webmestre d'installer le module PHP mbstring. -Si dans la fenêtre jaune (visible si l'option "Tracer" est cochée), il est indiqué que le script php4wduni.php ou query.php n'a pas été trouvé, cela indique que le module connecteur est encore dans une ancienne version (plus ancienne que 8.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). -Depuis 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. -Attention aussi à la version PHP. Au 21/01/2021 (version 1.5.1 de Merlin avec connecteur version 8.2), la compatibilité est assurée jusqu'à PHP 7.2, pas au delà (ni PHP7.3 (ça peut fonctionner parfois cependant), ni surtout PHP 7.4). PHP 7.4 génère une erreur 500 au moment de la connexion. -Si il s'agit du connecteur 10.0.6, après l'avoir installé, faites juste un clic sur la fonction "Réinitialiser" du module connecteur, depuis la page listant les modules dans le BO. Une nouvelle clé va être générée, mettez la dans Merlin et normalement ça fonctionne. C'est du à un fonctionnement étrange de PS qui n'exécute plus le script d'installation du module si une ancienne version n'est pas désinstallée avant . Et la version 10.x du connecteur a vraiment besoin que son script d'installation soit lancé. Ce que fait la fonction "Réinitialiser. -Si le site est en maintenance, à partir des versions 10.x du connecteur, encore plus sécurisé, la connexion n'est possible que si votre IP a été autorisée, dans le back office de PS, page de gestion du mode de maintenance. -Une échec de connexion peut aussi avoir pour cause un certificat SSL invalide ou mal installé. Pensez à vérifier et valider la configuration SSL coté hébergement. -Certains prestataires ou hébergeurs peuvent interdire le format par défaut des urls utilisées par Merlin Backoffice pour échanger avec son connecteur ( https://www.mondomaine/?fc=module&module=sitologconnector&controller=test_remote ). Les accès retournent alors une erreur 410 (script non trouvé). Vous pouvez dans ce cas essayer en utilisant le format d'url alternatif ( https://www.mondomaine/module/sitologconnector/interface?sitolog_controller=test_remote ). Pour cela une option à cocher dans les paramètres de connexion avancés. -Depuis 2025, de plus en plus de cas d'échec de connexion sont dus à un WAF, ou Cloudflare, ou Mode Security installé coté serveur pour sécuriser les accès, qui confond les requêtes reçus de Merlin Backoffice Flex par des attaques de robots ou hackers. Il faut dans ce cas, demander à ce que soit ajouté en liste blanche l'IP adresse fixe de votre poste de travail.
-Re-vérifiez l'e-mail, le mot de passe de connexion au back office et la valeur de la clé de cryptage. Ce type d'erreur est la cause de 98% des appels à notre support. -Cette version nécessite un nouveau module connecteur renommé "Sitolog Connector" V8.0.c et plus (à la place de Sitolog Application Connect), et qui s'installe dans un dossier différent" sitologconnector". L'ancienne version ne doit être conservée que si vous continuez à utiliser PrestaPricing, PrestaCatégories ou d'anciennes versions de Merlin , ou encore AutoPresta. La prochaine version d'AutoPresta utilisera aussi exclusivement le nouveau connecteur. Correctif : Sitolog Connector est bien sûr fourni avec Merlin 1.4 et ultérieur est doit obligatoirement être installé. -Ce nouveau connecteur est beaucoup plus sécurisé et donc plus stricte. Il impose de saisir la clé de cryptage et de la personnaliser. Lors de la première connexion, saisir la valeur par défaut AABBCCDDEEFFGGHH, sauf si la clé avait été modifiée dans l'ancien module connecteur. Si vous ne connaissez pas la valeur de la clé, vous pouvez la retrouver dans la page de configuration du module connecteur sur votre site. Si la valeur de la clé n'est pas la bonne, la connexion échoue avec un message d'erreur pouvant indiquer que la version du connecteur n'est pas la bonne. Correctif: La valeur dans la fenêtre de configuration et celle saisie dans la page de connexion de Merlin doivent correspondre. Essayez avec la valeur par défaut AABBCCDDEEFFGGHH, mais aussi avec votre valeur perso si vous l'aviez déjà changée, même si le connecteur vous indique qu'il voit la valeur par défaut. -La sécurisation nous a conduit à forcer l'encryptage de la toute première requête chargée de récupérer le nom de la base et à vérifier la clé de cryptage, ainsi qu'à forcer l'encryptage de toutes les requêtes lorsque la connexion vers votre site n'est pas du type HTTPS . Ces encryptages utilisent la commande PHP mb_convert_encoding. Or comme déjà indiqué plus haut, certains serveurs ne connaissent pas cette commande et cela conduit a un échec de connexion. Correctif : demandez à votre Webmestre ou hébergeur d'installer le module PHP mbstring. -Un nouveau cas surprenant ce jour : dans les versions récentes de PrestaShop, il peut arriver que la valeur encodée (md5) du mot de passe employé soit corrompue, mais qu'il soit malgré cela possible de se connecter au back office de Prestashop. Mais pas à Merlin. Comment vérifier si on est dans ce cas ? : Cliquez dans la zone blanche (fond de la fenêtre) de la fenêtre de connexion de Merlin et tapez la séquence de touches suivante : Maj+Alt+t (appuyez sur Maj, restez enfoncé, sur Alt, restez enfoncé, puis sur t et relachez les trois touches). Cela ouvre une page dans votre navigateur pour simuler la connexion à la base telle que l'effectue Merlin. Si vous avez un message du style "Employee login failed" c'est que soit l'email soit le mot de passe sont faux, soit encore que vous êtes dans le cas rencontré ce jour. Correctif: il suffit de faire une modification du mot de passe de l'employé dans la gestion de l'Equipe de PrestaShop (on peut remettre le même mot de passe, l'important est qu'il soit sauvé à nouveau, donc ré-encodé)
-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/ -Sur certains serveurs mal sécurisés, le CHMOD indique au contraire 777. Merlin refusera de se connecter, mettre le dossier du connecteur 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.
-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 puis sitologconnector.
-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.
-Mettre le répertoire /modules/sitologconnector (anciennement MPRApplicationsConnect puis /modules/sitologapplicationconnect) en 755 et son contenu en 644. -Anciennes versions de PrestaPricing et PrestaCatégories: 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". -Il est possible qu'il soit nécessaire d'ajouter votre IP adresse (qui devra être un IP fixe dans ce cas), dans la liste des "hosts" autorisés à accéder à MySQL (via le CPanel de l'hébergeur).
-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"]
-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 sitologconnector (anciennement MPRApplicationConnect puis sitologapplicationconnect) -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 et dans Merlin, toujours choisir l'alphabet "UTF8 (UNICODE)"
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. -Depuis 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ées 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. Il est possible qu'il soit aussi nécessaire d'ajouter votre IP adresse (qui devra être un IP fixe dans ce cas aussi), dans la liste des "hosts" autorisés à accéder à MySQL (via le CPanel de l'hébergeur). 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.
-Re-vérifiez le nom et préfix de 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 ou la clé de cryptage. -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 ou sitologconnector. Solutions: -Vérifiez l'e-mail et mot de passe de connexion au back office. -Désinstallez, SUPPRIMEZ LE REPERTOIRE sitologapplicationconnect ou à partir de Merlin 1.4 le répertoire sitologconnector, et réinstallez la dernière version du module de connexion, 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 sitologconnector. -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) -Anciennes versions de PrestaPricing ou PrestaCatégories : passez à la version béta 6.1.4 et le module de connexion en version 4.6.e ou ultérieures, 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..
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) -Mauvais réglage PHP sur le serveur, l'extension mysqli n'est pas activée. Allez dans votre Cpanel ou interface de gestion de votre hébergement, puis dans les réglages PHP (parfois il s'agit du bouton "Choix de la version PHP") et cochez la case "mysqli". Il est possible que le serveur refuse si cette option rentre en conflit avec une autre option, comme "myslnd". Dans ce cas décochez cette dernière.
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)
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:[email protected]/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.
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.
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.
-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. -Vérifier que le module PHP mbstring est bien installé coté serveur.
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)
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é.
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.
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 (puis plus tard par sitologconnector) 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.
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.
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.
-Il peut s'agir d'un problème de réglage TLS consécutif à une mise à jour de Windows. Voir le 1er article du forum concernant les problèmes de connexion de Merlin, relatif aux problèmes de validation de licence. -Il peut aussi s'agir d'un bug de Windows .Net, consécutif à une mise à jour de Windows. On arrive à le réparer en enlevant les dernières mise a jour Windows dont celles qui concernait .Net, puis en les réinstallant une par une. |
|
Sitolog Inscrit le : 04/12/2011 Messages : 524 |
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 |
|
Sitolog Inscrit le : 04/12/2011 Messages : 524 |
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 |
|
Sitolog Inscrit le : 04/12/2011 Messages : 524 |
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 |
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 |
|
Sitolog Inscrit le : 04/12/2011 Messages : 524 |
|
|
Fabrice B. Inscrit le : 13/07/2014 Messages : 4 |
|
|
Fabrice B. Inscrit le : 13/07/2014 Messages : 4 |
|
|
Fabrice B. Inscrit le : 13/07/2014 Messages : 4 |
