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

[jdaviescoates]

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

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?

[marcusquinn]

@jdaviescoates Already explained why this is not a time-efficient solution. What might work once as an inconvenience, doesn't work at scale, with many instances. Just unnecessary extra work for every instance. Time is not for wasting on jumping unnecessary hurdles to make something work, that shouldn't be breaking.

[marcusquinn]

Another WordPress, another forced madness with trying to remember all the sites that have FluentSMTP setup, but the unwanted SMPT Mailer reinstallation, and reactivation then stopping FluentSMTP from working.

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

[girish]

@marcusquinn I have a workaround for you till we implement the mail relay feature. Put this in the cron section of the app:

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

[marcusquinn]

@girish Thanks. Will give it a go. I have a mixture of apps where I've setup Fluent, and those which do still have the default SMPT Mailer, so gonna have to be better at remembering which, and making this a part of my routines.

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.

[jdaviescoates]

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

so gonna have to be better at remembering which

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

[marcusquinn]

Looks like restarting the app also resets any changes to SMTP Mailer settings, so from name keeps going back to "WordPress".

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

[girish]

@marcusquinn can you try setting the name at https://docs.cloudron.io/apps/#mail-from-address ?

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

[marcusquinn]

@girish Can I just ask again for reconsideration of Fluent SMTP to just replace SMTP Mailer?

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.

[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