Skip to main content

Back to Changelog

Mumara Campaigns 7.0.2

Release Date: May 2026 Type: Patch Release Previous Version: 7.0.1

Version 7.0.2 is a focused patch release on top of 7.0.1. It improves how Mumara handles bad SMTPs — they are detected sooner, recovered automatically when they come back online, and no longer get stuck offline. Trigger sending also moves onto the same queue worker as broadcasts, the event-processing cron is protected against overlapping runs, and the dashboard now shows abbreviated numbers with the full value on hover.

If you're already on 7.0.1, this update is a quick patch — no schema changes, no manual steps, and no breaking changes.


Highlights

AreaSummary
SMTP ReliabilityBad SMTPs are flagged correctly, recover automatically when they come back, and aren't taken offline by broken email content
Auto-Resume CampaignsCampaigns paused because their SMTP went down now resume by themselves once the SMTP is healthy again
Trigger SendingNow runs on the same queue worker as broadcasts — more predictable and easier to scale
Drip GroupsDrip emails now skip dead SMTPs the same way broadcasts already do
Event CronProtected against overlapping runs
Dashboard NumbersTop stats and the Sending Statistics chart show abbreviated numbers (e.g. 1.2M) with the full value on hover
Securityphpseclib bumped from 3.0.51 to 3.0.52

Before You Update

Straightforward Patch Update

7.0.2 is a patch release — there are no architectural changes, no database migrations, and no breaking changes. The in-app updater handles everything.

How to Update

Navigate to Tools → Update in the admin panel, pick your update channel (Stable is recommended for production), and click Begin Update.

Always Back Up

Even for patch releases, take a quick database and files backup before updating. It's the cheapest insurance you can buy.

Server requirements are unchanged from 7.0.1 — PHP 8.4 (with 8.3 and 8.5 also supported).


Smarter SMTP Handling

The biggest theme of 7.0.2 is making the way Mumara reacts to SMTP failures correct, recoverable, and safe. A few problems were creeping in after 7.0.1 — sometimes a bad SMTP wasn't being flagged on every send path, sometimes a healthy SMTP was being switched off because of a broken email, and once an SMTP was switched off it could stay that way even after the issue resolved. All of that is fixed in 7.0.2.

Bad SMTPs are now flagged on every send path

Whenever an SMTP fails to send, Mumara is now consistent about marking it inactive — across broadcasts, drip groups, and triggers. Previously, certain failure responses on the drip flow didn't propagate to the auto-inactive system, which meant a bad SMTP could keep being tried over and over.

Broken email content no longer takes the SMTP offline

If an email itself was broken — bad HTML, missing merge tag, etc. — Mumara was treating that as an SMTP problem and switching the SMTP off. That was the wrong call: a content problem is an email-level issue, not a server-level issue. Mumara now keeps the SMTP active and clears any old "issue" entries that were created for it.

SMTPs recover automatically when they come back online

When a drip or trigger marked an SMTP inactive, it could stay marked that way even after the underlying problem resolved. SMTPs now recover automatically on the next health check — the same way broadcast-marked SMTPs already did. No manual reactivation needed.

Cleanup is now properly scoped

When the auto-recover process cleans up, it only touches the entries it created. It no longer affects unrelated entries from other parts of the app.


Campaigns Resume Automatically

If a campaign was paused by the system because its SMTP went down, that campaign now resumes automatically as soon as the SMTP is healthy again. Previously you had to step in and resume it yourself.


Trigger Sending — Now on the Queue

Trigger send dispatch has been moved onto the queue worker, alongside broadcast sends. This makes trigger sending more predictable, easier to scale, and consistent with the rest of the sending engine.

While we were there, two related improvements:

  • Skip dead SMTPs upfront. Triggers no longer waste time attempting sends through SMTPs that have already been flagged inactive — they skip ahead to a healthy one.
  • Unwedge stuck send claims. If a previous send attempt crashed mid-claim, that row would block subsequent sends indefinitely. Stuck claims are now cleared on the next run.

The drip-group listener also now skips dead SMTPs, matching the campaign behaviour and bringing all three send paths into alignment.


Trigger Details — Show More / Show Less

Trigger detail rows can now toggle the visibility of additional content (extended details that aren't needed at a glance). The list stays compact by default and expands only when you need the extra information.


Event Processing — No More Overlapping Runs

The event-processing cron previously had no protection against running twice at the same time. On busy installations, two ticks could overlap and contend for the same rows, slowing things down. 7.0.2 ensures only one tick is running at a time, so each run finishes cleanly.


Dashboard — Cleaner Numbers

A handful of dashboard widgets were displaying long raw numbers (for example, 1,234,567 in a tight stat card). 7.0.2 cleans this up:

  • Top stat numbers on the admin dashboard are abbreviated (1.2M) with the full number available on hover.
  • The Sending Statistics pie chart abbreviates numbers using the same scheme for visual consistency.
  • Number rounding now promotes the unit at the boundary — so a value like 999.999M rounds up to 1B instead of the awkward 1000M.
  • A small gauge widget conflict that was breaking certain stat displays on the dashboard has been resolved.

Other Dashboard Fixes

  • Running Processes box layout fix.

Security

  • phpseclib updated from 3.0.51 to 3.0.52 for SFTP/SSH security and stability improvements.

Breaking Changes

None. 7.0.2 is fully backward-compatible with 7.0.1 — no configuration changes, no database changes, and no API contract changes.


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)
  • Your previous Mumara version and current PHP version

You can also visit our Support Portal or review the Troubleshooting guide.


Last updated on May 9, 2026