VertNature

Au sujet du mode SMTP: Un essai d'envoi via SMTP avec le client de messagerie Thunderbird confirme que le mode SSL/TLS port 465 n'est pas accepté par le serveur pro3.mail.ovh.net. Par contre le mode STARTTLS port 587 est bien fonctionnel. Ce mode n'étant pas proposé par PS1.6, ceci explique cela, et impose donc de choisir le mode Mail de PHP qui heureusement fonctionne.

Après échanges avec OVH qui me confirme la fonctionnalité sans Pb de la BAL emailpro souscrite (incluant donc désormais la sécurisation DKIM), j'ai finalement renoncé à l'envoi via SMTP qui s'avère incompatible, pour rester sur le mode mail de PHP recommandé par Prestashop, depuis les "paramètres avancés- Email" La fonction d'envoi des messages est ainsi bien restaurée, et il semble que la couche DKIM de la nouvelle BAL emailpro, moyennant quelques € supplémentaires, améliore grandement la distribution effective des messages, qui s'était singulièrement dégradée depuis quelques mois.

Bonjour Je rencontre un Pb similaire, survenu sans crier garde après des années de bons et loyaux services avec un simple plan MX OVH et la config par défaut de PS. Aucun message ne sort plus de PS depuis qq mois, et je m'étais temporairement dépanné en basculant via mon serveur de messagerie perso chez free...! Pensant que le Pb venait peut-être des nouvelles exigences de sécurisation DKIM (qui améliorent probablement la délivrabilité) , je viens de basculer mon plan MX-OVH (gratuit) vers un emailpro OVH (payant) qui intègre désormais la sécurité supplémentaire DKIM: Aucun Pb pour reconfigurer l'accès via Gmail en envoi/reception (Pop3), par contre impossible de reconfigurer Prestashop en SMTP avec les paramètres du serveur ovh emailpro ( serveurpro3.mail.ovh.net et port 587 + codage SSL, car TLS est systématiquement rejeté). Plus aucun message ne sort désormais de mon Prestashop, et je dois envoyer les validations de commandes et les N°s de suivi via Gmail, à la mano... ! Cela viendrait-il éventuellement d'un blocage coté OVH pour le protocole SMTP? Peut-on le contourner ? A noter que je suis en version 1.6 Merci des précieux conseils que vous pourrez m'apporter. FC

Ca fonctionne parfaitement. merci

Ce poste est ancien, mais toujours actuel: en version 1.6.1.18 et module ATOS, je confirme l’occurrence du 2eme type d'erreur signalé par ERICKO: Si l'on modifie une quantité directement au niveau du panier juste avant de passer au paiement (click direct sur un type de carte) donc sans rafraîchir le panier, le montant du paiement sur la page ATOS reste au montant du panier AVANT sa modif (alors que le total affiché juste avant sur le panier était correct). La commande est bien passée mais avec une erreur de paiement car le panier et le paiement indiquent alors 2 montants différents. il faut alors soit modifier la commande (si le client est OK) pour quantité+, soit rembourser le client pour repasser sa commande si Quantité - . C'est assez fastidieux... Difficile d'inciter le client à cliquer sur Panier pour rafraîchir la page avant de lancer le paiement !! Quelqu'un a t-il trouvé la solution depuis ces années?

Même difficulté rencontrée en version 1.6.1.5, sur prix et description produits, ainsi que nom du produit aussi, tous devenus non modifiables Résolu en forcant la compilation des smarty et désactivant le cache smarty pour permettre les modifications

Le mail reçu par le marchand se présente comme suit (par défaut): entête: Nouvelle commande : n°xxx - YSRMWYWKG corps; BRAVO ! Une nouvelle commande a été passée sur votre boutique "marchand" par ce client :"Nom" ("adresse mail") DÉTAIL DE LA COMMANDE Commande : YSRMWYWKG Passée le 01/04/2015 Paiement Atos - CB Référence Produit Prix unitaire Quantité Prix total ............. TRANSPORTEUR La Poste - Collissimo suivi ADRESSE DE LIVRAISON........... ADRESSE DE FACTURATION MESSAGE DU CLIENT :

