I'm sure you know, but for anyone skipping to the end of this thread. FluentSMPT will stop working every time the Cloudron App is restarted and SMTP Mailer is reinstalled and reactivated. That's the issue this post prmarily aims to address.

I agree with @micmc ’s option 2: default plugin for Developer version

Especially because of their promise: Most importantly, this plugin is free and will always be free.
Read why it’s 100% free (always)

YES! Indeed, the thing I'd forgot to mention yes. Not just the best but free as well yes. Looking forward ...

Especially because of their promise: Most importantly, this plugin is free and will always be free.
Read why it’s 100% free (always)

Can this topic be marked as solved, or is assistance required?

Well, it is NOT "solved" so why mark it as such?
This is a serious concern and I wonder why it hasn't been taken more seriously. For example I've asked TWO simple questions which have remained ignored... Are we trying to find a solution for the BETTER of everyone or leave this GLITCH going on?

Please leave this live thank you.
Maybe you can help to have the following answered:
After reading all this thread, been thinking a few insights that might not be perfect but quite convenient.

1. Would it be possible to simply have the developer version installed WITHOUT any SMTP settings?
   That would still deliver the credentials.txt for SMTP just like with LAMP, that the developer would use to connect ANY preferred SMTP provider, just like it's done with LAMP?
   Personally, I've always did that myself and would believe it is something perfectly acceptable for a DEVELOPER version.

2. Maybe for a simple solution, why not simply consider FluentSMTP instead of the actual plugin?
   Why not?
   This is the ABSOLUTE best SMTP plugin for WordPress that can be found.

as @marcusquinn said I too believe there would be a better way...

Any insights into how to auto-detect this reliably of course helps us to improve this, but so far we haven't found any solid solution here.

And @girish
I've commented before about this, but would like to add a few things.
The points brought by @marcusquinn here in great details about the SMTP plugins are absolutely IMPORTANT and I agree with him 100% and support all the points he's brought up!

Especially as the WordPress Developer version is addressing a very particular market that you might not be aware of, and the way this kind of 'forced' SMTP plugin is implemented is much more than just simply annoying. It's a nuisance for integrator like him and me for example, who develop complex web marketing solutions using WordPress as the base platform.

I believe we should be thinking and taking action on a solution for this PROBLEM (for a developer version) in high priority. It really is a red flag because a developer can NOT elaborate an custom email marketing solution with a 'system' that would 'break' its SMTP settings, thus its running campaigns and transactional emails, each time the server reboots or the app is updated. It's just unthinkable.

After reading all this thread, been thinking a few insights that might not be perfect but quite convenient.

1. Would it be possible to simply have the dev version installed WITHOUT any SMTP settings? That would still deliver the credentials.txt for SMTP just like with LAMP, that the developer would use to connect ANY SMTP (s)he likes, just like we do with LAMP?

Personally, I've always did that myself and would believe it is something perfectly acceptable for a DEVELOPER version.

2. Maybe for a simple solution, why not consider FluentSMTP? Why not? This is the ABSOLUTE best SMTP plugin for WordPress that can be found.

Regards,
Andy

So, I'm abandoning having Email set to enabled in those Cloudron WordPress Developer Apps, while SMTP Mailer remains tied to the auto credentials for sending from the same domain/app.

Sure, I could create additional email-only Cloudron Users, and do it that way, but I figure if doing all that work, may as well use a sending service that, in theory, will have an established trust level for each IP pool to get through spam filters, and it seems to be very fast on delivery, too.

I have a fair few WordPress websites to get though, and may miss some settings, as this has created a bunch of werk, and archived apps I'll need to remember to do if I need to restore them.

Recently also had some conflict caused by SMTP Mailer, so just can't risk that happening again.

My position remains, no plugin should be forced on any WordPress Developer app. If it gets removed, it should stay removed.

Plus, no-one should really be giving clients websites without visibility of their email sending logs, which FluentSMTP conveniently and generously offers for free.

I respect what SMTP Mailer gives to the community. It's just not for me, and in my opinion, not for professional setups that need accountability, and friendly setups, with audit trails to help identify and resolve any issues with email sending.

I said to someone else recently, to the effect of: "custom code is a highway to hell - standardise everything possible the first chance you get, and send it upstream for everyone else to help oversee and maintain — because you never know how long until you get another chance to solve, or will be caught out from the technical debt at the wrong time".

