La conferma dell'ordine Magento viene inviata a tutti i clienti


8

Vedo uno strano comportamento in uno dei nostri negozi: quando viene effettuato un ordine, l'e-mail di conferma viene inviata in CC a tutti i clienti registrati che hanno un ordine in stato di "elaborazione". Accade indipendentemente dal metodo di pagamento (sono disponibili bonifico bancario e carta di credito) e dal metodo di spedizione (disponibile solo standard piatto magento).

La configurazione del negozio è piuttosto semplice con una vista sito Web / negozio / negozio. Le estensioni installate non includono nulla correlato all'ordine o alla cassa tranne l'estensione del fornitore di servizi di pagamento della carta di credito.


Grazie per il codice simonthesorcerer. Sto avendo lo stesso problema. Tutte le e-mail in Magento 1.9.1 vengono inviate a tutti i clienti con ordini aperti (elaborazione o in sospeso). Non ho trovato una soluzione basata sugli eventi o alcuna soluzione al riguardo. Ho provato la tua soluzione ma non ha funzionato. In app / code / local /, non avevo nessuna delle seguenti cartelle / file: Namespace / EmailQueueFix / etc / config.xml Namespace / EmailQueueFix / Model / Resource / Email / Queue.php Così ho creato cartelle e file e copiato il codice che hai scritto. Tuttavia non ha risolto il problema. Hai creato le cartelle / i file sopra o sei m
JK9

Ciao, il codice è un'estensione, quindi è corretto che hai dovuto creare manualmente le cartelle / i file. Ciò che fa questo codice è: ogni volta che magento-cronjob rimuove tutti i messaggi inviati dalla tabella del database core_email_queue, rimuove anche tutti i destinatari di questi messaggi. Quindi, fondamentalmente, non ha funzionato per te perché questa attività cronjob deve essere eseguita almeno una volta prima che abbia effetto.
simonthesorcerer,

Risposte:


7

Attenzione!

Ciò che fa questo codice è: ogni volta che magento-cronjob rimuove tutti i messaggi inviati dalla tabella del database core_email_queue, rimuove anche tutti i destinatari di questi messaggi. Quindi, fondamentalmente, non funziona per te fino a quando questo task cronjob non verrà eseguito almeno una volta.

Soluzione

Ho trovato la risposta grazie a un'altra domanda qui: la tabella core_email_queue_recipients non è stata svuotata dal cronjob. Il metodo Mage_Core_Model_Email_Queue::cleanQueue()chiama Mage_Core_Model_Resource_Email_Queue::removeSentMessages(), che è piuttosto semplice:

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

Comunque, questo metodo non rimuove i vecchi destinatari. Pertanto, non appena un nuovo messaggio con message_id n viene messo in coda, anche tutti i vecchi destinatari con message_id n riceveranno la nuova e-mail. La cosa che non capisco è: perché il core team non l'ha visto e perché questo non porta a ulteriori problemi?

Ho scritto un piccolo modulo per risolvere questo problema. Utilizza un override di classe per Mage_Core_Model_Resource_Email_Queue, quindi se qualcuno può suggerire una soluzione migliore (basata sugli eventi?), Sarei felice.

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 / Modello / 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

Ho pubblicato una correzione diversa che non richiede l'installazione di un nuovo modulo e probabilmente è un po 'più pulita.

Utilizza solo un vincolo di chiave esterna nella tabella core_email_queue_recipients per eliminare i record dei destinatari in cascata.

Usando questa nuova chiave esterna, nessun record orfano verrà lasciato sulla tabella core_email_queue_recipients durante la pulizia della tabella core_email_queue , quindi nessun messaggio duplicato verrà ulteriormente inviato a destinatari errati.

Puoi trovare la soluzione dettagliata su questo post: https://magento.stackexchange.com/a/87299/23057


IMO questa è una soluzione più pulita e la chiave esterna dovrebbe essere inclusa per impostazione predefinita.
micwallace,

1

Questo è un problema di indici nel database. Puoi ripararlo con lo strumento di riparazione del database Magento .

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

Il problema mi provoca molta frustrazione. Nel mio caso è stato originato dall'aggiornamento della versione. È buona norma ogni volta che si esegue un aggiornamento della versione per effettuare un'installazione pulita in un'altra directory e in un nuovo database di riferimento vuoto e quindi utilizzare lo strumento per confrontare che la struttura e gli indici nel database sono dichiarati come nel nuovo vuoto database di riferimento. Questa struttura è ciò di cui ha bisogno la nuova versione! Tenere presente che il problema non riguarda indici errati e non può essere risolto con la reindicizzazione. Altro è un problema di indici mancanti come lo vedo io. Conservare sempre copie di backup del database prima di eseguire lo strumento!È un peccato che anche se si reinstalla Magento, la verifica dell'indice e della struttura del database non sia fornita come opzione e si debba seguire la procedura sopra descritta. (nel mio caso è stato l'aggiornamento dalla versione 1.8 alla 1.9).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.