Magento 1.9.1 Email Queue не работает / глючит - как устранить неполадки и какой патч считается лучшим?

Прежде всего, да, это еще один вопрос / тема об электронной почте 1.9.1. Но речь идет не о каких-либо проблемах cron (таких как эта или эта ) или о том, что новая функция очереди не используется (как эта ).

В нашем случае у нас была проблема, что очередь ( core_email_queueи core_email_queue_recipients) просто не получала бы электронных писем о новых заказах или обновлениях заказов, и, следовательно, больше писем не отправлялось для чего-либо связанного с заказом, также cron отлично работает и вручную добавляет электронные письма в очередь работает, и они отправляются.

Странно то, что в нашей тестовой среде все работало. Даже когда мы начали работать с сегодняшнего дня в первые минуты, все письма были обработаны, но через несколько минут (без каких-либо дополнительных изменений в действующей системе) больше никаких новых писем не добавлялось в очередь. Кажется, что это произошло (но я не могу сказать наверняка), когда первый клиент использовал PayPal Express, который мы не тестировали заранее: - / И действительно, мы использовали некоторые пользовательские переопределения в логике PayPal Express со старой sendNewOrderEmail()функцией. Но мы не могли заставить работать электронные письма снова, даже после того, как исправили их для использования queueNewOrderEmail().
Итак, первый вопрос: возможно ли, что старая функция вызвала некоторую несогласованность, которая «сломалась» очередь электронной почты? Или это просто большое совпадение и есть совершенно другое объяснение?

Поскольку мы не смогли найти проблему, но, разумеется, нам нужно было, чтобы письма снова работали как можно скорее, мы пошли на другое переопределение ядра. В Mage_Core_Model_Email_Template_Mailer(конечно, в копии local) мы закомментировали строку 76: ->setQueue($this->getQueue())
Это, кажется, обходит очередь, и все письма снова отправляются в старом порядке.

Однако, поскольку мы хотели бы свести к минимуму количество переопределений ядра, и мы также не можем прямо сейчас сказать, столкнемся ли мы с какими-либо другими побочными эффектами, любыми другими советами или решениями от людей с более глубоким пониманием кода magento и очередь электронной почты будет оценена.

Обновление для 1.9.2: при обновлении до 1.9.2 мы снова внимательно рассмотрели очередь электронной почты и не смогли воспроизвести проблему. Но поскольку мы до сих пор не имеем реального представления о том, в чем заключалась проблема с 1.9.1, и поскольку переопределение Mage_Core_Model_Email_Template_Mailer::send()все еще работает описанным здесь способом, мы все еще не используем очередь. Таким образом, мы надеемся, что не будем снова сталкиваться с той же проблемой через некоторое время в производстве.

tl; dr: в 1.9.1 очередь электронной почты не работает, закомментируя строку 76 в Mage_Core_Model_Email_Template_Mailerобход очереди электронной почты, и письма отправляются снова, но это не похоже на хорошее решение. Как это можно решить лучше?

email ce-1.9.1.0 cron

— Джи DWork
источник

Сколько тестовых транзакций вы выполнили по сравнению с количеством реальных транзакций, выполненных за первые несколько минут? Было ли это обновление более старой версии, а некоторые файлы отсутствуют или имеют неправильные разрешения? Как насчет exception.logили, возможно system.log, есть какие-нибудь подсказки там?

— pspahn

Это было обновление с 1.9.0.1, и оно было сделано не через Connect-Manager, а из базы кода Magento, поэтому я сомневаюсь, что у нас отсутствуют файлы (мы также выполнили проверку и coreт. Д., Чтобы убедиться, что все не настроено или расширение установлено и немодифицировано и оно есть). Права доступа соответствуют старой настройке, а журналы / отчеты чистые.

— Джи DWork

Cron настроен так же?

— pspahn

Когда мы увидели изменение адреса электронной почты в журнале изменений, мы изменили запуск cron каждую минуту каждые 5 минут (как мы понимаем это изменение, так что в противном случае в худшем случае клиенты должны будут ждать до 5 минут для своих писем с подтверждением). В остальном изменений нет, и, как уже было сказано, мы видим, что cron работает без проблем. // edit: я, вероятно, должен добавить, что мы используем (и всегда использовали) Aoe_Scheduler, где мы также устанавливаем core_email_queue_send_allзапуск каждую минуту и откуда мы видим, что он на самом деле выполняется.