(1) WP CLI has a plugin deactivate command: wp plugin deactivate <name of plugin> which perhaps can be added to a regularly scheduled cron job to allow Fluent SMTP to prevail. When a Cloudron update happens and SMTP Mailer becomes active, the cron job would deactivate it again. You can also delete plugins via WP CLI. This is not an elegant approach, just a hack that might work. Also, WP CLI can be run remotely via SSH, so if that is preferable in your environment, that can be done as well.

(2) A native Wordpress solution might be to use a plugin like WP Crontrol where you could add an event to deactivate SMTP Mailer. I don't know if there is a plugin deactivate event or if you could run a WP-CLI command as an event.

(3) Another option is a pure PHP solution driven by cron where the script would check for the existence of the SMTP Mailer plugin folder, and if found, delete it. (Note: Never tried this before, so be careful!)

Hope one of these is possible, and if not, perhaps it triggers some other ideas!

I can't see any downsides. It's been open-source for years, promises to stay free and open source, and handles all sorts of outbound email services and common APIs, with visible logs, and retry functionality for failed sends.

Every single time on every single website I keep hitting this issue where I desperately need the email logs visible and usable for setup, diagnostics, and sometimes evidence of a message.

I have a daily race against time on so many genuine life-affecting business needs, to have this one unremovable stone in my shoe while running this technology marathon just causes unnecessary pains.

Of all my years with any technologies, silent and difficult to analyse problems are just time and soul destroying.

The ripple effects of this issue are clients just silently lose sales or customers, just because a simple email wasn't delivered, and nobody knew.

We have enough genuine technical gymnastics to keep up with, and to have a solution there and working for this particular area, but then have to remember a series of hoops to jump through on every single site, and maintain them, is just such a loss of time, when we're all here to use technology to recover some precious time from all the other competing needs.

None of us have long on this planet, and we all have have so many things to solve. We have something here that is a longterm trusted solution.

Maybe SMTP Mailer was the best option at the time it was chose all those years ago, but I just don't have the mental bandwidth to keep coming back to re-setting up custom email settings per WordPress (Developer) install.

If you want to torture a busy person, just give them some trivial repeat task to do and remember, and then disproportionate pains and distractions for not doing it.

That's where I'm still at with this. I can't see how there would be any regressions, It should just be just transposing the same settings into another plugin.

Looking at package code, this is only set in plugin configuration and nowhere else. Not sure why this affects anything else .

Still don't think this plugin should be reinstalled and settings overwritten on the WordPress (Developer) app.

so gonna have to be better at remembering which

Perhapa put them intoa group called Fluent or something? that's what I'd do

Still happy to recommend FluentSMTP, though. Those email logs are super handy on knowing what's sent or not under many different circumstances where interruptions or issues can happen that would otherwise be invisible and no easy way to resend any that failed for any reason.

@reboot echo "Deactivate smtp-mailer" && sudo -u www-data -i -- /app/pkg/wp --path=/app/data/public/ plugin deactivate smtp-mailer

This disables the mailer plugin on updates automatically.

I still don't understand why we can't have the SMTP credentials set and working in credentials.txt but just not have any plugin force-fed on the app.

It feels like breaking rocks having to remember, find, and fix every instance each time

SMTP Mailer plugin is reinstalled and reenabled for everyone.

Unless, I think, you've checked this box in the App's Email settings:

You've probably shared this before, but why does doing that not work for you? Sounds like it'd lead to less hassle and work than your current scenario, no?

If you're using any other SMPT plugin, it won't be working until SMTP Mailer is deactivated again.

20 years with WordPress, many years with Cloudron. Many, many times I've found workarounds to things.

Appreciate the sentiment — but experience tells me that opportunities to improve the world rarely happen unless someone makes them happen the first time around.

It's technical debt and a time-costs. Time is too precious to have it repeatedly spent on something that could be avoided. That's the whole point of computers, to automate and iterate on wisdom, so we are free to create.

I chose Cloudron specifically for time-saving factors. It's all those little things that add up to a non-scaleable business if they aren't templated and automated out.

Automated problems are a crime against other's time.

I'm not changing the hosting setup of dozens of WordPress sites because a design flaw hasn't been solved yet.

That would be quitting — which isn't in my vocabulary.

I'm not working around this. I'm here for the long-haul, and if I see unnecessary time lost, risk, confusion, disparate solutions, it's a moral duty to stick with the problem until solved.

If the majority don't value their time as highly, or have the same issues, it doesn't mean they won't in future, or that everyone holds the same standards for auditing and time-efficiency.

Life is too short for workaround hacks that will cost more time than just solving the source of the problem:

There's a plugin being reinstalled after it was deleted.

No amount of "have you tried", "why don't you", is gonna change this fact.