Now updated in 16014, I encounter in FO a Pb with the pack content description, which is now troncated to the 1st item only (listed and displayed) This pb only appeared since 16014. Despite various trials such as cache regeneration, DB clean-up (with dedicated module) and re-check of the packs in BO (which are OK) : the FO Pb remains. you may see it more clearly on visiting my shop vertnature.fr with the KI and KIE items. Any suggestion?

Thank you The cleaner module did the job perfectly (cleaning+ integrity check of the database) reducingmeanwhile its size of a mere 20Kb amongst 600Kb Followed by the upgrade in 1 click to 1.6.0.14 : NICKEL I 'll keep in mind that trick to roll a clean/integrity check before the next upgrade. That can't hurt. Thanks again By the way, the product description Pb previously seen in FO seems to have been partially corrected, since doubled references of items included previously shown have now gone, but instead, for the kits, some references included are not listed anymore in the description...,

I Updated mid Feb from 1.6.0.9 to 1.6.0.12 and noticed only that items are written twice in FO. except for 1 product (amongst 12) strangely....any idea? Anyway, hoping that new "stable"1.6.0.14 would solve it, I jumped to the last update using 1click update facility, but unfortunately it failed: So I tried to revert but DB failed to recover (only 3 tables were copied) ! After investigation of DB, it appeared that the 4th table (advice_lang) is corrupted in all saved DB since 1.6.0.12, and had to be removed manually (with phpadmin) and replaced by a clean one (copied from 1.6.0.9 DB)... quite tedious ! After such repair and manual replacement of corrected DB, 1.6.0.12 works again. However, even just after that DB clean-up, I tried again to upgrade to 1.6.0.14 but it is still impossible to upgrade to 1.6.0.14 because of corrupted DB. How can I get out of that and upgrade to 1.6.0.14 ???

Module ATOS rendu inopérant suite à un echec de MAJ 1.6.0.14 et rollback vers 1.6.0.12: Solution: modules/atos/bin/request n'est plus un problème après réactivation des file permissions de groupe (lire et exécuter à 755) avec filezilla, appliquée à tous les sous dossiers du dossier modules/atos/bin.

Aussi incroyable que cela puisse paraître, Google Analytics semble être reparti tout seul depuis hier, alors que je n'ai touché à rien depuis l'avant veille, et ce après 10 jours de silence radio (en fait du 8/12 au 17/12 inclus) La veille j'avais bien tenté la réinit du module et le forcage de la compilation en désactivant le cache, mais les messages d'erreurs persistaient autant dans GA que lors de l'enregistrement des paramètres du module API GA v3.0. J'ai abandonné de guerre lasse ! Or à l'ouverture ce matin, tout est rentré dans l'ordre... EUREKA

I have the same pb since 17/12. Statistics of Google Analytics are no longer delivered. i.e visits remain at 0 every day since 17/12. However no modification were made in prestashop nor Google Analytics dashboard. In Prestashop "API Google Analytics" module, configuration page, all infos have been rechecked (ID, secred, Profil) but an alert permanently says "Cannot retrieve test results" In https://www.google.com/analytics/web/...., I have the following message (in french) : "La propriété vertnature.fr n'enregistre aucun appel. Le site ne reçoit aucune session ou n'est pas balisé correctement". And datas also stopped on 17/12 onwards. I wonder if an update of prestashop done around that date could be the cause of that disruption of the statistics...

Pour moi, la réponse du bureau de poste concernant le contrat So-Colissimo est qu'il ne faut pas y penser à moins de 5000 envois par an ! Du coup, on reste en affranchissements unitaires colissimo tarif particuliers, qui est en effet bien moins cher que le tarif pro. C'est quand même idiot... Notre statut est SARL en exo de TVA.

Ayant quelque peu cherché de mon coté aussi sur le même sujet, j'apporte 2 précisions: 1-Bien s'assurer que la commande sur laquelle on veut tester un N° de colis a effectivement bien sélectionné le transporteur que l'on veut tester. ça parait idiot, mais ça va encore mieux en le disant ! 2- Le modèle de courrier reprenant le lien vers le transporteur est bien "in-transit". Il n'est toutefois pas nécessaire de l'associer à un état de commande particulier, car c'est bien la saisie+validation du N° de suivi qui déclenche l'envoi séparé du mail "in-transit"