MarcKarl

Je vais expliciter plus clairement : 1 : Avant l'autorisation d'accès au dossier admin protégé, le tâche CRON se bloquait. J'ai pu constater le bloquage en testant l'URL de la tâche CRON sur le navigateur : il y avait une fenêtre qui me demandais un log et un mot de passe pour accéder au dossier. 2 : Maintenant cet accès n'est plus demandé. 3 : J'ai donc lancé la tâche CRON en test mais elle ne fonctionne toujours donc j'ai décidé de retester l'URL de la tâche CRON sur le navigateur 4: Sur le navigateur, la page affiche une page de connexion (pièce jointe) qui bloque la réalisation de la tâche CRON. Au vu de ce qui est écrit, je pense que sont demandés les logs et mot de passe de Prestashop

Merci, ça fonctionne très bien ! Il reste une dernière étape concernant ces 2 tâches CRON : j'ai les logins et mot de passe de Prestashop lui-même (je ne parle pas du dossier admin protégé, mais des logs qui protègent l'accès au backoffice) qui fait bloquer les URL Comment faire pour ces logs soient intégrés dans l'URL, ou s'il y a une autre méthode ?

Ok. Comment ignorer cette adresse IP ? Je ne vois pas comment faire

Merci pour l'information ! Et si le gestionnaire de tâche CRON est hébergé sur le même serveur que la boutique Prestashop, ça pose également problème ? (nous avons un serveur semi-dédié, Plesk chez OVH)

Bonjour, Je souhaite mettre en place deux tâches CRON pour la boutique Prestashop : - mise à jour de l'index de recherche - mise à jour d'un flux de données vers les places de marché Toutes les autres tâches CRON fonctionnent sans embuches, mais celles-ci bloquent : en effet, ces tâches CRON ont une URL qui pointe vers le dossier admin de Prestashop qui est protégé par un login/mot de passe. Comment intégrer le login et le mot de passe à la fin des URL de ces 2 tâches CRON afin qu'elles fonctionnent directement ? Merci bien

Quelle sont les raisons possibles de cette augmentation quotidienne de la taille du cache, et donc de notre sauvegarde ?

Ok, mais est-ce que c'est normal d'avoir une augmentation quotidienne d'environ 200 à 400Mo sur la taille de la sauvegarde sur un site de 1000 pages ?

Bonjour, Depuis 2 semaines, nous recevons un message d'erreur de la part du système de sauvegarde auto de notre hébergeur OVH. Ces erreurs indique que la sauvegarde auto n'a pas pu être menée à bien pour manque de place sur l'espace disque. Ce qui prend le plus de place sur notre boutique Prestashop est le cache qui ne cesse d'augmenter en taille : entre 200 et 400Mo par jours (nous avons environ 1000 fiches produit en ligne). - Est-ce que cette augmentation de cache est normale ? - Sachant que nous souhaitons conserver 2 semaines de sauvegarde quotidienne, est-il possible de compresser le cache ? Merci !

Re-bonjour, Votre solution fonctionne parfaitement, le nombre d'email en erreur envoyé a drastiquement chuté, merci beaucoup ! Bonne continuation

Ouups ! Cette fois j'ai supprimé le bon fichier et je vous tiens informé de l'évolution

J'ai supprimé index.php de /www/override/classes/order pour être précis

