La confirmación del pedido de Magento se envía a todos los clientes.


8

Veo un comportamiento extraño en una de nuestras tiendas: cuando se realiza un pedido, el correo electrónico de confirmación se envía en CC a todos los clientes registrados que tienen un pedido en estado de "procesamiento". Sucede independientemente del método de pago (la transferencia bancaria y la tarjeta de crédito están disponibles) y el método de envío (solo está disponible el estándar plano de magento).

La configuración de la tienda es bastante básica con una vista de sitio web / tienda / tienda. Las extensiones instaladas no incluyen nada relacionado con el pedido o el pago, excepto la extensión del proveedor de pagos de la tarjeta de crédito.


Gracias por el código simonthesorcerer. Estoy teniendo el mismo problema Todos los correos electrónicos en Magento 1.9.1 se envían a todos los clientes con pedidos abiertos (en proceso o pendientes). No he encontrado una solución basada en eventos ni ninguna solución para el caso. Intenté su solución pero no funcionó. En app / code / local /, no tenía ninguna de las siguientes carpetas / archivos: Namespace / EmailQueueFix / etc / config.xml Namespace / EmailQueueFix / Model / Resource / Email / Queue.php Así que creé las carpetas y archivos y Copié el código que escribiste. Sin embargo, no resolvió el problema. ¿
Creó

Hola, el código es una extensión, por lo que es correcto que haya creado las carpetas / archivos manualmente. Lo que hace este código es: cada vez que magento-cronjob elimina todos los mensajes enviados de la tabla de base de datos core_email_queue, también elimina todos los destinatarios de estos mensajes. Entonces, básicamente, no funcionó para usted porque esta tarea cronjob debe ejecutarse al menos una vez antes de que surta efecto.
simonthesorcerer

Respuestas:


7

¡Atención!

Lo que hace este código es: cada vez que magento-cronjob elimina todos los mensajes enviados de la tabla de base de datos core_email_queue, también elimina todos los destinatarios de estos mensajes. Entonces, básicamente, no funciona para usted hasta que esta tarea cronjob se haya ejecutado al menos una vez.

Solución

Encontré la respuesta gracias a otra pregunta aquí: la tabla core_email_queue_recipients no fue vaciada por el cronjob. El método Mage_Core_Model_Email_Queue::cleanQueue()llama Mage_Core_Model_Resource_Email_Queue::removeSentMessages(), que es bastante simple:

public function removeSentMessages() {
    $this->_getWriteAdapter()->delete($this->getMainTable(), 'processed_at IS NOT NULL');
    return $this;
}

De todos modos, este método no elimina los antiguos destinatarios. Por lo tanto, tan pronto como se ponga en cola un nuevo mensaje con message_id n, todos los destinatarios anteriores con message_id n también recibirán el nuevo correo electrónico. Lo que no entiendo es: ¿por qué el equipo central no ha visto esto y por qué esto no genera más problemas?

Escribí un pequeño módulo para arreglar esto. Utiliza una anulación de clase para Mage_Core_Model_Resource_Email_Queue, por lo que si alguien puede sugerir una mejor solución (¿basada en eventos?), Me alegraría.

app / code / local / Namespace / EmailQueueFix / etc / config.xml

<?xml version="1.0"?>
<config>
    <modules>
        <Namespace_EmailQueueFix>
            <version>1.0</version>
        </Namespace_EmailQueueFix>
    </modules>
    <global>
        <models>
            <core_resource>
                <rewrite>
                    <email_queue>Namespace_EmailQueueFix_Model_Resource_Email_Queue</email_queue>
                </rewrite>
            </core_resource>
        </models>
    </global>
</config>

app / code / local / Namespace / EmailQueueFix / Model / Resource / Email / Queue.php

<?php

class Namespace_EmailQueueFix_Model_Resource_Email_Queue extends Mage_Core_Model_Resource_Email_Queue {
    /**
     * Remove already sent messages
     * ADDED: also remove all recipients of sent messages!
     *
     * @return Mage_Core_Model_Resource_Email_Queue
     */
    public function removeSentMessages() {
        $writeAdapter = $this->_getWriteAdapter();
        $readAdapter = $this->_getReadAdapter();
        $select = $readAdapter->select()->from(array("ceqr" => $this->getTable('core/email_recipients')), array('*'))->joinLeft(array('ceq' => $this->getMainTable()), 'ceqr.message_id = ceq.message_id', array('*'))->where('ceq.processed_at IS NOT NULL OR ceq.message_id IS NULL');
        $recipients = $readAdapter->fetchAll($select);
        if ( $recipients ) {
            foreach ( $recipients as $recipient ) {
                $writeAdapter->delete($this->getTable('core/email_recipients'), "recipient_id = " . $recipient['recipient_id']);
            }
        }
        $writeAdapter->delete($this->getMainTable(), 'processed_at IS NOT NULL');
        return $this;
    }

}

app / etc / modules / Namespace_EmailQueueFix.xml

<?xml version="1.0"?>
<config>
    <modules>
        <Namespace_EmailQueueFix>
            <codePool>local</codePool>
            <active>true</active>
        </Namespace_EmailQueueFix>
        <depends>
            <Mage_Core/>
        </depends>
    </modules>
</config>

2

Publiqué una solución diferente que no requiere instalar un nuevo módulo, y probablemente sea un poco más limpia.

Simplemente usa una restricción de clave externa en la tabla core_email_queue_recipients para eliminar los registros de Destinatarios en cascada.

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 , por lo que no se enviarán mensajes duplicados a destinatarios incorrectos.

Puede encontrar la solución detallada en esta publicación: https://magento.stackexchange.com/a/87299/23057


En mi opinión, esta es una solución más limpia y la clave externa debe incluirse de forma predeterminada.
micwallace

1

Este es un problema de índices en la base de datos. Puede repararlo con la herramienta de reparación de bases de datos Magento .

http://merch.docs.magento.com/ce/user_guide/magento/database-repair-tool.html

El problema me causa mucha frustración. En mi caso, se originó a partir de la actualización de la versión. Es una buena práctica cada vez que realice una actualización de versión para realizar una instalación limpia en otro directorio y en una nueva base de datos de referencia vacía y luego use la herramienta para comparar que la estructura y los índices en su base de datos se declaran como en el nuevo vacío base de datos de referencia. ¡Esta estructura es lo que necesita la nueva versión! Tenga en cuenta que el problema no es de índices malos y no se puede resolver con la reindexación. Más es un problema de falta de índices como lo veo. ¡Mantenga siempre copias de seguridad de la base de datos antes de ejecutar la herramienta!Es una pena que, incluso si reinstala Magento, la verificación de índice y estructura de la base de datos no se ofrece como una opción y debe seguir el procedimiento anterior. (en mi caso estaba actualizando de la versión 1.8 a 1.9).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.