Черга електронної пошти Magento 1.9.1 не працює / баггі - як усунути неполадки і що вважається найкращим виправленням?

Перш за все так, це ще одне питання / тема щодо черги електронної пошти 1.9.1. Але мова не йде про якісь проблеми з кроном (на кшталт цього чи цього ) або про те, що нова функція черги не використовується (як ця ).

У нашому випадку у нас виникла проблема, що в черзі ( 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

— Jey DWork
джерело

Скільки тестових транзакцій ви здійснили порівняно з тим, скільки трансляцій було здійснено за перші кілька хвилин? Це було оновлення до більш старої версії, а деякі файли відсутні або мають неправильні дозволи? Як щодо того, exception.logчи можливо system.log, чи є там якісь підказки?

— pspahn

Це було оновлення з 1.9.0.1, і це було зроблено не через Connect-Manager, а з кодової бази Magento, тому я сумніваюся, що у нас відсутні файли (ми також відрізнялися coreтощо, щоб забезпечити все, що не налаштовано, або розширення є на місці та немодифікований і він є). Дозвіл відповідає старому налаштуванню, а журнали / звіти чисті.

— Jey DWork

Чи встановлено cron однаково?

— pspahn

Оскільки ми побачили зміни в електронній пошті в журналі змін, ми змінили cron, щоб він працював щохвилини від кожні 5 хвилин до цього (як ми розуміємо зміни, так що в іншому випадку в гіршому випадку клієнтам доведеться чекати до 5 хвилин на свої листи підтвердження). Крім того, що немає змін і, як було сказано раніше, і ми бачимо, що з інших робочих місць cron працює без проблем. // редагувати: я, мабуть, мушу додати, що ми використовуємо (і завжди використовуємо) Aoe_Scheduler, де ми також налаштовуємося core_email_queue_send_allбігати щохвилини і звідки ми бачимо, що він насправді виконується.

— Jey DWork

Q4 2015, і у мене той самий випуск, я можу підтвердити, що в таблицях черг повністю відсутні записи для деяких замовлень, чіткий знак для підтвердження повідомлень про те, що повідомлення електронної пошти не надходило. На жаль, реєстрація в моєму випадку була вимкнена, тому я ще не маю помилок шукати. Чи дізналися ви щось нове з моменту публікації, яке ви могли б додати?

— Рік Бучинський

Відповіді:

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

З урахуванням сказаного, існують Mage::Logвинятки Mailer Mailer, тому переконайтесь, що ведення журналу увімкнено було б найкращим кроком для визначення того, чи є якісь винятки. Може бути розумним також просто запустити 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 працює щохвилини, не означає, що всі Magento Cron виконують завдання. У нашому випадку була створена лише електронна пошта, яка також запускається щохвилини, і з журналу 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 включення, вона не буде приймати нові записи.

— Алі Екзальтер
джерело