Which PrestaShop versions are supported?

PrestaShop 8.0 to 8.99 (the entire 8.x branch). PrestaShop 1.7 is not supported (the actionEmailSendBefore hook exists but the per-shop activation system differs).

How does blocking work?

The module adds the actionEmailSendBefore hook which is called by PrestaShop on each email send. If the template (e.g. bankwire, order_conf, shipped) is in your block list, the hook returns false — the email is silently cancelled. Otherwise, the email goes out normally.

Which emails can I block?

All of them: bankwire (awaiting wire transfer), cheque (awaiting check), order_conf (order confirmation), payment (payment accepted), shipped (order shipped), order_changed (status changed), order_return_state (product return), account (account creation), password / password_query, contact / contact_form, newsletter, backoffice_order, refund. The 15 most common templates are proposed in autocomplete. You can also type any custom template — the module doesn't prejudge anything.

How do I enable filtering only on certain shops in multi-store?

Via the native PrestaShop per-shop activation system: in Modules → Module Manager, switch the multi-store selector to the desired shop, and enable or disable the module at that level. On shops where the module is disabled, emails are sent normally. On shops where it's enabled, the templates list applies. The list itself is global (shared across active shops).

Is there a trace of blocked emails?

Yes. Each block is logged in PrestaShopLogger with the template name and the shop ID. Visible from Advanced Parameters → Logs by filtering on "Email". Useful to verify that filtering works, or to audit what isn't sent over a period.

How do I re-enable an email I blocked?

You can disable a template (toggle) without deleting it — it stays in the list but stops being filtered, very useful for testing. You can also fully delete the template from the list. And to resume all emails everywhere, simply disable the module on the relevant shop (without touching the list).

Is there a performance impact?

The module uses the official actionEmailSendBefore hook: it's a single ultra-fast SQL query (unique key lookup on the template) executed just before each email send. The impact is totally negligible — a few microseconds per send.

Does the module impact the front office?

No, it's a 100% back-office module with no front-office impact. Pages load normally, checkout works, contact form too (unless you blocked contact in the list). Filtering acts only at the moment of any email being sent.

Why a module for this rather than an override?

The utility PrestaShop developers re-write as override on every project: cleanly cut certain emails without modifying the core, without touching templates, without breaking other modules. This module does that as a standard, in 5 minutes, without a single line of code, and remains active after PrestaShop updates.

What are the typical use cases?

Typical cases: B2B store with custom invoicing process (cut the standard order confirmation to keep only your in-house invoice); test or staging site (cut ALL emails to avoid spamming real customers from a test environment); white-label store with external email system like Brevo / ActiveCampaign (cut native PrestaShop emails to leave only those from the external system); multi-store where some shops should send the newsletter and others not.

DataFirefly Email Filter — Block PrestaShop 8 emails by template

DataFirefly Email Filter — Block transactional emails on PrestaShop 8

Block the sending of certain PrestaShop emails without override or core hack — official hook, native multi-store.

On PrestaShop, cutting the sending of a specific transactional email (the order confirmation, the payment notification, the account creation email) requires writing an override, touching the core, or installing a Rube Goldberg machine that filters by complex rules. DataFirefly Email Filter does the opposite: an admin page, a text field with autocomplete on standard templates, you type the template name (or pick from the list: bankwire, order_conf, shipped…), you click Add, it's blocked. For multi-store, you enable or disable the module shop by shop with the native multi-store selector. No override, no core hack, the official PrestaShop hook does all the work. €9, installed in 2 minutes.

PrestaShop 8.0+ Multi-store 1 hook 1 table Native logs No front config

30-day refund

12 months updates

24h support

The long version

Everything you'd want to know before you install.

A detailed look at how DataFirefly Email Filter — Block transactional emails on PrestaShop 8 works, why we built it the way we did, and the thinking behind the features above.

§ 01

The need

On PrestaShop, you have a pre-production environment that sends confirmation emails to your real customers when a test passes; or a B2B store where you have your own invoicing process and the native email is duplicate; or a multi-store where the German sub-shop sends its own newsletter via Brevo and PrestaShop emails become spam. All these cases call for the same solution: selectively cut certain emails. And all these cases end up in practice with hacked overrides that break on the next PrestaShop update.

§ 02

The module in one sentence

A list of email templates to block, managed from the back office, applied via the official PrestaShop actionEmailSendBefore hook. No magic, no hidden complexity — the native PrestaShop mechanism is used as is.

§ 03

Daily usage

You go to Modules → Module Manager, you configure DataFirefly Email Filter. A very simple page: a text field (with datalist autocomplete on PrestaShop standard templates) to add a template to block, and a table of templates already in the list with two buttons per row: toggle active/inactive and delete. That's it. No complex rules, no nested conditions — if the template is in the list, it's blocked; otherwise it goes through.

§ 04

Multi-store

The module uses the native PrestaShop per-shop activation system. To enable filtering on certain shops only, you go to Modules → Module Manager, you select the target shop with the multi-store selector at the top, and you enable or disable the module at that level. The actionEmailSendBefore hook is called only on shops where the module is active — PrestaShop handles the routing. The templates list, however, is global and shared.

§ 05

Performance and traceability

The hook executes a single SQL query: a SELECT on a unique key (the template) to check presence in the list. A few microseconds, totally negligible even on a store with several hundred emails per day. Each block is logged in PrestaShopLogger with the template and shop ID — visible in Advanced Parameters → Logs, Email filter. You can thus audit what wasn't sent, without having to dig into server logs.

§ 06

Use cases

Pre-prod / staging: add all templates to the list, enable the module — no email leaves the test environment anymore, your test campaigns no longer pollute real customers. B2B with custom invoicing: block order_conf, keep your own in-house invoice email. Multi-store with external emails: enable the module only on shops connected to Brevo / ActiveCampaign / Mailchimp, keep native emails on other shops. Store migration: temporarily block order_conf and shipped during historical import to avoid sending 5,000 confirmations by mistake.

DataFirefly Email Filter — Block transactional emails on PrestaShop 8

The short version.

Standard hook, no hacking

Minimalist interface

Native multi-store

Blocked emails traceability

Everything you'd want to know before you install.

The need

The module in one sentence

Daily usage

Multi-store

Performance and traceability

Use cases

The long list.

What's shipped.

The fine print.

License & delivery

Compatibility

What actual users say.

Reviews

Anything still unclear?

DataFirefly Email Filter — Block transactional emails on PrestaShop 8

Standard hook, no hacking

Minimalist interface

Native multi-store

Blocked emails traceability

The need

The module in one sentence

Daily usage

Multi-store

Performance and traceability

Use cases

License & delivery

Compatibility

Reviews

Modules often bought together.