RKR Alert News: Notify your customers when you publish a product they were looking for

v1.3.02026/11/05

Revision of the 1.2.0 package: as delivered, no alert ever reached a customer.

Fixed

• Saving an alert from the shop (account page or product page) ended in a fatal error.
• Alerts without price limits were stored with a maximum of 0 and never matched a product.
• Emails showed the Smarty code of the template ( {$shop_name|escape...} , {foreach} ) and "Array": module mail templates are not run through Smarty by PrestaShop. The product list is now rendered by the module and the templates only use {placeholders} ; emails exist in en, es, fr, it, de and pt (other languages get a copy). The sender name and address were swapped.
• Texts saved in the back office (email subjects, intro, legal footer, widget title and text) were stored under one configuration name and read under another, so they were never used. Every key now uses RKR_ALERTNEWS_ ; the upgrade renames the old ones.
• Saving the General tab switched the whole module off.
• Category alerts never matched ( category_product has no id_shop ), only looked at direct subcategories and crashed on PHP 8 ( Category::getChildren() returns rows): the whole category tree is used now.
• A product was marked as processed before it was complete (PrestaShop 8/9 create it empty, imports add categories and stock afterwards) and was then lost for good. Products are checked once the request has saved them (also on later saves) and only when they are active, visible, named and not a draft; a product published days after its creation is still found. When only the "in stock" filter fails, the product is checked again for a week.
• Saved searches: case and accents are ignored, the words can come in any order, and "red" no longer matches "redondo" in the middle of a word only because of the substring.
• The duplicate-alert check never worked (SQL error: LIMIT 1 twice); customer matching on import had the same error.
• Shop requests used a rkr_token parameter that another Rekire module also intercepts (redirect to the home page for logged-in customers); the parameters are now rkran_token and rkran_action .
• Prices in emails sent from the cron or an import were not formatted.
• The same product could be notified several times (search + brand + category, hook + cron): notifications are unique per alert, product and channel, and one email shows each product once.
• Products that did not fit in an email (maximum per email) were marked as sent; they now wait for the next one.
• After unsubscribing or pausing an alert, queued digest emails were still sent.
• Changing the frequency or the channel of an alert in "My alerts" paused it (or resumed it).
• "My alerts" and the unsubscribe page were rendered without the theme (no header, styles or scripts).
• The unsubscribe link acted on the first GET: mail link scanners unsubscribed customers. The link now asks for confirmation.
• Digests depend on the exact time of the cron run; they are sent once per scheduled slot, whatever the cron frequency. With instant emails switched off, "instant" alerts travel in the daily digest.
• Demo data used real customers: their demo alerts could send real emails and show in the shop bell. Demo rows never reach a customer now, and removing the demo also removes their notifications.
• psgdpr export and erasure did nothing (wrong customer key, wrong return type).
• The shared "REKIRE MODULES" menu belonged to this module: every visit to the panel deleted and recreated it and uninstalling removed it with the menus of other Rekire modules.
• Employees with view-only rights could change settings, delete subscriptions, import and export customer data: every action now checks the view/edit/delete permission. In multistore, employees only see their shops.
• Changing frequency or channel in the back-office subscription list was not saved.
• Import "replace" deleted every subscription (of every shop) before checking the file; it now only replaces the shops present in the valid rows. Customers are matched in the target shop, the CSV carries id_shop , the notification history is no longer imported with foreign ids, and imported settings go through the same checks as the forms (AI endpoint and allowed groups are not imported).
• Multistore: default settings are global, labels and product names come from the right shop, email links point to the customer's shop.
• The product page button proposed the whole product name as saved search and showed the category id instead of its name; it kept working after changing combination (Classic) and opens the login page for guests.
• The "My account" link uses the markup of the theme (Classic, Hummingbird 1.x and 2.x).
• The rich text editor of the email texts was not loaded.
• The custom CSS filter could be bypassed; theme variables and custom CSS are served as a stylesheet.
• Outbound AI requests: the checked IP is the one used (no DNS rebinding), https only; an invalid endpoint no longer saves half of the AI settings.
• Animations of the bell and the product button no longer loop forever.
• Generic class names shared with other modules ( .rkr-check , .rkr-bell-wrap ) squeezed the product-page modal into one word per line and moved the bell away from its panel; the module now uses its own names.
• The frequency and channel selects of the back-office list were too narrow to read.

Changed

• PrestaShop Addons validator: no nofilter , no Context:: calls, no HTML in PHP, literal version, root .htaccess .
• Translations: es, fr, it, de and pt (XLIFF).