ok, très bien.

@doekia merci merci j'y vais ...

Justement tu ne dois pas utiliser le paramétrage "livraison/préférence", c'est une option trop restrictive. Tu dois utiliser les règles paniers et/ou un maillage plus fin de transporteur (ou un mix des 2)

Bonsoir, je reviens vers vous pour remonter ce sujet car je n'arrive pas à faire marcher les taches crons malgré votre codage. Je suis en prestashop 1.7 avec un OVH mutualisé. Je veux faire tourner une tâche cron d'un module de génération de relances via messenger. J'ai donc mis la tache cron indiquée dans ce module dans le module cronjob. Et j'ai copié votre script dans un fichier cron.php que j'ai mis à la racine de mon fichier admin dans le www (c'est-à-dire : www/adminxx/cron.php). J'ai pris soin de mettre la tache cron indiquée dans cronjob dans ce cron.php. Je vous recolle le texte indiqué dans cron.php peut-être ai-je fait une erreur ? J'ai levé mon nom de domaine et les clés en remplaçant par xxx <?php /* ** Changez cette variable en true ou false pour que le cron ** affiche quelque chose - ceci apparaît dans les log de la ** console */ $verbose = true; /* ** sur l'écran de configuration du module cronjobs ** après avoir activé le mode avancé */ $cronjob_url = <<< EOT https://www.monnomdomaine.fr/adminxxx/index.php?controller=AdminCronJobs&token=xxxx EOT; /************************************** ** Ne rien modifier après cette ligne ** ***************************************/ error_reporting(E_ALL); $break_line = (php_sapi_name() == "cli") ? PHP_EOL : '<br/>'; $output = $verbose ? $break_line.'Cron Report of '.date('c').$break_line.$break_line : ''; $cronjob_url = trim($cronjob_url); $ch = curl_init($cronjob_url); curl_setopt($ch, CURLOPT_URL, $cronjob_url); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0); $data = curl_exec($ch); if ($verbose) { if($data) $output .= 'Ok'.$break_line.$data; else $output .= 'Failed'; } curl_close($ch); die($output); Sur ovh, j'ai crée le lien pour aller chercher ce cron.php Quand je le teste avec www.monnodomaine.fr/adminxxx/cron.php j'ai le resultat suivant qui semble indiquer que cela fonctionne : cronjobs_prestashop Cron Report of 2018-08-20T19:17:37+02:00 Ok 1 Quand je vais dans cronjob, cela m'indique que la requete a tourné (peut etre parce que j'ai testé manuellement comme indiqué ci-dessus). Pour autant les fameux messages par messenger ne sont jamais envoyés. Quelqu'un pourrait-il regarder pour vérifier si j'ai oublié quelque chose ou mal retranscrit une étape ? Sinon y a t il une autre moyen ? J'ai vu qu'il y a un module crontab. est-il plus efficace ? Je vous remercie par avance pour l'aide que vous pourrez m'apporter. Bonne soirée

Bonjour @eolia Après avoir regardé l'error.log. On a checker les trads et certains fichiers template qui était appelé. Finalement, après y avoir passé plus de 2h à modifier 400000 fichiers sans voir de changement sur le site. On a fait des essais en effacant et en forcant le cache. Et même après avoir forcé ovh a egalement mettre le site en mode dev, ça n'a rien changé. Finalement, on a enlevé le mode debug, et les caches se sont bien raffraichis ! Il n'y avait plus d'erreur, et même la page produit s'affiche, le site marche bien, j'ai pu mettre des produits dans le panier. C'était vraiment dû à une mauvaise synchronisation de prestashop et il avait buggé dans le passé sans prendre en compte tous les changements. Ah la la... Merci encore pour vos conseils et le temps que vous avez pris. J'avoue Prestashop 1.7 m'aura bien traumatisé...

non ce n'est pas block_contact mais block_myaccount_infos

