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

[jdaviescoates]

Just comparing Fluent SMTP and SMTP Mailer it looks like SMTP Mailer uses slightly less memory and is a tiny bit faster too, but there isn't much in it, and overall Fluent has more usage and better ratings:

https://wphive.com/compare/plugins/fluent-smtp/vs/smtp-mailer/

Perhaps we should just change the default SMTP plugin from SMTP Mailer for Fluent SMTP?

[marcusquinn]

@girish Thanks. I wouldn't ask and be so picky normally, and maybe I'm the only one with the issue, but it is a repeat time-cost, distraction, and audit-trail issue for me, and I can see it being for others once they discover.

I get all the reasoning, but the workarounds for me to avoid the regression for each setup are a fair bit of time and remembering needs when working at pace, and I still feel there's a design-flaw that could fix it once-and-for-all. That's assuming you're OK with updates having a very slight difference in behaviour to fresh installs, of course.

My backup should all have SMTP Mailer removed, too, so again wouldn't expect to be seeing it back after a restore.

Maybe there needs to be some separation of logic and a tick-box for installing SMPT Mailer (default it to yes if you prefer) being separate from the setting for whether the app offers email sending and credentials, or not.

[marcusquinn]

@jdaviescoates I'm happy to endorse Fluent SMTP from over a year in production (and all their other plugins, the new Booking one is amazing), but don't want to force my preferences on anyone, and we never know when preferences might change from upstream or companion plugin choice factors.

My issues really are that:

1. My subsequent changes are regressing beyond my control.
2. Having email sending logs just saves a lot of unknowns in debugging and client reassurances through transparency of these.

[marcusquinn]

@marcusquinn Further, WordPress itself is such a universally needed and wanted platform, I feel it's worth the extra attention to make it a 1st-class Cloudron citizen. Hence, I put the time into detail here on feedback and suggestions, as I fully endorse anyone working with it, and choosing Cloudron to self-manage hosting.

[jdaviescoates]

@marcusquinn have you also tried https://wordpress.org/plugins/wp-mail-smtp/ ?

That does logs too and is seemingly by far the most used SMTP WordPress plugin.

Although I'd guess that both WP Mail SMTP and Fluent likely insert ads for their other plugins etc into the WP dashboard, and I'd also guess that perhaps @girish chose SMTP Mailer in part because it doesn't do stuff like that?

[girish]

Right, we used to use "WP Mail SMTP plugin"in the past but then it started showing ads on every new install. So, we then migrated to simpler "WP SMTP Mailer". Personally, I lean towards a solution where people can choose their own plugin. It's a recurring problem and I agree Cloudron can be a bit more flexible here about allowing users to choose whatever plugin they want (well, it's already possible but we should make it simpler).

[marcusquinn]

@jdaviescoates I'm not a fan of that one, same reasons as @girish noticed, a bit aggressive on the upsells, and ultimately, once I find a happy solution, I rarely revisit it. In this instance I'm happy with Fluent, and focused on the use of these features.

I agree, SMTP Mailer does the basic job, non-offensively. I just prefer Fluent for the more options to have multiple sending servers for different purposes (Transactional/Marketing), support of other sending methods (APIs), and those sending logs are very valuable to myself and clients in auditing.

[marcusquinn]

Still the same problem.

Still causing potentially disproportionately extreme financial costs from missing emails. One missing email for a client can cost thousands in lost revenue.

Still lose emails sent records until by some luck it is noticed that the SMTP Mailer plugin has forced itself upon us again.

Still no solution.

Sorry, it's not an issue that can be thought or negotiated away. It's a problem with the Cloudron WordPress Developer App functionality assumption that needs to modifying.

[jdaviescoates]

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

It's a problem with the Cloudron WordPress Developer App functionality assumption that needs to modifying.

Yeah, I think WordPress Developer should probably just be vanilla WordPress with no pre-installed plugins, but links to info in docs on how to set up whatever SMTP plugin you want in First Time Setup.

[girish]

@marcusquinn I have added a doc section now for people wanting to switch the SMTP plugin https://docs.cloudron.io/apps/wordpress-developer/#email . Disabling email auto configuration is the approach we follow for all apps where user wants to have more control over email sending.

@jdaviescoates at that point, might as well use LAMP app, no? WP developer is just LAMP+WP Latest Extracted+Auto configuration. There is nothing else there. In fact, with LAMP, you can even get choice of PHP version which WP developer does not have.

[jdaviescoates]

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

Disabling email auto configuration is the approach we follow for all apps where user wants to have more control over email sending.

I'd forgotten about that option.

[marcusquinn]

@girish Thanks, is there no way to have the SMPT sendmail credentials created in credentials.txt and still working when selecting Do not configure app's mail delivery settings?

I suppose counter-intuitive for that options label, but it's many additional steps to remember and do for every single instance without those.

Or have more options in that panel?

• Use Cloudron Mail to send emails with the SMTP Mailer plugin.
• Use Cloudron Mail to send emails with the Fluent SMTP plugin.
• Use Cloudron Mail to send emails with your own SMTP plugin choice.
• Do not configure app's mail delivery settings.

Or just two options, and a dropdown to select from these two plugins, or no plugin?

[girish]

