README

Turn "sold out" into a waiting list. Product pages that cannot be bought show Notify me when it's back. Visitors confirm their address by email; logged-in customers are on the list in one click. When the product is back, they get an email.

Selling unique or small-batch items? Stock Alert Pro lets customers follow a kind of product — "new Oolong", a category, a brand — plus a fair queue for unique items, price-drop alerts and a demand dashboard.

Status: 1.0.0 (stable). Security-reviewed and lifecycle-tested on Shopware 6.7.15 (update, install, uninstall with and without keeping data).

Features

Notify me under the buy area of products and variants that cannot be bought (same rule as Shopware's buy button — backorderable products never show it).
Double opt-in for visitors; a logged-in customer's own address counts as confirmed.
Unsubscribe link in the confirmation mail and on the "you're on the list" page (signed link, no account needed); the back-in-stock mail is the last mail and closes the request by itself.
Back-in-stock mail: as soon as the product can be bought on the customer's sales channel again, one email per confirmed subscriber — right after Shopware recalculates availability, with an hourly safety net for imports that bypass Shopware; oldest subscribers first, never twice.
Flow Builder events stock_alert.confirmation_requested, stock_alert.subscribed and stock_alert.product_available, with default flows for the confirmation and back-in-stock mails — edit the mail in Settings → Email templates, the flow in Settings → Flow Builder, or add your own actions.
Bot protection with the storefront captchas you already use (honeypot, basic captcha, reCAPTCHA) plus a rate limit per IP and a limit on confirmation mails per address.
Privacy by design: confirmation tokens stored only as hashes, the answer never reveals who is on which list, link pages never indexed or cached and send no referrer.
Admin: Catalogues → Stock alerts lists every request (search, status filter, delete) and the most wanted products; the product page shows "N customers are waiting". Own ACL roles.
Optional Notify me label on sold-out products in listings.
Retention built in: closed requests deleted after 30 days, expired confirmations at once, waiting requests after a configurable period (default 180 days).
Per sales channel settings; English, Dutch and German.

Requirements

Shopware 6.7 (tested with 6.7.15), PHP 8.2 or newer
A working mail setup

Installation

composer require tenbruggencate/stockalert-lite
bin/console plugin:refresh
bin/console plugin:install --activate TenBruggencateStockAlertLite
bin/console cache:clear

The default flow is ready right after install. Theme overrides of the buy_widget_buy_form block must call {{ parent() }} for the form to appear.

Uninstall

plugin:uninstall --keep-user-data keeps subscriptions, mail templates, flows and configuration. Without the flag all of it is removed.

Security

What the plugin does to protect shoppers and the shop (details and the threat table in SECURITY.md):

Double opt-in: an address that is not a logged-in customer's own only ever gets the confirmation mail until it is confirmed; confirmation mails are limited per address (3 at once, then 1 an hour, at most about 10 a day), whatever the IP.
Tokens: 256-bit random confirmation tokens, only their SHA-256 stored, valid 7 days, single use, bound to the sales channel.
Links never act on GET: confirm and unsubscribe pages show a button; only the POST changes anything, so mail scanners cannot confirm or unsubscribe. Link pages send no-store, noindex and no referrer.
Unsubscribe links are signed with HMAC-SHA256 under the shop's APP_SECRET and checked in constant time. Rotating APP_SECRET invalidates links in mails already sent (the request then simply waits until retention removes it).
No enumeration: the form gives the same answer for new, pending and confirmed addresses.
No personal data on cached pages: the product page never prints the customer's address; a logged-in customer leaves the field empty to use the account address.
Admin: the request list needs the ACL role Stock alerts → View (delete: Delete); the API never exposes confirmation tokens.
GDPR: retention task, delete per request in the admin, and deleting a customer account deletes that customer's requests.

Known limits: no List-Unsubscribe header (there are no recurring mails); a logged-in customer who subscribes with their own address gets no mail until the product is back, so they withdraw via the shop (or by deleting their account). The per-IP limit needs correct TRUSTED_PROXIES behind a proxy or CDN.

Report vulnerabilities privately to guy@tenbruggencatedevelopment.nl; see SECURITY.md.

tenbruggencate / stockalert-lite

Package info

Security

Statistics

README

Features

Requirements

Installation

Uninstall

Security

More from Ten Bruggencate Development