Bon... mauvaise nouvelle, ça n'a pas l'air de fonctionner pour le moment. Je confirme bien que le fichier OrderHistory.php est dans le dossier /www/override/classes/order . Tout est bon dans le code ? <?php class OrderHistory extends OrderHistoryCore { public function sendEmail($order, $template_vars = false) { $result = Db::getInstance()->getRow(' SELECT osl.`template`, c.`lastname`, c.`firstname`, osl.`name` AS osname, c.`email`, os.`module_name`, os.`id_order_state`, os.`pdf_invoice`, os.`pdf_delivery` FROM `'._DB_PREFIX_.'order_history` oh LEFT JOIN `'._DB_PREFIX_.'orders` o ON oh.`id_order` = o.`id_order` LEFT JOIN `'._DB_PREFIX_.'customer` c ON o.`id_customer` = c.`id_customer` LEFT JOIN `'._DB_PREFIX_.'order_state` os ON oh.`id_order_state` = os.`id_order_state` LEFT JOIN `'._DB_PREFIX_.'order_state_lang` osl ON (os.`id_order_state` = osl.`id_order_state` AND osl.`id_lang` = o.`id_lang`) WHERE oh.`id_order_history` = '.(int)$this->id.' AND os.`send_email` = 1'); if (isset($result['template']) && Validate::isEmail($result['email'])) { ShopUrl::cacheMainDomainForShop($order->id_shop); $topic = $result['osname']; $data = array( '{lastname}' => $result['lastname'], '{firstname}' => $result['firstname'], '{id_order}' => (int)$this->id_order, '{order_name}' => $order->getUniqReference() ); if ($result['module_name']) { $module = Module::getInstanceByName($result['module_name']); if (Validate::isLoadedObject($module) && isset($module->extra_mail_vars) && is_array($module->extra_mail_vars)) { $data = array_merge($data, $module->extra_mail_vars); } } if ($template_vars) { $data = array_merge($data, $template_vars); } $data['{total_paid}'] = Tools::displayPrice((float)$order->total_paid, new Currency((int)$order->id_currency), false); if (Validate::isLoadedObject($order) && !strpos($result['email'], "alerts-shopping-flux.com")) { // Attach invoice and / or delivery-slip if they exists and status is set to attach them if (($result['pdf_invoice'] || $result['pdf_delivery'])) { $context = Context::getContext(); $invoice = $order->getInvoicesCollection(); $file_attachement = array(); if ($result['pdf_invoice'] && (int)Configuration::get('PS_INVOICE') && $order->invoice_number) { Hook::exec('actionPDFInvoiceRender', array('order_invoice_list' => $invoice)); $pdf = new PDF($invoice, PDF::TEMPLATE_INVOICE, $context->smarty); $file_attachement['invoice']['content'] = $pdf->render(false); $file_attachement['invoice']['name'] = Configuration::get('PS_INVOICE_PREFIX', (int)$order->id_lang, null, $order->id_shop).sprintf('%06d', $order->invoice_number).'.pdf'; $file_attachement['invoice']['mime'] = 'application/pdf'; } if ($result['pdf_delivery'] && $order->delivery_number) { $pdf = new PDF($invoice, PDF::TEMPLATE_DELIVERY_SLIP, $context->smarty); $file_attachement['delivery']['content'] = $pdf->render(false); $file_attachement['delivery']['name'] = Configuration::get('PS_DELIVERY_PREFIX', Context::getContext()->language->id, null, $order->id_shop).sprintf('%06d', $order->delivery_number).'.pdf'; $file_attachement['delivery']['mime'] = 'application/pdf'; } } else { $file_attachement = null; } if (!Mail::Send((int)$order->id_lang, $result['template'], $topic, $data, $result['email'], $result['firstname'].' '.$result['lastname'], null, null, $file_attachement, null, _PS_MAIL_DIR_, false, (int)$order->id_shop)) { return false; } } ShopUrl::resetMainDomainCache(); } return true; } }

Donc pour être sûr, en modifiant cette ligne dans l'override, ça va : - bloquer l'envoi d'e-mails sur toutes les adresses "[email protected]" lors de la création d'une commande - et aussi bloquer l'envoi d'e-mails sur toutes les adresses "[email protected]" lors de la modification des statuts de ces commandes Ok j'ai fais ça, merci beaucoup ! C'est par contre un peu étrange qu'il y ait plusieurs versions de fichiers pour une même version de prestashop, je ne pensais pas que c'était possible. Je vais regarder ce que ça donne prochainement, je vous tiens au courant.

Elle est dans le fichier OrderHistory.php original (je l'ai mis en pièce jointe qq posts plus haut si jamais)

Du coup je viens de percuter sur qqch : la ligne du Mail::Send n'est pas dans la function AddWithemail, mais dans la function sendEmail