Release notes — Conviro AI Chat for Magento 1.4.1
Status: released 2026-09-27 (repo.conviro.io). The backend needs migration 0232, applied before the API deploy. 1.4.1 is a hardening release built from the first production store's field report after its 1.3.4 → 1.4.0 upgrade (2026-09-26). Upgrading from 1.3.x? Read Release notes 1.4.0 and the Upgrade guide first — everything there applies.
Upgrade
The admin's "update available" notice shows the command for your store — its Magento mode and the locales a static deploy must build. Production mode, as the owner of the Magento files (never root):
bin/magento maintenance:enable
composer require 'conviro/module-aichat:^1.4.1'
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f en_US <your store locales>
bin/magento cache:flush
bin/magento maintenance:disable1.4.1 changes class constructors: in production mode the compile and the static deploy are required. There is no --keep-generated in this in-place sequence any more (the first 1.4.1 draft of the docs had it before the compile — that would run the new data patches against the old compiled code); it belongs to release-directory upgrades. Each step, failure handling and rollback.
Rollback: before setup:upgrade ran, restore the previous code and compile; after it ran, restore the database backup together with the old code (Magento refuses older module code against a newer schema version). 1.4.1 adds no table or column; its data patch only inserts a configuration row where a Lead Form Key exists (see below), so a 1.4.0 database is unchanged otherwise.
What changes for you
| Area | 1.4.1 |
|---|---|
| Upgrade command | Built for your store: mode (production / default / developer) and the locales of every active store view and admin user (+ en_US). No --keep-generated in-place. Conviro's own notice to 1.3.x stores carries the same sequence. |
| Cron | The delivery and connection jobs record their own last run / last success / last failure. Admin system message when cron has not run the delivery job for 10 minutes, or an event waits 15 minutes while cron runs — never for a store with nothing to send. The store reports its delivery health to the Conviro dashboard every 15 minutes. Cron troubleshooting |
| Cart recovery / payment assist held since 1.4.0 | The admin message now opens a page that confirms only the features you tick — it starts no sync and changes nothing else (the wizard's step 5 Save also starts the initial sync jobs). |
| Widget loading | New Load the Chat Widget: on the first interaction (default; tap, click, key, scroll or focus, at the latest after 4 s), when idle, or immediately (1.4.0). A keyboard user's first key loads it at once. The widget bundle's build id is cached in the browser (no version.json request on most page views; a release reaches visitors within 30 minutes). Theme hook conviro:before-init (appearance only). Widget loading |
| Lead form | New Lead Form Placement: only where embedded (default for new installs), on every page, only inside the chat widget, or off. An upgraded store keeps what it had: where a Lead Form Key was saved, the upgrade saves on every page. One lead-form script per page (1.4.0 loaded it twice when a form was both embedded and on every page). |
| Theme overrides | The health card finds theme overrides of the Conviro widget (template, loader, layout) and says whether they bypass the module's loader and its security fixes. Check storefront reads the page visitors get and checks the widget configuration, the loader (and that the served loader is this release — a missed static deploy shows here), and a second widget start. Storefront widget row |
| Checkout safety | No Conviro observer can throw into order placement, checkout or a save (all 16 wrap their whole body). Skipped events are counted and shown (Skipped events row). payment.failed is no longer sent for an order that was created (another module's error after the order was saved is not a failed payment). |
| 4-byte characters | Emoji and other 4-byte characters in product / customer names survive Magento's utf8mb3 tables and connections (2.4.4–2.4.6): stored as JSON escapes, sent to Conviro unchanged in meaning. No table is converted. |
| Conviro's network protection | A Cloudflare challenge is recognised as such — not as "the key lacks a scope" — events are kept and retried, the OAuth migration keeps retrying. Every call carries User-Agent: Conviro-Magento/<version> (Magento <version>; +https://useconviro.com). Troubleshooting |
| Diagnostics bundle | Lists every Conviro cron job, including the two retention jobs. The bearer-token row's own instruction ("… = No.") is no longer masked as if it were a secret. |
| Package | The Composer zip no longer contains Test/. |
Conviro side (deployed separately, before or with 1.4.1)
- Webhooks from Conviro to your store: a redirect (3xx) is a failed delivery and is never followed — 1.3.x modules answered every webhook with a 302 and the old sender re-posted it to your home page (details). Failures are classified (redirect, auth, challenge, not found, server, timeout, DNS …); an endpoint that keeps failing is paused, Conviro's operators are alerted, the dashboard shows it with Verify and resume, and a re-registration of the store re-checks it (resumed only on a 2xx). Retries are spread out and stop after 48 hours.
- Dashboard: the Magento store card shows Delivery health — the webhook state, the store's cron / queue report, and an update warning for 1.3.x.
- Backend migration
0232_webhook_delivery_health.sql(idempotent, no data writes).
Permissions and routes
No new ACL resource. New admin routes: conviro/consent/index and conviro/consent/confirm (Conviro_AiChat::setup), conviro/health/storefront (Conviro_AiChat::config). New Conviro API route used by the module: POST /api/magento/module-health (scopes kb:write or magento:module).
Not tested / known limits
See the PR description and the plan's status block for what was measured on which Magento version: install-tested on 2.4.4-p13 (PHP 8.1), 2.4.7-p4 and 2.4.9 (PHP 8.4, also with the Hyvä default theme); 2.4.6 and 2.4.8 checked statically only. Not tested: Hyvä Checkout (no licence), Varnish, Redis, 2.4.7-p9. On 2.4.9, cache:flush did not remove the full-page cache written before the upgrade — see the old widget after an upgrade.