— Джи DWork

В четвертом квартале 2015 года у меня возникла та же проблема. Я могу подтвердить, что в таблицах очередей отсутствуют некоторые записи для некоторых заказов, что является явным признаком подтверждения сообщений об отсутствии электронных писем. К сожалению, логирование было отключено в моем случае, поэтому у меня пока нет ошибок для поиска. Узнали ли вы что-нибудь новое с тех пор, как вы изначально разместили, что может быть полезно добавить?

— Рик Бучински

Ответы:

Я предполагаю, что настройка cron.php для запуска каждую минуту привела к тому, что многие вещи встали друг на друга, то есть не закончили до того, как выполнится следующая запланированная задача того же характера или аналогичная. Поскольку оба cron.php не будут знать о каждом состоянии. Одна и та же запись может быть предпринята дважды, что приведет к нечетному исключению, нарушающему отправку электронной почты в очереди.

С учетом вышесказанного, есть Mage::Logисключения в почтовой программе очереди, поэтому проверка того, включено ли ведение журнала, будет лучшим шагом, чтобы определить, есть ли исключения. Также может быть целесообразно просто запустить php -f cron.phpиз CLI, чтобы увидеть, вызывает ли он какие-либо исключения, вы можете не увидеть, что он работает за кулисами.

https://github.com/OpenMage/magento-mirror/blob/magento-1.9/app/code/core/Mage/Core/Model/Email/Queue.php#L246

Я бы также начал с простого mail()теста PHP, чтобы убедиться, что вы не сталкиваетесь ни с какими политиками спама или чем-то подобным. Просто чтобы быть уверенным, что это не что-то меньшее в стеке, вызывающее проблему.

Magento отправка почты не работает

Просто некоторые предположения, надеюсь, это поможет!

* РЕДАКТИРОВАТЬ *

Используйте cron.shвместо , cron.phpкак он будет делать , grep psчтобы посмотреть , чтобы увидеть , если предыдущий процесс уже запущен.

https://github.com/OpenMage/magento-mirror/blob/magento-1.9/cron.sh#L46

— B00MER
источник

Спасибо за вклад, но эти проблемы вполне могут быть исключены. То, что реальное задание системного cron выполняется каждую минуту, не означает, что все задания cron Magento выполняются. В нашем случае только электронная почта была настроена так, что она также запускается каждую минуту, и из журнала cron Magentos мы видим, что все задания cron завершаются успешно - даже в «напряженные» минуты (т.е. каждый час или около того, когда одновременно запускается больше заданий, а не только электронная почта). ). Ведение журнала также включено, и исключения не генерируются вообще. Использование спам-фильтров может быть исключено, так как после обходного пути, который я разместил, все электронные письма достигают всех клиентов.

— Jey DWork

Вы можете попробовать включить режим разработчика, чтобы увидеть, помогает ли он генерировать исключения, которые не регистрируются. Будьте осторожны, если он запущен в производство. Также какие-либо коррелирующие журналы веб-сервера?

— B00MER

@JeyDWork вы реализовали Aoe_Scheduler ? Это может дать хорошую видимость.

— отметки

Хотелось бы увидеть обновление. Очередь электронной почты становится проблемой для многих.

— отметки

Для меня я использовал стандарт PayPal, который требует возврата данных IPN (мгновенного платежа) из PayPal только для того, чтобы подтвердить, что платеж был успешным, изменить статус заказа на обработку / завершен и, наконец, отправить электронное письмо ..., но у меня не было фактической настройки домена для моего сервера и доступа к vhosts это было причиной, по которой PayPal не мог публиковать данные IPN в magento. Вы можете проверить историю IPN в профиле бизнес-аккаунта PayPal. Paypal фактически показал данные, которые предполагалось отправить, и статус был «повторная попытка» ..

— Zaw

Проверьте, имеют ли core_email_queue и core_email_queue_recipients AUTO_INCREMENT. Если в этой таблице нет AI, она не будет принимать новые записи.

— Али Экзальтер
источник