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

[marcusquinn]

@girish Thanks, never noticed that setting, will have to remember for all instances. Yes, using other SMPT services for these instances, just to make sure records of the emails sent are visible in the sent items and Fluent SMPT logs.

[marcusquinn]

@girish Sorry, this still remains a problem.

I can't disable "Use Cloudron Mail to send emails" because that needs to be enabled for the credentials to be available and working for using those in my installed, configured, and preferred Fluent SMTP.

Every time WordPress Developer is updated by Cloudron, it reinstalls SMTP Mailer.

I'm not using SMTP Mailer. I'm using Fluent SMTP — because I need the email sending logs to ensure emails are sent, and keep records of what was sent. Hence I recommend this should be the default, as I find this a very common need:

• https://forum.cloudron.io/topic/10016/consider-fluent-smtp-as-the-default-email-sending-plugin

Every time SMTP Mailer is reinstalled, and reactivated, it takes priority over Fluent SMPTP, my chosen SMTP plugin, so Fluent SMTP no longer sends emails.

Wordpress Developer version should allow me to make all plugin choices, and not be installing and activating any plugins.

Every single time this happens, I have a gap in email log records, and sometimes just no emails being sent from the site.

Because this is a silent nuisance, it can be weeks before noticing. Clients asking me what emails have sent, if their contact forms are working, and I have no records. Real businesses are losing valuable contact records because of this bug.

Please, please, can we find another way. Life's too short for self-inflicted werk time-cost.

I don't know if or why I might be the only person having this issue, but communications logs are really important in a role where issues, bugs, and accusations of things not working or being changed without request are common. Worse, people rely on their websites to generate new business, and often that means a quick response to form submissions, and communications trail.

Sorry, I just don't believe we solved this issue, and I have an issue with any logic that makes executive decisions that overrides and regresses my own.

[jdaviescoates]

@marcusquinn if I were in your shoes in the interim I'd just turn off auto-updates for your WordPress Developer apps.

Perhaps WordPress Developer should just not have any plugins installed by default and a message informing people that they'll need to install SMTP Mail / Fluent SMTP or similar to enable emails?

[girish]

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

I can't disable "Use Cloudron Mail to send emails" because that needs to be enabled for the credentials to be available and working for using those in my installed, configured, and preferred Fluent SMTP.

What is the problem here? Can you not put the sending credentials of your mail provider into Fluent?

If you are hosting on Cloudron itself:

• create a mailbox
• you can create an app password for that mailbox even - https://docs.cloudron.io/profile/#app-passwords (just choose mail client)
• put credentials

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