@marcusquinn anything is possible Cloudron is designed as a platform and not optimized for WordPress as such (https://docs.cloudron.io/packaging/manifest/). This has downsides as we don't have UI which is specific to an app and specific app plugins. The options might make sense when we have optimize Cloudron for WP hosting (which atm we haven't).

Also, as mentioned in a very early post, the real workflow issue is that Cloudron lacks a way to easily create mail relay credentials. If this was there, one can avoid creating a mailbox and mail app passwords. This is in the immediate roadmap. Will have this next release.

[marcusquinn]

@girish I see the WordPress app was updated again today.

It's a choice of madnesses to me for the sake of something that just should not be happening:

1. Several extra steps in setup of every single WordPress instance in setting up separate users (no-one in their right mind should be putting Cloudron Amin User credentials in a WordPress database) and app passwords, storing all that in a password manager, using those details.

2. This merry dance or fixing something that every single Cloudron WordPress update breaks, and is clear why and how, and that it doesn't have to be this way, as it is a design choice, not a default expected behaviour of standard WP setups.

3. Manual updates, and the same fixes.

I've never heard of any WordPress hosting that would do this.

Yes, some come with default plugins — but I just cannot think of a single reason why any system would reinstall deleted default plugins.

I expect WordPress is perhaps the most popular app, and likely it's needs should be leading Cloudron design, not following.

Life is so short. There's already not enough hours to achieve everything my knowledge could, but the bureaucracy of life and systems steals time from achieving.

I can understand opt-in compromises, but not ones that have extraordinary opt-out time-costs.

If you need email working on first-install, why not just use the standard WordPress php mailer?

[girish]

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

Several extra steps in setup of every single WordPress instance in setting up separate users (no-one in their right mind should be putting Cloudron Amin User credentials in a WordPress database) and app passwords, storing all that in a password manager, using those details.

Note that the app password does not need to be saved in the password manager. You can always generate a new one if you forget, it's not important to save it (it's like an API access token). Also, it's also not an admin password, you cannot do admin ops with it. App password, by design, can be restricted to just email (the screenshot in the docs).

[girish]

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

If you need email working on first-install, why not just use the standard WordPress php mailer?

Maybe this is possible. We are not WP experts but we have @vladimir-d to help, so I will open an internal task to investigate.

[nebulon]

Actually while WordPress being WordPress is one of the most used apps, we are not designing the platform around it specifically, mostly because there are already lots of great WordPress hosting options out there, which are highly specialized for it. This is not our main goal. If full flexibility is required, I guess using the lamp app with WordPress might be preferable.

For your suggestion, what do you mean with the standard php mailer, maybe we miss something more basic here then on how to setup WordPress smtp.

[micmc]

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

Still the same problem.

Still causing potentially disproportionately extreme financial costs from missing emails. One missing email for a client can cost thousands in lost revenue.

Still lose emails sent records until by some luck it is noticed that the SMTP Mailer plugin has forced itself upon us again.

Still no solution.

Sorry, it's not an issue that can be thought or negotiated away. It's a problem with the Cloudron WordPress Developer App functionality assumption that needs to modifying.

Wanted to add that you're NOT the only one, this happens on my WP install as well where I installed FuentSMTP for which I'm also a great supporter.

The only thing is it is installed only on a few sites I'm working on for now, but yeah, I mean how many times I was like ; "f... I thought I'd disabled that SMTP Mailer ??" a few times here and there, and then I see this thread...

Indeed, that SHOULD NOT happen. I understand that the app has to have the capacity to send email with initial installation, and that yeah when you update a package it has to be completely updated as it installs. Fair enough, since there's actually no way for an update to detect if the plugins installed initially are disabled.

I think also that for the time of finding a counter measure this should be mentioned in the developer's version, so at least users are aware that if they change the SMTP plugin, they'll have to go back and RE-disable it for EACH WordPress updates!?

It's while I type the above that we must realise that it does not make much sense. And the problem I see is that for some clients SMTP plugins may be much more important than for some others, and that "setting" (as we have it now) kind of restrict the client's freedom to use a smtp plugin of choice, at least without such hassle.

There must be another way.

Meanwhile, one can implement a solution using MainWP for example, to be able to operate plugin changes on several or all your wp installations at once.

[marcusquinn]

@micmc @girish The only other solution I can see is making Fluent SMTP the new default SMPT plugin.

It's a more complete solution and versatile due to keeping sendmail logs, and having all the common API mailer connections and documentation.

Sure, it's some publicity for the other Fluent plugins, all of which I've been happy with, but others may be invested in their alternatives.

They've committed to keeping Fluent SMTP free, and it'll work just as well with any other non-Fluent plugins.

This would be your least-effort, not changing the Cloudron platform option, and least user effort or risk.

As it stands, the default app setup creates unnecessary extra setup work, awareness needs, and unless I go through all the WP instances and do all these manual things, I can't ever take a holiday.

[nebulon]

To take a small step back here. Given that all our apps are designed in a way to ensure basic settings on restart/install/clone/restore... and sending email is, like database setup a basic setting. Given the installation base we have for WordPress shows us we are doing something right here to solve this for the 90% use-cases.

Now unless we can find a way to auto-detect that a user has installed a plugin, which is some kind of smtp plugin and thus gets thrown off with the start script enabling the other, I guess those 10% use-cases are much better put into the lamp app, where WordPress is fully under your control.

Of course the alternative approach for a user is still to disable sendmail via cloudron app configuration and do this manually to not having to set up WordPress fully on your own.

Mail with WordPress also apparently is some odd case, given that WordPress seems to not have any built-in smtp capability which anyone wants to use. So just like for user management our package should pre-setup a sensible one and give you options, which we have. I understand if this is not the most convenient one in your case, but we have to optimize for the majority use-cases.

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.