Mumara Campaigns 7.1
Release Date: TBD 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. 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.
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 |
| 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 |
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.
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.
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
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.
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.
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.
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 July 17, 2026