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

[marcusquinn]

@robi It'd rather be able to delete it, and it stay deleted. I wouldn't ask for anything detrimental to others. I'm not forcing my preferences on anyone else.

I just cannot see any reason to reinstall it on an app update.

My guess is it was just assumed it would never be replaced.

I do replace it with Fluent SMTP on every install, as I get time, and it is a manual chore.

I'm not forcing that one anyone else, but have run it happily for a long time now (when uninterrupted with app updates).

I can't see any downsides, but right now it's just me recommending it, so I respect that might need more voices.

In the meantime, you can't try out any other SMTP plugins and have continuity through app updates.

[jdaviescoates]

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

I just cannot see any reason to reinstall it on an app update.

I'm not sure, but I think the way Cloudron works is that updates are basically the exactly same as an install (to ensure everything is exactly the same, hence why backing up, restoring, cloning etc nearly always works flawlessly), so I'm not sure this idea is really feasible.

Edit: yep, as @girish says below:

The reason why the mailer plugin gets re-enabled is just for reproducible states. It's also logic for restore and import. When you import from backup, the plugin has to re-enabled. App packaging logic does not know whether it's a fresh install or an import or a clone or a restore etc. Sorry, it's a bit technical but there's a good reason to write packaging code this way.

[girish]

@marcusquinn I agree that maybe creating a mailbox is not required. The platform needs to be provide a way to create sending only credentials, we have to add this feature. i.e the quick equivalent of grabbing it from credentials.txt . I am thinking that maybe when a user selects "Do not configure email" , we can still create SMTP credentials that the app can use. Will discuss this internally and get back.

The reason why the mailer plugin gets re-enabled is just for reproducible states. It's also logic for restore and import. When you import from backup, the plugin has to re-enabled. App packaging logic does not know whether it's a fresh install or an import or a clone or a restore etc. Sorry, it's a bit technical but there's a good reason to write packaging code this way.

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