Mumara Campaigns 7.1
Release Date: August 20, 2026 (Beta) Type: Minor Release Previous Version: 7.0.5
Version 7.1 is a reliability and performance release focused on segment operations. Interrupted exports, copies, and moves no longer freeze forever — they recover automatically and resume from exactly where they stopped — and exporting, copying, and moving have all been re-engineered to handle very large audiences (tens of millions of contacts) at a steady pace without straining the server. It also hardens contact importing — "Skip duplicates" now reliably skips duplicates found within the imported file, the "Overwrite" option no longer gets stuck or loses contacts on large imports, and imports no longer get stuck at 100% when a spreadsheet cell contains a line break. Automation triggers that had silently stalled on long-running servers now recover automatically. It also adds an optional multi-server (cluster) mode that keeps Application Settings in sync across every server in a load-balanced deployment, makes scheduled background tasks cluster-safe (they run on exactly one server at a time), and fixes background hooks that were silently skipped on the Redis queue driver. Finally, it hardens internal security — the endpoint the application uses to trigger its own background tasks now accepts only signed internal requests — and cleans up leftover pre-update page files that could cause errors on updated installations.
Highlights
| Area | Summary |
|---|---|
| Segment exports | Interrupted exports recover automatically within minutes and resume where they stopped — no more exports frozen at "10%" |
| Segment copy & move | Interrupted copy/move operations also recover and resume automatically — with no duplicated and no skipped contacts |
| Copy & move performance | Copying or moving a segment is dramatically faster and no longer pins the server — contacts are processed in efficient batches instead of one at a time |
| Viewing a segment's contacts | The contacts page loads almost instantly even for very large statistics segments, instead of hanging and failing to load |
| Segment recipient counts | Activity-based segments (opens/clicks/sends) now count each contact once instead of once per event — no more inflated recipient totals |
| Very large audiences | Export progress advances at a steady pace regardless of size; exports of tens of millions of contacts are now practical |
| Export lifecycle | Starting an export survives leaving the page; cancelling one cleans up completely and never blocks other segment operations |
| Import — skip duplicates | "Skip duplicates" now reliably skips duplicates that appear within the imported file, and each list guarantees one contact per email address |
| Import — overwrite & update | "Overwrite" no longer gets stuck or loses contacts on large imports; "Overwrite" and "Update" refresh contacts in place and keep their history |
| Contact import | Imports no longer get stuck at 100% when a spreadsheet cell contains a line break (common in Excel / Apple Numbers exports) |
| Multi-server deployments | New optional cluster mode keeps Application Settings in sync across every server behind a load balancer — a change on one server applies to all within a minute (off by default; no effect on single-server installs) |
| Cluster-safe scheduled tasks | In multi-server deployments, scheduled tasks that work on shared data now run on exactly one server at a time — no more duplicate preparation or duplicate notifications |
| Background hooks | Background hooks and automations now run reliably on every queue driver — previously they were silently skipped on Redis |
| Automation triggers | Triggers could silently stop sending emails on servers with long uptimes — affected installations recover automatically within minutes of updating |
| Import — Map Fields | The Map Fields step opens immediately even on files with millions of rows, instead of timing out while counting records |
| Force secure tracking URLs | New admin option generates all tracking links over HTTPS and locks every domain's "Use Secure URL" switch on — users can no longer downgrade tracking links to plain HTTP |
| Update reliability | Updating or optimizing an installation no longer fails with a "directory does not exist" error on deployments missing an internal views folder |
| Export queueing | A single long export no longer silently holds up every other export, copy, and move on the installation — and waiting jobs are no longer shown as running |
| Segment counts | A segment's contact count no longer freezes permanently after an interrupted background recount |
| Log retention | "Delete campaign logs after (days)" now also clears rows left behind by skipped or failed recipients, so the table no longer keeps growing |
| Log cleanup speed | Campaign log cleanup is dramatically faster and lighter on the database, and no longer competes with active sending |
| Scheduled maintenance | Maintenance runs can no longer stack on top of one another and place avoidable memory pressure on the database server |
| Security hardening | The internal background-task endpoint now accepts only signed, short-lived internal requests — it can no longer be used from outside to run maintenance commands |
| Updated-install cleanup | Leftover page files from older versions no longer override redesigned pages — fixes the View Broadcasts database error and other stale-layout surprises |
| Listing pages | Per-column search no longer causes a server error, and column sorting is more robust across the application's listings |
Before You Update
7.1 is a minor release with no breaking changes. A short background migration runs automatically during the update — there are no manual steps.
How to Update
Navigate to Tools → Update in the admin panel, choose your update channel (Stable is recommended for production), and click Begin Update. You can review the full changelog for the version you're about to install right on that screen before you begin.
Take a quick database and files backup before updating. It costs nothing and gives you a clean rollback path.
Server requirements are unchanged from 7.0.5 — PHP 8.4 (with 8.3 and 8.5 also supported).
Segment Exports
Stuck exports recover automatically — and resume, not restart
A segment export whose background worker was interrupted — by a server restart, a timeout, or a process being killed — could previously freeze at its last progress value (for example 10%) and never move again, with no way to complete it short of cancelling and starting over.
Exports are now fully resumable:
- The export continuously records how far it has gotten while it runs.
- If the worker dies, an always-on recovery process notices within minutes that the export has stopped making progress and puts it back in the queue.
- The next processing run picks up the same file and continues from exactly the contact where the export stopped — everything already exported is kept, the progress bar resumes from where it froze, and the finished file contains every contact exactly once.
Exports that were already stuck before this update are recovered automatically as well — no manual intervention needed.
Re-engineered for very large audiences
Exporting has been overhauled so that it scales to the largest databases:
- Steady pace from start to finish. Previously, each step of a large export became slower the deeper into the export it got, which is why very large exports appeared to crawl and then stall. Progress now advances at a constant pace whether the export is at contact 20 thousand or contact 20 million.
- Dramatically lighter bookkeeping. Progress tracking and custom-field lookups now happen once per batch instead of once per contact, cutting thousands of database round-trips out of every batch exported.
Together with automatic resume, this makes exports of tens of millions of contacts practical.
Copy and move recover the same way
Copying or moving a segment to a list had the same weakness: an interrupted operation froze at its last progress value with no way to complete it. Copy and move now use the same automatic recovery:
- Progress is recorded as the operation runs, and an interrupted copy/move is picked back up within minutes and resumes from the exact contact where it stopped.
- Each batch of contacts is committed all-or-nothing, so an interruption can never leave half-copied batches behind — after recovery the destination list contains every contact exactly once, with no duplicates and no gaps, regardless of which duplicate-handling option was selected.
Copy and move are dramatically faster
Copying or moving a segment previously processed contacts one at a time, with a long chain of per-contact work behind each one. On larger operations this made progress crawl and could drive server CPU usage to 100% for the duration.
Copy and move now process contacts in efficient batches:
- A copy that previously crawled for hours now completes in a fraction of the time, and server load stays normal while it runs.
- The operation scales to very large audiences, the same as exporting.
- The activity log is no longer flooded with a separate entry for every copied contact — the operation itself is still logged, and each contact's timeline still records its arrival in the destination list.
- All duplicate-handling options (skip, overwrite, update, delete existing) behave exactly as before.
Segment recipient counts are no longer inflated
When sending a broadcast to an activity-based segment (one built on opens, clicks, or sends), the recipient count could be significantly inflated — reported as many times larger than the actual number of contacts — and preparation could mark large numbers of contacts as "Skipped."
Activity-based segments match contacts through their opens, clicks, and sends, and a contact who had, say, opened or clicked several times was being counted once for every one of those events instead of once as a person. The more engaged the audience, the larger the over-count.
Now each contact is counted exactly once, no matter how many times they opened, clicked, or were sent to. Preparing these campaigns is also faster and lighter as a result.
This was a display problem only. The actual send list was always de-duplicated, so no contact was ever emailed more than once, and no opens, clicks, or other tracking data were affected. If you paused campaigns because of the inflated numbers, they were safe to run.
Viewing a segment's contacts is fast again
Opening a segment to view its contacts could hang for minutes and then fail to load on large statistics-based segments (those built on opens, clicks, sends, and similar activity). The contacts list now pages through the results efficiently and opens almost instantly, no matter how large the segment is. The list contents, sorting, and search are unchanged — only the speed.
Export lifecycle fixes
- Starting a segment export is no longer cut short by closing or navigating away from the export page.
- Cancelling a segment export now also removes its partially-written file, and a cancelled export no longer interrupts other pending segment operations (copies, moves, or other exports) waiting in the queue.
Queued exports no longer wait invisibly behind a slow one
Exports, copies, and moves are processed one at a time. Previously, every job queued behind the one being worked on was already marked internally as running, so a single long-running job held up everything behind it — for every user on the installation, not just the person who started it — while the waiting jobs looked exactly like running ones on screen.
The practical effect was that exporting appeared to stop working altogether: jobs sat for hours producing no file and no error message, with nothing to indicate they were simply waiting their turn.
Jobs are now taken up individually, as each one actually starts. Queued work is no longer flagged as running before it begins, so it is picked up as soon as the job ahead of it finishes.
Segment counts no longer freeze after an interrupted recount
A segment's contact count is refreshed by a background recount. If that recount was interrupted part-way — by a server restart, a timeout, or the database becoming briefly unavailable — the segments it was working on stayed marked as being counted and were skipped from then onward. Their totals stayed frozen at whatever they last were, with nothing on screen to indicate the number had stopped tracking reality.
Interrupted recounts are now detected and released automatically, and affected counts resume updating on their own. The segments themselves always continued to work correctly for sending and filtering — only the displayed total was stale.
Contact Import
"Skip duplicates" now skips duplicates inside the file too
Importing with Skip duplicates selected could still add duplicate contacts — not against what was already in your list, but against the imported file itself. If the same email address appeared more than once in the file, the extra copies were added anyway.
This happened because the duplicate check only compared each incoming contact against the contacts already saved in the list. Copies of an address that were still elsewhere in the same file — including copies handled by different threads of a large, multi-threaded import — hadn't been saved yet, so they were invisible to the check and slipped through.
Two things fix this:
- The import now recognises repeats within the file itself, so Skip duplicates skips them as expected.
- Each list now guarantees one contact per email address at the database level, as a permanent backstop. An import can no longer create duplicate contacts on a list regardless of file size, ordering, or timing.
Applying that safeguard (and clearing any pre-existing duplicates) is handled by a one-time background optimization that starts automatically after you update. There is nothing to stop or start — you can keep importing and sending as normal, and your contacts stay fully usable the entire time. It also waits while your campaigns are sending, so on very large accounts it may take a while to finish quietly in the background. No action is needed.
"Overwrite" no longer gets stuck — or loses contacts
The Overwrite duplicate-handling option could get stuck partway through a large import and, more seriously, lose contacts — a list could finish with fewer contacts than it started with. On big imports (which Mumara runs on several threads at once), an internal timing conflict between those threads could interrupt Overwrite after it had already removed the old copy of a contact but before it had written the new one, leaving the import frozen at a fraction of the total.
Overwrite and Update now refresh the matching contacts in place instead of removing and re-adding them. The result:
- The import completes reliably — no freezing partway through.
- No contacts are lost — the list size is preserved.
- Each updated contact keeps its identity and history (opens, clicks, and timeline) instead of starting over as a brand-new contact.
- Overwrite still fully replaces the contact's fields and stamps it with the new import; Update refreshes only the fields you mapped and leaves the rest untouched.
Update imports of large files also no longer appear to stall: they were always working, but their progress only advanced in large steps — progress now updates smoothly as the import runs.
Imports no longer get stuck at 100% on cells with line breaks
A contact import could get stuck at 100% and never finish when a cell in the imported file contained a line break inside it — common in files exported from Excel or Apple Numbers, where a single field (such as a job title or notes) wraps onto two lines.
Previously, Mumara counted that in-cell line break as an extra contact, so the total it expected to import was slightly higher than the number of real contacts. Every contact was in fact imported correctly, but because the expected total was never reached, the import could never mark itself finished — the progress bar sat at 100% indefinitely. (For example, a file whose contacts include a few cells with line breaks would report a slightly higher expected total than the number of real contacts, so the import never completed.)
Imports now count contacts the same way they are added, so the total is always accurate and the import finishes cleanly — with every valid contact imported exactly as before. No change to your files is required.
The Map Fields step opens immediately on very large files
The Map Fields step re-read the entire file to count its records every time it loaded, which could time the page out on very large files. The count is now computed with a fast scan that produces exactly the same total the import uses, so the mapping screen opens immediately even for files with millions of rows.
Multi-Server Deployments
Application Settings now stay in sync across every server
If you run Mumara across several application servers behind a load balancer, saving Application Settings used to update only the one server that happened to handle your request. The other servers kept running on the old values until each was refreshed by hand, so a change could appear to "not stick" depending on which server a later request landed on.
The new optional Multi-server (cluster) mode removes that gap:
- Enable it once under App Settings → General (it's off by default).
- With it on, a settings change made on any server is applied to every server automatically within a minute — no manual step on each machine.
- It uses your existing shared database and shared storage; no extra services are required.
.envA few settings (queue driver, application URL/name, environment, debug) are stored
in the server's .env file rather than the database. For those to propagate too,
each server's .env must live on the shared storage — the same shared mount
your storage/ folder already uses — so a change made on one server is seen by all.
The recommended setup is to keep a single shared .env and symlink each server's
.env to it. Mumara's cluster deployment scripts do this for you: the first server
creates the shared .env, and each additional server just links to it.
This setting is meant purely for load-balanced, multi-server deployments. On a single-server installation there is nothing to synchronize, so leave it off — with it off, nothing about your install changes. Each server should already be running its scheduled tasks (cron) as normal.
For the full deployment layout — shared storage, shared .env, cache store
requirements, and how the sync works — see the new
Multi-Server (Cluster) Mode guide.
Scheduled tasks are cluster-safe
In a multi-server deployment, every server runs Mumara's scheduler. Scheduled tasks that work on shared data — campaign sending and preparation, evergreen scheduling, stuck-campaign recovery, suppression processing, segment processing and counting, credit resets, maintenance, statistics rollups, and update checks — now run on exactly one server at a time instead of on every server. This prevents duplicate work, such as a campaign being prepared twice (which could mean duplicate sends) or duplicate notifications, when several servers tick together.
Tasks that process each server's own local files (open/click tracking spools, exported-file cleanup) still deliberately run on every server. Single-server installations are unaffected.
Background Jobs & Hooks
Trigger emails no longer stall silently on long-running servers
Automation triggers could silently stop sending emails on servers with a long uptime. An internal identifier used to claim queued trigger events could exceed its storage limit, after which every queued event sat pending indefinitely with no error reported anywhere — and because campaign sending was unaffected, the stall was easy to miss entirely.
The identifier is now kept within range, and installations that were affected recover on their own within minutes of installing this update — no manual steps.
Trigger emails that queued up during a stall are sent once processing resumes. If your installation was affected for a long period, expect a burst of pending trigger emails shortly after updating.
Background hooks now run on every queue driver
Background hooks and automations — such as post-event integrations and new-user provisioning — now run reliably on installations using the Redis queue driver. Previously they were silently skipped unless the queue driver was Database or Sync, so events could fire without their follow-up work ever happening.
Queue processing intervals of 31–59 minutes now work
In cron-job queue-processing mode, an interval between 31 and 59 minutes previously matched no schedule at all, so queued jobs were silently never processed. All values now work: 1–59 minutes runs the queue every that-many minutes, and values of an hour or more are scheduled on whole-hour boundaries.
Database Maintenance
Campaign log retention now clears everything it should
The "Delete campaign logs after (days)" setting under Application Settings → General removes campaign send logs older than the period you set. Previously it only removed rows for recipients that were successfully sent. Rows left behind by recipients that were skipped or failed were never eligible, so they stayed in the database however the retention period was configured, and the log table kept growing even on installations with a short retention period set.
Those rows are now cleared as well, once the campaign they belong to has finished. Rows belonging to campaigns that are paused or still sending are deliberately left untouched — they are that campaign's remaining queue, so pausing a campaign and resuming it later is completely unaffected.
Log cleanup is dramatically faster
The routine that applies this setting was re-engineered. It now removes records directly in paced batches, rather than listing them first and then deleting them in a second step, and it no longer repeats a full pass over the table to confirm it has finished.
On installations with very large log tables the difference is substantial. The routine's regular check — which runs on every maintenance cycle, including the many where there is nothing at all to remove — goes from a heavy scan of the table to a near-instant one. The cleanup also spreads its work more evenly, so it no longer competes with active campaign sending while it runs.
Maintenance runs can no longer stack up
On installations with a large amount of data to clean up, a scheduled maintenance run could take longer than the gap until the next one. The next run then began on top of the one still in progress, and on a busy installation several heavy background processes could end up running at once, placing avoidable memory pressure on the database server.
Only one maintenance run is now active at any time; scheduled runs that arrive while one is still working are skipped. A run interrupted unexpectedly — for example by the server running out of memory — is picked up again automatically rather than blocking future runs.
The same overlap protection now also covers the background runs that process opens, clicks, and delivery tracking, so a slow processing run can no longer stack duplicate workers behind itself.
Sending Domains
Force secure (HTTPS) tracking URLs platform-wide
A new "Force secure URLs for tracking domains" option is available under Application Settings → Domains. Previously, any user could turn off the "Use Secure URL" switch on their sending domain, silently downgrading that domain's open-tracking, click-tracking, unsubscribe, and web-version links to plain HTTP — and modern inboxes and browsers increasingly flag plain-HTTP links as insecure.
With the option enabled, tracking links for every sending domain are always generated over HTTPS, and each domain's "Use Secure URL" switch stays on and locked — it cannot be turned off from the page or through direct requests. Each domain's own preference is preserved behind the scenes and applies again if you later disable the option.
Make sure valid SSL certificates are installed on your tracking domains first — domains without a working certificate will otherwise serve broken tracking links. Confirmed tracking domains that lack a certificate are prompted to install one automatically from the sending domain page.
Security
Internal background-task endpoint hardened
Mumara triggers some of its own background work through an internal web endpoint. This release replaces that endpoint's previous access check — which could be bypassed — with cryptographically signed, short-lived internal requests, restricts it to a fixed list of internal operations, and requires an administrator login for anything else, so it can no longer be used from outside to run the application's maintenance commands.
The change is fully automatic: no configuration is needed, and background tasks — including in multi-server (cluster) deployments — keep working exactly as before. Installing this update promptly is recommended.
Other Fixes
-
Updating or optimizing no longer fails on a missing views folder. On deployments where an internal views directory had not yet been created,
optimize/ view caching during an update could fail with a "directory does not exist" error. Installations and updates now create the directory automatically. -
The Initial Setup Guide no longer gets stuck at 0%. On the first page view after logging in, the guide could sit loading forever. It now loads reliably, and a missing translation that could surface as the raw text
common.label.setupinstead of "Setup" has been added. -
World-map charts render reliably. The dashboard and statistics detail pages now bundle the map-projection library their world-map charts rely on. Previously it was missing, causing a chart warning and potentially inaccurate map rendering.
-
DKIM host-name preview corrected. In Application Settings, the DKIM host-name preview for the fallback sending domain showed
._domain.instead of the correct._domainkey.while typing a custom selector or domain, so copying the previewed host produced an invalid DNS name. Display issue only — generated keys and stored records were unaffected. -
The View Broadcasts page no longer fails with a database error on some installations updated from older versions. The error came from leftover page files that pre-dated the current design and were still taking precedence over the redesigned pages. Current pages now always take priority, and the outdated leftovers are removed automatically during the update — which also prevents other screens from unexpectedly showing pre-update layouts.
-
Per-column search no longer errors. Typing into the per-column search boxes on listing pages could cause a server error; searching and column sorting are now robust across the application's listings.
-
Sending domain page display fixes. The SSL status badge no longer stretches across the full width of its section, and the certificate details no longer show an unclosed parenthesis in the days-remaining text.
-
The Issues page in the admin area no longer fails with a server error on Linux servers.
Breaking Changes
None. 7.1 is fully backward-compatible with 7.0.5 — no configuration changes and no manual steps beyond the automatic background migration.
Getting Help
If anything looks off after the update, please contact your Mumara team member with the exact error message (or a screenshot), which updater channel you used (Stable, Beta, or Specific Version), and your previous Mumara version and current PHP version. You can also visit our Support Portal or review the Troubleshooting guide.
Last updated on August 20, 2026