Nuevo correo electrónico de pedido que se envía dos veces

Estoy usando Magento 1.9.1 y al crear un nuevo pedido, ya sea desde la interfaz o el administrador, el sistema envía 2 correos electrónicos, ¡ambos iguales!

Miré en la red y encontré un error que era antiguo y no pude encontrar el código mencionado para comentar, también parecía que tenía que ver con los pedidos de Paypal y este no es el caso.

He desactivado TODAS las extensiones y lo he intentado y todavía tengo el mismo problema, así que estoy seguro de que no es un problema de Extensión.

Este problema debe estar relacionado con el nuevo sistema Magento Email Queue, que deja registros huérfanos en la tabla de destinatarios. Si este es tu problema, te envío una solución.

El nuevo sistema Magento Email Queue gestiona estas dos tablas: core_email_queue y core_email_queue_recipients . El primero maneja los mensajes de correo electrónico y el segundo, los destinatarios de estos mensajes.

La tabla core_email_queue se limpia a medida que se envían correos electrónicos en Magento Email Queue. Esta limpieza se realiza mediante un trabajo de pestaña cron llamado core_email_queue_clean_up , que se define dentro del archivo de configuración app / code / core / Mage / Core / etc / config.xm l. El código que realiza la limpieza se define en las removeSentMessages funcionan en el Mage_Core_Model_Resource_Email_Queue clase:

/**
 * Remove already sent messages
 *
 * @return Mage_Core_Model_Resource_Email_Queue
 */
public function removeSentMessages()
{
    $this->_getWriteAdapter()->delete($this->getMainTable(), 'processed_at IS NOT NULL');
    return $this;
}

El código anterior se ejecuta una vez al día por la tarea cron.

Pero sucede que la tabla core_email_queue_recipients (la que contiene destinatarios de correo electrónico, y que está vinculada a la tabla core_email_queue por el campo message_id ), no se limpia junto con la tabla core_email_queue (la que contiene mensajes de correo electrónico), dejando registros huérfanos dentro esa tabla de destinatarios cuando se limpia la tabla de mensajes.

El problema descrito aquí surge cuando la tabla core_email_queue (Mensajes) se restablece y el campo message_id de incremento automático en esta tabla se reinicia a 1.

Debido a que la tabla core_email_queue_recipients (Destinatarios) no se ha limpiado en consecuencia, cuando se agregan nuevos correos electrónicos a la Cola de correo electrónico de Magento, se crean nuevos registros en la tabla core_email_queue (con message_id comenzando de nuevo desde 1), y al mismo tiempo se crean nuevos registros en la tabla core_email_queue_recipients con estos mismos identificadores (comenzando de nuevo desde 1).

El problema es que estos identificadores ya pueden existir en la tabla de destinatarios como registros huérfanos (debido a mensajes de correo electrónico anteriores). Estos nuevos ID de mensajes se repiten dentro de la tabla core_email_queue_recipients . Al final, los mensajes de correo electrónico diferentes están vinculados a sus Destinatarios correspondientes por el message_id , pero también se vinculan erróneamente a los destinatarios anteriores a los que se les asignó el mismo message_id de correos electrónicos anteriores.

Por lo tanto, cuando se busca a los destinatarios para enviar un mensaje dado, además del destinatario apropiado, pueden surgir otros destinatarios incorrectos.

Afortunadamente, la solución para este problema es fácil de realizar.

Todo lo que se necesita es limpiar todos los identificadores de mensajes repetidos en la tabla core_email_queue_recipients y asegurarse de que cuando se elimina un mensaje en la tabla core_email_queue , al mismo tiempo, sus destinatarios correspondientes se eliminen en la tabla core_email_queue_recipients .

La mejor manera de lograr esto es crear una clave foránea que vincule estos registros y los elimine en cascada (pero debe realizar alguna limpieza antes de poder hacerlo).

Este es el procedimiento para solucionar el problema:

1) Ejecute las siguientes dos consultas SQL para limpiar la tabla core_email_queue_recipients de los registros huérfanos y los identificadores de mensajes repetidos:

DELETE FROM core_email_queue_recipients WHERE message_id NOT IN (SELECT message_id FROM core_email_queue);
DELETE FROM core_email_queue_recipients WHERE recipient_id < (SELECT recipient_id FROM (SELECT recipient_id FROM core_email_queue_recipients ORDER BY message_id ASC, recipient_id DESC LIMIT 1) AS r);

La primera consulta elimina los registros huérfanos y la segunda elimina los registros antiguos que ya no son válidos.

2) Cree una clave foránea en la tabla core_email_queue_recipients para eliminar los registros de Destinatarios en cascada. La consulta SQL para crear esta clave foránea es:

ALTER TABLE core_email_queue_recipients ADD FOREIGN KEY(message_id) REFERENCES core_email_queue(message_id) ON DELETE CASCADE;

Al usar esta nueva clave externa, no se dejarán registros huérfanos en la tabla core_email_queue_recipients al limpiar la tabla core_email_queue , y no se enviarán mensajes duplicados a destinatarios incorrectos en el futuro.

Yo tuve el mismo problema. Por cada pedido recibía el correo electrónico de los clientes y un correo electrónico separado a la dirección de mi tienda, ambos en el buzón de mi cuenta de correo electrónico de la tienda.

En Magento Admin: Sistema> Configuración> Correo electrónico de ventas> Pedido

He configurado el correo electrónico "Método de copia de correo electrónico de pedido de envío" de "Correo electrónico separado" a "Cco", y ahora funciona. Ahora solo recibo un correo electrónico por pedido.

Yo tuve el mismo problema. En mi caso, el problema fue causado por el código fuente del script cron.sh.

Mi proveedor de hosting usó sus propias versiones de los scripts cron.sh y cron.php para el trabajo cron de Magento.

Cuando cambié de la secuencia de comandos cron.sh a la secuencia de comandos cron.php para iniciar Magento-Cron-Job, el nuevo pedido de correo electrónico solo se envió una vez, mi problema se resolvió.

Tal vez su problema tenga algo que ver con el código del script cron.sh o cron.php .