J'ai fait une autre installation de votre Prestashop, sur une autre instance. Celle ci est vierge et tout c'est bien passé. Je pense que ma version 1.6.1.24 est trop endommagé, cela fait des mois que le site ralenti et que je rencontre des petits bugs. Je vais trouver la solution pour envoyer toutes mes données sur la version vierge et repartir avec un site plus puissant. Faut que juste que je trouve la solution pour tout récupérer et tout envoyer. Merci encore pour votre aide.

Avec la nouvelle version du module et la nouvelle version de analytics (ça n'arrête pas de changer), les étapes sont contruites automatiquement par un codage en dur de la part de google. Les étapes sont remontées par la couche "ec" via les évents GoogleAnalyticEnhancedECommerce.addCheckout(step) Avec step en dur donc: 1 - récap panier (étape 0 du tunnel) 2 - authentification (marche 1 coup sur 5 du fait de l'implémentation et du cheminement exact de l'internaute) 3 - page de sélection des adresses 4 - page de sélection du transporteur 5 - page des moyens de paiement 6 - confirmation de commande (hook et bien sûr dépendant de l'internaute et de son retour sur le shop après paiement tiers type CB) Il suffit ensuite de renommer les étapes dans analytics: Administration > Vue > Commerce électronique > Paramètres du commerce électronique amélioré Pour voir l'entonoir, c'est dans analytics: Conversion > Commerce électronique > Comportement lors du processus de paiement

Je n'arrive pas à comprendre qu'il faille polluer pendant 3 jours le topic pour quelque chose qui se résout d'un simple test A/B en 2 mn et qui au final consiste à faire très exactement ce qui est écrit. Ni plus, ni moins

Ah ben merci pour ces avertissements, je n'y aurais pas pensé... Cela dit actuellement je ne dois pas avoir de personnalisations, que du remplissage des champs dans le thème par défaut. Mais ça devrait me servir.

@okom3pom Le virer ou utiliser ma version débuguée (qui en même temps corrige les taches sur les jours et permet les accents dans les description^^)

@chdup han.. merci pour l'information. effectivement, ça semble logique en plus. Comme je n'ai pas eu de message d'erreur, je pensais que prestashop avait comprit que c'était offert. Merci encore.

@briko-bike Si tu es prêt à perdre tout ton historique de visite, truncate les tables Sinon il faut faire des requête en suppression un peu compliquées et compte tenu de ton volume nous parlons de plusieurs jours de maintenance pour faire cela - lock des tables connexion == aucune visite web possible. J'ai fais un module de nettoyage - par cron qui résoud ce problème https://store.enter-solutions.com/fr/75-housekeeper.html Compte tenu de ton volume à nettoyer il faudra plusieurs semaine avant que les tables retrouvent une taille normale. ATTENTION: Lorsque le cron s'exécute (ou que tu le lance manuellement) ton shop est quasi inaccessible en raison des locks en suppressions sur des tables essentielles. Il (le module) limite les suppressions à 10'000 paniers et 25'000 connexions/guest par exécution afin de ne pas mettre le bazar dans trafic .

Sauf que le xml n'as aucune raison d'avoir été ré-écrit tous les jours A moins d'update du module ou de need_instance = 1

Bonjour, j'ai le même problème pour le réglé j'ai mis le fichier csv dans Admin / export, pas terrible mais ça fonctionne, si tu as réglé le problème différemment n'hésite pas a le partager.

@eolia arf le con j'ai tout mélangé. Dans Fricadelle, j'avais ajouté les Rich Snippets il y a 9 ans et justement, je regardais hier et je me disais, Top pas d'erreur lol je viens de comprendre pourquoi :)

Oui, mais cette partie n'est pas gérée lors de l'install/upgrade du CMS. Je viens d'ajouter un contrôle dans le constructeur de Module.php et si la dépendance n'est pas installée, le module sera lui-même désinstallé.

@chdup Merci pour cette astuce, ça me servira si ça se reproduit.