When Cloudron updates the WordPress app, would it reinstall an enable SMTP Mailer?

[crazybrad]

@marcusquinn I am late to this thread and have no experience with Wordpress Developer on Cloudron, just Wordpress on other platforms, so my suggestions here might be irrelevant...

(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!

[marcusquinn]

I gave up — and have spent an unwelcome amount of time jumping through infinite hoops to setup Amazon SES (against my wishes to use any FANG tech on my personal site - but its the only external option that doesn't have an additional monthly subscription overhead), FluentSMTP works with it and nicely documented setup.

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".

[micmc]

@nebulon said

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

[marcusquinn]

@micmc Currently you can turn off the SMTP Mailer installation, and reinstallation and activation, but then it means you have to setup sendmail credentials for every new WordPress (Developer) app installed, it's just extra werk and things to remember, taking time away from developing with what would otherwise be a one-click setup.

[micmc]

@marcusquinn Yeah, I know

[james]

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

[marcusquinn]

@james It may just be one of those things that remains forever unsolved, as it's an opinionated feature, so my thread is one of attempting to sway that opinion to what I believe would be a better way

[micmc]

@james said in When Cloudron updates the WordPress app, would it reinstall an enable SMTP Mailer?:

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...

[imc67]

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)

[micmc]

@imc67 said in When Cloudron updates the WordPress app, would it reinstall an enable SMTP Mailer?:

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 ...

[jdaviescoates]

Just using Fluent SMTP sounds like a good option given how everyone here seems to speak so highly of it.... although I can't help notice there haven't been any updates since Feb

[marcusquinn]

@jdaviescoates Might just be nothing to update. I expect they are attentive to it, as so many of their other plugin clients will use.

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.