Konfirmasi pesanan Magento dikirim ke semua pelanggan


8

Saya melihat perilaku aneh di salah satu toko kami: ketika pesanan dilakukan, email konfirmasi dikirim dalam CC ke semua pelanggan terdaftar yang memiliki pesanan dalam "pemrosesan" negara. Itu terjadi terlepas dari metode pembayaran (transfer bank dan kartu kredit tersedia) dan metode pengiriman (hanya standar datar magento yang tersedia).

Pengaturan toko cukup mendasar dengan satu tampilan situs web / toko / toko. Ekstensi yang dipasang tidak menyertakan apa pun yang terkait pesanan atau checkout kecuali ekstensi penyedia pembayaran kartu kredit.


Terima kasih untuk simonthesorcerer kode. Saya mengalami masalah yang sama. Semua email di Magento 1.9.1 dikirim ke semua pelanggan dengan pesanan terbuka (pemrosesan atau pending). Saya belum menemukan solusi berbasis peristiwa atau solusi apa pun dalam hal ini. Saya sudah mencoba solusi Anda tetapi tidak berhasil. Di app / code / local /, saya tidak memiliki folder / file berikut: Namespace / EmailQueueFix / etc / config.xml Namespace / EmailQueueFix / Model / Sumber Daya / Email / Queue.php Jadi saya membuat folder dan file dan menyalin kode yang Anda tulis. Namun itu tidak menyelesaikan masalah. Apakah Anda membuat folder / file di atas atau sedang m
JK9

HI, kodenya adalah ekstensi, jadi sudah benar bahwa Anda harus membuat folder / file secara manual. Apa yang dilakukan kode ini adalah: setiap kali magento-cronjob menghapus semua pesan yang dikirim dari tabel database core_email_queue, kode ini juga menghapus semua penerima pesan-pesan ini. Jadi, pada dasarnya, itu tidak berhasil untuk Anda karena tugas cronjob ini harus dijalankan setidaknya sekali sebelum mulai berlaku.
simonthesorcerer

Jawaban:


7

Perhatian!

Apa yang dilakukan kode ini adalah: setiap kali magento-cronjob menghapus semua pesan yang dikirim dari tabel database core_email_queue, kode ini juga menghapus semua penerima pesan-pesan ini. Jadi, pada dasarnya, itu tidak bekerja untuk Anda sampai tugas cronjob ini berjalan setidaknya sekali.

Larutan

Saya menemukan jawabannya berkat pertanyaan lain di sini: tabel core_email_queue_recipients tidak dikosongkan oleh cronjob. Metode Mage_Core_Model_Email_Queue::cleanQueue()panggilan Mage_Core_Model_Resource_Email_Queue::removeSentMessages(), yang cukup sederhana:

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

Bagaimanapun, metode ini tidak menghapus penerima lama. Dengan demikian, segera setelah pesan baru dengan message_id n di-antri, semua penerima lama dengan message_id n juga akan mendapatkan email baru. Hal yang saya tidak mengerti adalah: mengapa tim inti tidak melihat ini, dan mengapa ini tidak menyebabkan lebih banyak masalah?

Saya menulis modul kecil untuk memperbaikinya. Ini menggunakan class override untuk Mage_Core_Model_Resource_Email_Queue, jadi jika ada yang bisa menyarankan solusi yang lebih baik (berbasis acara?), Saya akan senang.

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 / Sumber Daya / 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

Saya telah memposting perbaikan berbeda yang tidak perlu menginstal modul baru, dan mungkin sedikit lebih bersih.

Itu hanya menggunakan batasan kunci asing pada tabel core_email_queue_recipients untuk menghapus catatan Penerima pada kaskade.

Dengan menggunakan kunci asing baru ini, tidak ada catatan anak yatim yang akan ditinggalkan di tabel core_email_queue_recipients saat membersihkan tabel core_email_queue , sehingga tidak ada pesan duplikat yang akan dikirim lebih lanjut ke penerima yang salah.

Anda dapat menemukan solusi terperinci pada posting ini: https://magento.stackexchange.com/a/87299/23057


IMO ini adalah solusi yang lebih bersih dan kunci asing harus dimasukkan secara default.
micwallace

1

Ini adalah masalah indeks dalam basis data. Anda dapat memperbaikinya dengan alat perbaikan basis data Magento .

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

Masalahnya menyebabkan saya sangat frustrasi. Dalam kasus saya itu berasal dari peningkatan versi. Ini adalah praktik yang baik setiap kali Anda melakukan peningkatan versi untuk melakukan instalasi bersih di direktori lain dan dalam database referensi kosong baru dan kemudian menggunakan alat untuk membandingkan bahwa struktur dan indeks dalam database Anda dinyatakan sebagai dalam kosong baru database referensi. Struktur ini adalah apa yang dibutuhkan versi baru! Sadarilah bahwa masalahnya bukan indeks yang buruk dan tidak dapat diselesaikan dengan pengindeksan ulang. Lebih banyak adalah masalah indeks yang hilang seperti yang saya lihat. Selalu simpan salinan cadangan dari basis data sebelum menjalankan alat!Sangat disayangkan bahwa bahkan jika Anda menginstal ulang Magento, indeks dan verifikasi struktur database tidak diberikan sebagai opsi dan Anda harus mengikuti prosedur di atas. (dalam kasus saya ditingkatkan dari versi 1.8 ke 1.9).

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.