MailWizard v6.1.5

Release Date: August 12, 2026 Tags: FEATURES, CAMPAIGNS, TEMPLATES, EDITOR, DELIVERABILITY, BUG-FIXES

Overview

This release adds reusable Blocks — save a section of an email once and drop it into any template — and fixes the two things a campaign screen would not tell you: how long a campaign will actually take, and how to re-send to the recipients that failed without re-sending to everybody else.

It also repairs both drag-and-drop editors. They looked full-screen, but they were painting over the admin header and footer rather than replacing them: the chrome underneath stayed loaded, kept fetching, and kept swallowing clicks anywhere the editor did not cover.

Requires Core v6.5.8 or later. No database migration.

Update Instructions

pnpm updator

Then restart the backend so the campaign cron and the new admin routes are picked up. New permissions (access / view / create / edit / delete on mailwizard.block) are seeded on start; grant them to any role that should manage blocks — Super Admin has them automatically.

Added

Reusable blocks

A block is a saved row of an email — a header, a footer, a product card, a signature. Build it once in the visual editor and it appears in the editor's Blocks panel for every template afterwards.

• Added a Blocks screen at MailWizard → Blocks: create, rename, group and delete saved blocks, each edited in the same drag-and-drop editor as a template.
• Added Save as block in the template editor toolbar: pick a row of the email you are working on, name it, and it is saved. Nothing you are editing is touched.
• Added a Category that groups blocks in the panel, so a long list stays navigable.

Retry only the recipients that failed

A recipient that failed was final. The campaign completed with the failure recorded, nothing ever tried again, and the only documented recovery — setting the campaign to Stopped — resets every recipient, including everyone who had already received the email. Recovering from three bounces meant sending to the other nine hundred a second time, which is worse for your sending domain than the bounces were.

Worse, on a Completed campaign — exactly the state a campaign is in when you discover it had failures — all four controls on the campaign screen were disabled, so even that workaround was unreachable from the interface.

• Added Retry failed, which re-queues only the failed recipients and reactivates the campaign. Delivered recipients are left alone and are never emailed twice.
• Added a cap of three attempts per recipient. A mailbox that is gone answers the same way every time, and repeatedly hammering dead addresses is what damages a sender reputation.
• Added the reason each failed recipient failed and how many times it has been attempted, so you can tell a temporary outage from a bad address before retrying.
• Added a clickable failed count on the progress panel, which filters the recipient list to exactly the addresses a retry would cover.
• Changed Stop to be available again on a completed campaign — it is still the way to re-send to everybody — but it now asks first, and the confirmation says how many people would receive the email a second time.

Changed

Sending speed now states what it costs you

Sending speed is a budget per send run, and a send run happens once an hour. 1,000 recipients at speed 10 is therefore about 100 hours — four days — and nothing on the campaign form said so.

• Changed the speed field to show the projected finish time from the recipients actually still pending: "1000 pending recipients at 10/hour ≈ 100 hours (about 4.2 days) to finish."
• Added a warning under the field on a campaign that would take more than a day.
• Fixed the campaign list's description of the speed column, which used to end mid-sentence, immediately before the unit. It now states it.
• Changed the API error for an invalid speed, the API documentation, and the cron description on System → Cron to use the same wording as the form.

Fixed

The editors covered the admin chrome instead of replacing it

The template and block editors take the whole viewport, and they were getting it by drawing a full-screen surface over the admin header and footer. Those were still there underneath: still mounting, still fetching menus, notifications and settings on every open, still running the navigation dropdown, and still receiving clicks anywhere the editor's own surface did not reach.

Both editors are now genuine full-page routes — the chrome is not rendered at all — so nothing is loaded to be hidden and nothing intercepts a click. They are still behind the same licence check as the rest of the addon, and the Create forms for templates and blocks are ordinary pages that keep their navigation.

• Fixed the template and block editors overlaying the admin header and footer, which left them loading and able to intercept clicks behind the editor.