Magento n'envoie pas d'e-mails de confirmation de commande à l'administrateur


15

Je ne sais pas quoi faire.

Ce matin, j'ai configuré cron et selon Aoe_Scheduler, les e-mails dans la file d'attente sont envoyés toutes les 5 minutes. Cependant, je ne reçois pas de nouvelles confirmations de commande sur mon compte de messagerie. J'ai vérifié trois fois si j'ai configuré la bonne adresse de confirmation et j'ai quadruplé les dossiers de spam, mais pas d'e-mails.

Je crains également que les clients n'aient reçu aucun e-mail. Quelqu'un reconnaît-il ce problème? J'ai couru 1.9.1 (et depuis quelques minutes 1.9.2).

modifier: la création d'un compte ou la demande d'un nouveau mot de passe sur le frontend envoie des e-mails.


Que montrent vos journaux de courrier sortant?
Ben Lessani - Sonassi

@ BenLessani-Sonassi Je suis sur un serveur magento partagé donc je ne peux pas accéder à ces journaux directement (je contacterai mon hébergeur) Merci pour la suggestion de journal.
Frank

La configuration d'Aoe_Scheduler est également Queue configuration -> Queue Usage -> Never utile.
amitshree

Réponses:


15

Essayez une solution de contournement:

dans CMS> E-MAILS DE VENTE Définir la commande> Emails envoyés par courrier séparé (BCC est Buggy)

Magento connaît ce bogue et le corrigera en 2.0.


Quand le correctif est-il prévu? Est-ce réparé maintenant?
camdixon

9

Trois jours ont été consacrés à la recherche et à la résolution de ces hoquets, et je peux maintenant partager mes nouvelles connaissances sur les problèmes possibles liés à la mise à jour de Magento vers la version 1.9.

Tout d'abord, Magento 1.9+ repose entièrement sur des tâches cron pour envoyer des e-mails transactionnels. Si vous n'aviez pas configuré correctement les tâches cron auparavant, vous devrez le faire maintenant.

Tout d'abord, assurez-vous d'avoir configuré les tâches cron dans l'administrateur Magento sous System > Configuration > Advanced > System > Cron. Les paramètres par défaut sont:

Generate Schedules Every: 15
Schedule Ahead for: 20
Missed if Not Run Within: 15
History Cleanup Every: 10
Success History Lifetime: 60
Failure History Lifetime: 600

Il y a des gens qui suggèrent que ces paramètres devraient être modifiés, mais comme ils ne semblent pas être d'accord sur la meilleure combinaison, je préfère les laisser tels quels.

Vous devez ensuite aller dans votre panneau de contrôle d'hébergement et configurer des tâches cron. Dans cPanel, c'est sous Advanced> Cron Jobs. Configurez-les pour qu'elles s'exécutent toutes les cinq minutes et utilisez cette commande:

php -f /home/username/public_html/cron.php

Vérifiez que le chemin ci-dessus est correct et que le fichier cron.php est bien là à la racine de votre installation Magento (si vous venez de mettre à jour, il devrait l'être). Changez le nom d'utilisateur pour le bon compte.

Maintenant, j'ai d' abord fait l'erreur de suivre les conseils des développeurs à xtento.com qui disent utiliser une chaîne de commande wget: wget -O /dev/null -q http://www.YOURDOMAIN.com/PATH_TO_MAGENTO/cron.php.

Cela ne fonctionnait pas du tout pour moi, contrairement à la commande php, donc mon conseil est: respectez-le.


Merci de votre aide! Votre suggestion php de "php -f /home/username/public_html/cron.php" a fonctionné pour moi.
Scott

Homme merveilleux! cela a fonctionné pour moi aussi, comme un charme
CodeRomeos

L'utilisation de wget devrait également fonctionner .. Je suis curieux de savoir ce qui n'a pas fonctionné là
groovenectar

Merci, je n'exécutais pas cron sur l'instance DEV et j'ai noté que des e-mails de mot de passe oubliés étaient en cours d'envoi mais que la confirmation de commande ne suivait pas la mise à niveau vers 1.9.4.1 ... L'ajout du cron pour le site DEV a résolu l'envoi de l'e-mail de commande. Apparaît les e-mails transactionnels sont envoyés via cron à partir de 1.9. Ce qui suit est la syntaxe que nous utilisons pour notre cron, peut être utile pour arrêter le cron déclenchant les mises à jour de db à mi-mise à niveau: "! Test -e /absolute/path/to/your/sites/document/root/maintenance.flag && php - f /absolute/path/to/your/sites/document/root/cron.php> / dev / null 2> & 1 "
Flipmedia

2

Les e-mails de confirmation de commande n'étaient pas envoyés au client ou à nous. Vérifié les tâches cron sous cpanel et il était vide. Mon site de test a bien fonctionné, j'ai donc vérifié les tâches cron pour trouver ce paramètre et instantanément 60 e-mails sont entrés une fois que je l'ai défini sur le site en direct. J'espère que cela aide quelqu'un, m'a rendu fou.

min: 0,26,42,58 heure: * Jour: * Mois: * Jour de semaine: *

Commander: php /home/username/public_html/cron.php > /dev/null

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.