Magento 1.9.1 Coda e-mail non funzionante / buggy - come risolvere e quale è considerata la migliore patch?

Prima di tutto sì, questa è ancora un'altra domanda / argomento sulla coda di posta elettronica 1.9.1. Ma non si tratta di problemi di cron (come questo o questo ) o di non utilizzare la nuova funzione di coda (come questo ).

Nel nostro caso abbiamo avuto il problema, che la coda ( core_email_queuee core_email_queue_recipients) semplicemente non avrebbe ricevuto e-mail su nuovi ordini o aggiornamenti di ordini e quindi non più e-mail sono state inviate per qualsiasi cosa relativa all'ordine, anche cron sta funzionando perfettamente e aggiungendo manualmente e-mail a la coda funziona e vengono inviati.

La cosa strana è che nel nostro ambiente di test tutto ha funzionato. Anche quando siamo andati online oggi nei primi minuti, tutte le e-mail sono state elaborate, ma dopo alcuni minuti (senza ulteriori modifiche sul sistema live, ovviamente) non sono state aggiunte più nuove e-mail alla coda. Sembra che questo sia accaduto (ma non posso dirlo con certezza) quando il primo cliente ha utilizzato PayPal Express, che non abbiamo testato in anticipo: - / E in effetti stavamo usando alcune sostituzioni personalizzate nella logica di PayPal Express con la vecchia sendNewOrderEmail()funzione. Ma non siamo riusciti a far funzionare nuovamente le e-mail anche dopo averle patchate queueNewOrderEmail().
Quindi la prima domanda sarebbe: è possibile che la vecchia funzione abbia innescato alcune incoerenze che "si sono rotte" la coda di posta elettronica? O è solo una grande coincidenza e c'è una spiegazione completamente diversa?

Dato che non siamo riusciti a trovare il problema, ma ovviamente avevamo bisogno che le e-mail funzionassero di nuovo al più presto, abbiamo optato per un'altra sostituzione principale. In Mage_Core_Model_Email_Template_Mailer(ovviamente in una copia in local) abbiamo commentato la riga 76: ->setQueue($this->getQueue())
questo sembra bypassare la coda e tutte le mail vengono inviate di nuovo alla vecchia maniera.

Tuttavia, poiché vorremmo ridurre al minimo il numero di override principali e al momento non possiamo nemmeno dire se dovremo affrontare altri effetti collaterali, eventuali altri suggerimenti o soluzioni da parte di persone con una comprensione più profonda del codice magento e del la coda di posta elettronica sarebbe apprezzata.

Aggiornamento per 1.9.2: sull'aggiornamento a 1.9.2 abbiamo dato di nuovo un'occhiata più da vicino alla coda e-mail e non siamo stati in grado di riprodurre il problema. Ma dato che non abbiamo ancora idea di quale fosse il problema con 1.9.1 e dato che l'override Mage_Core_Model_Email_Template_Mailer::send()funziona ancora nel modo qui descritto, non stiamo ancora usando la coda. In questo modo speriamo di non ripetere lo stesso problema dopo qualche tempo in produzione.

tl; dr: la coda e-mail non funziona in 1.9.1, commentando la riga 76 in Mage_Core_Model_Email_Template_Mailerbypass la coda e-mail e le e-mail vengono inviate di nuovo, ma questa non sembra una buona soluzione. Come può essere risolto meglio?

email ce-1.9.1.0 cron

— Jey DWork
fonte

Quante transazioni di test hai eseguito rispetto a quante transazioni live sono state eseguite nei primi minuti? Si è trattato di un aggiornamento da una versione precedente e alcuni file sono mancanti o dispongono di autorizzazioni non corrette? Che ne dici exception.logo forse system.logci sono degli indizi?

— pspahn,

È stato un aggiornamento dall'1.9.0.1 e non è stato eseguito tramite Connect-Manager ma dalla base di codici Magento, quindi dubito che ci siano file mancanti (abbiamo anche differito coreecc. Per garantire che tutto ciò che non è personalizzato o un'estensione sia presente e non modificato ed è). Le autorizzazioni corrispondono alla vecchia configurazione e i registri / i rapporti sono puliti.

— Jey DWork,

Cron è impostato lo stesso?

— pspahn,

