Double Opt-In Newsletter Subscription for OpenCart

Stock OpenCart treats the tick box itself as consent. A customer ticks “Subscribe to newsletter” during registration, and customer.newsletter = 1 appears in the database immediately. No confirmation, no date, no trace of where that consent came from. An address someone typed into a stranger’s registration form can’t be removed from the list, and there’s nothing to prove the person actually agreed.

This module turns that tick box into a request. The flag only goes up after the person clicks a link from their own inbox — and that’s when a consent record appears in the database, complete with a timestamp, source, and IP.

What the buyer sees

In the footer (or wherever you place the form) — an email field, optionally a name field, and a button. After submitting, the person immediately sees: “Almost done — check your inbox and follow the link in the email. We won’t send you anything until then.”

The email itself has one action — a confirmation link. Clicking it opens a store page in your theme (using the standard common/success template, so the look inherits from the theme) reading “Subscription confirmed”. A short welcome email follows, already containing a one-click unsubscribe link.

If someone enters an address that’s already confirmed, they see “This address is already subscribed” — and get no further email. That’s deliberate: otherwise anyone could flood a stranger’s inbox with “confirmations” just by typing their address into the form.

What the admin gets

A dedicated subscriber grid in the module settings: address, name, status (pending / confirmed / unsubscribed / error), source (form, account, admin, import), language, IP, request date, and confirmation date. Filters by status, source, address, and period.

A “Resend” button for anyone who hasn’t confirmed. CSV export of all confirmed addresses — together with proof of consent (source, IP, both dates), in UTF-8 with BOM, so Excel doesn’t mangle names into garbled characters.

Per-status counters are always visible, so you see the real size of the list, not “how many people once ticked a box”.

How it works, step by step

1. Someone leaves an address — in the module’s own form or via the stock tick box at registration or in the account area.
2. A row is created in a dedicated table with status “pending”, a token, IP, user agent, language, and source. If the tick box was used at registration, the module pushes customer.newsletter back to 0 — until there’s consent, there’s none in the database either.
3. A confirmation email goes out in the language of the storefront version the request came from.
4. Clicking the link moves the row to “confirmed”, records the date, and raises the stock customer.newsletter flag, so the rest of the store sees the same picture.
5. After a configured number of hours, anyone who hasn’t confirmed gets exactly one reminder. The row is marked “reminded” regardless of whether the email actually arrived, so a dead address doesn’t loop forever.
6. Unconfirmed requests older than N days are deleted automatically. An address that never confirmed isn’t a subscriber, and there’s no reason to keep it indefinitely.

Unsubscribing works in one click from any email: following the link moves the row to “unsubscribed”, lowers the stock flag, and (optionally) sends a short confirmation, so the person keeps written proof.

Under the hood

A single dedicated table, cc_news_subscriber: one row per (store, address) pair, with status, token, and proof of consent. A unique key on the pair prevents duplicates, and a repeat request from the same address revives that same row with a new token — so the link from an old email stops working.

The token is 48 hexadecimal characters from random_bytes. The same token serves both confirmation and unsubscribing: once confirmed, it deliberately doesn’t change, because it’s exactly what the “unsubscribe” link in every future email relies on.

Form protection is a hidden honeypot, out of the document flow and off the tab order, plus a signed timestamp (an HMAC over the installation’s own parameters) that can’t be rewritten client-side. The stamp is valid for 24 hours, so the form survives full page caching. On top of that, there’s a per-IP hourly request limit and, optionally, the store’s own captcha.

Email texts live in a library rather than language files: an email is built from three different contexts (storefront, admin, scheduled run), and the email’s language is the subscriber’s language, not the language of the current request. An empty template field always falls back to the built-in text, and an unknown language falls back to English.

The module doesn’t touch a single core file: it works through OpenCart’s standard events and its own storefront routes.

Installation

1. Extensions → Installer → upload the zip.
2. Extensions → Modules → find “Double Opt-In Subscription” → click “+”. This step creates the table and registers the events and scheduled task.
3. Open the settings, enable the module, and save.
4. Insert the form wherever needed in the theme: {{ cc_newsletter }} in any Twig template.
5. If the store already has subscribers via the stock tick box, click “Import existing subscribers”. Import runs once, manually only: it enrols them as confirmed, because the store already considers them subscribers, and it never brings back anyone who unsubscribed.