FluentCRM 3.1 is here

Jim Patton You can read this article: https://fluentcrm.com/blog/fluentcrm-mcp-and-what-it-means/ or watch this video: https://www.youtube.com/watch?v=VtBU8MMYFnQ

Nazir Himel I tried to follow the guide but for me, the application password section in my admin profile is not shown, and I don't know how to activate it. So it's not possible to create the password. All the plugins are updated and fluentkit installed. Any advice?

Fabio Pinna The "Application Passwords" section is typically located at the very bottom of your Users > Profile page, right below the account color scheme and above the "Update Profile" button.

If you cannot see it, this feature has likely been disabled or hidden by your hosting environment or a plugin. You can resolve this using the steps here: https://developer.wordpress.org/advanced-administration/security/application-passwords/

Nicholas Boyes-Hunter we have kept all the hooks and functions as backward compatible so your custom codes should not break. But I would suggest this: update in a staging and do a quick test of your custom integrations.

Sifiso Madwayi We have added WP Native AI option as well which has OpenRouter Connected addon: https://wordpress.org/plugins/ai-provider-for-openrouter/ (developed by Automattic employees). So you can use that for the connector and use the native WP option in FluentCRM.

Nikola Belopitov, I published a full doc explaining why your email sending speed slows down. The basic rule is: If your server-side cron runs correctly, the speed depends on your actual email-sending service's per-second HTTP round-trip timing.

More details here: https://developers.fluentcrm.com/modules/email-sending-speed.html

So enable multi-thread email sending can speed up the sending.

Shahjahan Jewel Thanks Shahjahan, but I've read that doc carefully and tested every lever in it, and respectfully it does not explain my case — it actually points the wrong way.

The doc's logic is "if cron runs and the server has headroom, speed = your SMTP's per-email round-trip." On my setup that round-trip is ~0.05s (Elastic Email API, EU region, same region as my server — I measured it with curl). By that logic I should be flying. I'm not. CPU sits ~80% idle the entire send. Not cron, not memory, not SMTP latency, not server resources. The only variable that changed is 2.x → 3.x.

The hard numbers, same hosting, same SMTP, same config, only the plugin version different:

• 2.x: ~220/min, smooth — a 28k campaign cleared in ~2 hours.
• 3.x: ~40/min with 8 parallel CLI workers; ~6/min on plain cron.

A campaign that took 2 hours now takes most of a day. That's the regression Nikola and I are both describing.

On "enable multi-threading" specifically — I did, and I tested it hard. On my host (Cloudways Autonomous, managed Kubernetes) it's a mirage: it fires a few real bursts (peaks of 500-760/min for 2-3 minutes), then dies and drops to ~5/min and won't restart. The spawning model uses loopback/AJAX requests, and on a containerized host where web and cron run in separate pods, those spawned workers get reaped before they finish. Emails get claimed into "processing," the worker dies, they fall back to pending, and it loops without sending. Multi-threading doesn't fail loudly — it just quietly stops carrying the campaign after the first couple of minutes.

I also tried raising mailer_multi_thread_chunk_size, action_scheduler_queue_runner_concurrent_batches, the AS time limit and batch size. None of it changed anything — which matches what Fabienne found on her near-identical Cloudways setup. The bottleneck isn't batch size; it's per-email connection setup and the spawning model.

So the real question, honestly: what changed in the sending path between 2.x and 3.x? 2.x did 220/min on this exact box with no tuning at all. If the answer is HTTP keep-alive / connection reuse, that would explain everything and it's the fix that matters — far more than any batch-size knob. I've been on FluentCRM for nearly 4 years and I'd much rather stay than move back to an external ESP, but at 3 days for a campaign that used to take 2 hours, that's the math I'm currently being forced into.

Shahjahan Jewel Update — I just rolled back to 2.9.86, and the result settles the question for my setup.

Same server, same SMTP, same Elastic Email account, same config. The only change was the plugin version.

The same ~25,000-subscriber campaign that crawled for hours/days on 3.1.0 completed in 39 minutes on 2.9.86. Measured directly, first email to last.

And here's the key part for the multi-threading point: on 2.9.86 the built-in multi-threading just works — fluent_crm_send_multi_thread_emails tasks run cleanly through Action Scheduler, no manual CLI workers needed. On 3.1.0 the same multi-threading was effectively a mirage on my Kubernetes host: it would burst for 2-3 minutes, then the loopback-spawned workers got reaped and it stalled, rows cycling between processing and pending. That's why I was forced into manual CLI workers in the first place — and even those only hit ~40/min in bursts.

So the doc's advice ("enable multi-threading") is exactly what I had enabled. The problem isn't that it's off — it's that the 3.x multi-threading model doesn't survive on this hosting, while the 2.x one does.

One more concrete data point: at high send rates on 3.1, FluentSMTP logged hundreds of cURL error 28 (connection timeout) entries — consistent with a new HTTPS connection per email instead of connection reuse. On 2.9.86 sending the same volume, this isn't happening at the same scale.

I genuinely want to help here, not just complain — I have full diagnostics (SQL, send-rate measurements, server load, the cron logs) and I'm happy to share whatever would help engineering pinpoint what changed in the 3.x sending path.