Come abbiamo visto la modifica delle e-mail nel registro delle modifiche, abbiamo cambiato cron in modo che venga eseguito ogni minuto ogni 5 minuti prima (poiché comprendiamo la modifica in modo che, nel caso peggiore, i clienti debbano attendere fino a 5 minuti per le loro e-mail di conferma). A parte questo, non ci sono cambiamenti e, come detto prima, vediamo da altri lavori che cron funziona senza problemi. // modifica: probabilmente dovrei aggiungere che usiamo (e abbiamo sempre usato) Aoe_Scheduler in cui impostiamo core_email_queue_send_alll'esecuzione anche ogni minuto e da dove vediamo che viene effettivamente eseguito.

— Jey DWork,

Q4 2015 e ho lo stesso problema, posso confermare che nelle tabelle delle code mancano completamente le voci per alcuni ordini, un chiaro segno per confermare che non sono state ricevute e-mail. Sfortunatamente la registrazione è stata disattivata nel mio caso, quindi non ho ancora errori da cercare. Hai imparato qualcosa di nuovo da quando hai pubblicato originariamente che potrebbe essere utile aggiungere?

— Rick Buczynski,

Risposte:

La mia ipotesi è che l'impostazione di cron.php da eseguire ogni minuto abbia causato la sovrapposizione di molte cose, vale a dire, non terminare prima che venga eseguita la prossima attività pianificata della stessa natura o simile. Poiché entrambi cron.php non sarebbero a conoscenza di ogni stato. Lo stesso record potrebbe essere tentato due volte causando una strana eccezione che interrompe l'invio di e-mail in coda.

Detto questo, ci sono Mage::Logdelle eccezioni del Mailer code, quindi assicurarsi che la registrazione sia abilitata sarebbe il passo migliore per aiutare a determinare se ci sono eccezioni. Potrebbe essere saggio anche correre php -f cron.phpdalla CLI per vedere se sta generando delle eccezioni, potresti non vederlo correre dietro le quinte.

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

Vorrei anche iniziare con un semplice mail()test di PHP per assicurarmi che non stai eseguendo alcuna politica di spam o simili. Solo per essere sicuro che non è qualcosa di più basso nello stack che causa il problema.

L'invio di e-mail Magento non funziona

Solo qualche speculazione, spero che sia d'aiuto!

* MODIFICARE *

Usa cron.shinvece di cron.phpcome farà grep psper vedere se un processo precedente è già in esecuzione.

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

— B00MER
fonte

Grazie per l'input, ma questi problemi possono essere sicuramente esclusi. Solo perché il processo cron di sistema effettivo viene eseguito ogni minuto non significa che tutti i processi cron di Magento lo facciano. Nel nostro caso è stata impostata solo la posta elettronica per essere eseguita anche ogni minuto e dal registro cron di Magentos possiamo vedere che tutti i lavori cron terminano correttamente - anche in minuti "stressanti" (cioè ogni ora circa quando vengono eseguiti più lavori contemporaneamente e non solo la posta elettronica ). Anche la registrazione è abilitata e non vengono generate eccezioni. È possibile escludere l'incontro con i filtri antispam e dopo che la soluzione alternativa che ho pubblicato tutte le e-mail raggiunge tutti i clienti.

— Jey DWork,

Potresti voler provare e abilitare la modalità sviluppatore per vedere se aiuta a generare eccezioni che non vengono registrate. Siate cauti se funziona comunque in produzione. Anche registri web server correlati?

— B00MER,

@JeyDWork hai implementato Aoe_Scheduler ? Questo può dare una buona visibilità.

— benmarks

Vorrei vedere un aggiornamento. La coda delle e-mail si sta rivelando una sfida per molti.

— benmarks

Per me stavo usando lo standard paypal che ha bisogno del ritorno dei dati IPN (Instant Payment Notification) da paypal solo per confermare che il pagamento è andato a buon fine e cambiare lo stato dell'ordine in elaborazione / completato e infine inviare e-mail .. ma non avevo un vero dominio impostato l'accesso al mio server e ai vhosts è stato il motivo per cui paypal non ha potuto pubblicare i dati IPN su magento. Puoi controllare la cronologia IPN nel profilo dell'account aziendale paypal. Paypal in realtà ha mostrato i dati che si supponeva di inviare e lo stato era "riprovare" ..

— zaw

Controlla se core_email_queue e core_email_queue_recipients ha AUTO_INCREMENT. Se la tabella non dispone dell'abilitazione AI, non accetta nuove voci.

— Ali Exalter
fonte