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

[marcusquinn]

@jdaviescoates Ahh, good thinking. Although, another thing to remember to do as a workaround. I have quite a lot of WP sites, and expect to be creating many more.

[marcusquinn]

@girish I only ever have a problem with unnecessary repeat effort

1. Fluent SMPT just doesn't work whenever SMTP Mailer is installed and Activated at all. Nothing. Nadda. Zilch. Zero. No email shall leave the website unless SMTP Mailer sends it. No other logs shall be kept by any other plugin. It completely takes over php mailer functionality, and no other plugin can do any email sending. It will only go through SMTP Mailer code and credentials, or not at all. It's one thing to install a recommended plugin, but another to activate a deactivated and/or deleted plugin. To be clear, no other SMPT Plugin can work alongside SMTP Mailer, at all. Doesn't matter what the credentials are.

2. If I disable "Use Cloudron Mail to send emails", to stop this plugin being reinstalled and activated, now, instead of just quickly grabbing the credentials from credentials.txt, I now have to also setup a user account with a mailbox, and put that Cloudron user's credentials into a WordPress database. Not ideal for both extraordinary, unnecessary effort, and security, since the User account has more privileges than the credentials.txt SMTP details.

3. I could use an external SMPT proxy credentials, but then I need a new account for every domain. So much extra work and cost, when the functionality already exists.

Many websites just don't also need full blown mailboxes and users. They just need to send emails from the website, hence you install SMTP Mailer, and hence I remove it and install Fluent SMTP, so I can track what it sends.

I appreciate there's workarounds, but I just don't want the SMTP Mailer plugin being force-fed. Can we just modify the WP-CLI that's installing and activating it to only do that on a fresh install? I can't think of any reason why it should be doing that again on App updates, since once a plugin is installed in the App setup, for a WordPress Developer App, that should now only be the responsibility of WordPress or the Developer to update it, or not, as they choose.

I cannot imagine any regression from this fix, since those that don't care will not have deactivated it in the first place.

I appreciate if you might not want to change the default plugin offered, and perhaps many don't care for email logs, but for me they are essential auditing, and client's like the reassurance of being able to see copies of the emails the websites send in their name.

[robi]

@girish can you simply check to see if the SMTP mailer plugin is disabled and leave it so?

If it's not installed, it makes sense to install it, unless there is some config variable that says otherwise.

At least two options to resolve this, or both (keeping it uninstalled).

Feature wise, Fluent would be a welcome upgrade if you can configure it just as easily as the existing 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?