La confirmation de commande Magento est envoyée à tous les clients


8

Je constate un comportement étrange dans l'une de nos boutiques: lorsqu'une commande est passée, l'email de confirmation est envoyé en CC à tous les clients enregistrés qui ont une commande en état "traitement". Cela se produit indépendamment du mode de paiement (virement bancaire et carte de crédit sont disponibles) et du mode de livraison (seul standard plat magento disponible).

La configuration de la boutique est assez basique avec une vue de site Web / magasin / magasin. Les extensions installées n'incluent rien lié à la commande ou à la caisse, à l'exception de l'extension du fournisseur de paiement de la carte de crédit.


Merci pour le code simonthesorcerer. J'ai le même problème. Tous les e-mails dans Magento 1.9.1 sont envoyés à tous les clients avec des commandes ouvertes (en cours de traitement ou en attente). Je n'ai pas trouvé de solution basée sur les événements ou aucune solution d'ailleurs. J'ai essayé votre solution mais cela n'a pas fonctionné. Dans app / code / local /, je n'avais aucun des dossiers / fichiers suivants: Namespace / EmailQueueFix / etc / config.xml Namespace / EmailQueueFix / Model / Resource / Email / Queue.php J'ai donc créé les dossiers et fichiers et copié le code que vous avez écrit. Mais cela n'a pas résolu le problème. Avez-vous créé les dossiers / fichiers ci-dessus ou êtes m
JK9

HI, le code est une extension, il est donc correct que vous deviez créer les dossiers / fichiers manuellement. Ce que fait ce code est: chaque fois que magento-cronjob supprime tous les messages envoyés de la table de base de données core_email_queue, il supprime également tous les destinataires de ces messages. Donc, fondamentalement, cela n'a pas fonctionné pour vous car cette tâche cronjob doit être exécutée au moins une fois avant de prendre effet.
simonthesorcerer

Réponses:


7

Attention!

Ce que fait ce code est: chaque fois que magento-cronjob supprime tous les messages envoyés de la table de base de données core_email_queue, il supprime également tous les destinataires de ces messages. Donc, fondamentalement, cela ne fonctionne pas pour vous tant que cette tâche cronjob n'a pas été exécutée au moins une fois.

Solution

J'ai trouvé la réponse grâce à une autre question ici: la table core_email_queue_recipients n'a pas été vidée par le cronjob. La méthode Mage_Core_Model_Email_Queue::cleanQueue()appelle Mage_Core_Model_Resource_Email_Queue::removeSentMessages(), ce qui est assez simple:

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

Quoi qu'il en soit, cette méthode ne supprime pas les anciens destinataires. Ainsi, dès qu'un nouveau message avec message_id n est mis en file d'attente, tous les anciens destinataires avec message_id n recevront également le nouvel e-mail. La chose que je ne comprends pas est: pourquoi l'équipe centrale n'a-t-elle pas vu cela, et pourquoi cela ne conduit-il pas à plus de problèmes?

J'ai écrit un petit module pour résoudre ce problème. Il utilise un remplacement de classe pour Mage_Core_Model_Resource_Email_Queue, donc si quelqu'un peut suggérer une meilleure solution (basée sur les événements?), Je serais heureux.

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

J'ai publié un correctif différent qui ne nécessite pas d'installer un nouveau module, et est probablement un peu plus propre.

Il utilise simplement une contrainte de clé étrangère sur la table core_email_queue_recipients pour supprimer les enregistrements de destinataires en cascade.

En utilisant cette nouvelle clé étrangère, aucun enregistrement orphelin ne sera laissé sur la table core_email_queue_recipients lors du nettoyage de la table core_email_queue , donc aucun message dupliqué ne sera envoyé à de mauvais destinataires.

Vous pouvez trouver la solution détaillée sur ce post: https://magento.stackexchange.com/a/87299/23057


OMI, c'est une solution plus propre et la clé étrangère doit être incluse par défaut.
micwallace

1

Il s'agit d'un problème d'index dans la base de données. Vous pouvez le réparer avec l' outil de réparation de base de données Magento .

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

Le problème me cause beaucoup de frustration. Dans mon cas, il provient de la mise à niveau de la version. C'est une bonne pratique chaque fois que vous effectuez une mise à niveau de version pour effectuer une nouvelle installation dans un autre répertoire et dans une nouvelle base de données de référence vide et utilisez ensuite l'outil pour comparer que la structure et les index de votre base de données sont déclarés comme dans le nouveau vide base de données de référence. Cette structure est ce dont la nouvelle version a besoin! Sachez que le problème n'est pas dû à de mauvais index et ne peut pas être résolu par une réindexation. Plus est un problème d'index manquants comme je le vois. Gardez toujours des copies de sauvegarde de la base de données avant d'exécuter l'outil!Il est dommage que même si vous réinstallez Magento, la vérification de l'index et de la structure de la base de données ne soit pas proposée en option et vous devez suivre la procédure ci-dessus. (dans mon cas, je passais de la version 1.8 à 1.9).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.