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

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

[marcusquinn]

@nebulon It might also be that 90% of people just don't know any better, as they assume the source of what they get is making the best executive decisions, and trusts in those.

I'm sure 90% of websites are in may ways insecure because human nature is to trust and just deal with whatever wolf gets through the door.

I'm sure 90% of people's lives could be easier, if they only knew something they were given could be better, if the 10% shared improvement opportunities.

It's often the small percentage of experience that supports the larger percentage that is the more valuable direction for wisdom to flow.

My experience is one of the most common frustrations between website client and website provider, being lack of visibility for what their website is or is not doing, that it is expected to.

The email logs are the answer to that question, and Fluent SMTP also then gives the option to re-attempt email sending, where there's been some error that is now fixed.

Without this, email sending is a black box to anyone but the server/service admins. Plus, extraordinary extra work to enable SMTP with services like GMail and Office365, where they are moving people to use the API integrations, instead. For which, Fluent SMTP provides, documents, and works with, too.

WordPress doesn't need SMTP capabilities, because it provides for sending email with the wp_mail php function:

• https://developer.wordpress.org/reference/functions/wp_mail/

The only reason for any SMTP plugin, is that some hosts restrict email sending, to avoid their hosting being spam machines.

Also, sending email via a separate services helps avoid the IP (often shared) from being blacklisted.

Perhaps Cloudron doesn't need any SMTP plugin setup to send emails in first install, since the current setup isn't giving any separation of IP for this service, anyway.

I can't even think of any initial emails needed from the app for setup, anyway, since the Admin login credentials are standardised in the app first launch instructions.

Perhaps starting up should happen once to make wp-cli available, query for any plugin with smtp in it's name, and then only IF there isn't one, restart the app and install SMTP Mailer.

• https://developer.wordpress.org/cli/commands/plugin/list/

Honestly, I hate asking for anything — but I hate lost time more, so in this case I feel it is a request of necessity and contribution to an improvement for all, from experience of the time-costs not having a solution continues to incur and risk.

Yes, it's an apparent request to change something that appears to already be working, and have workarounds to make work differently to suit some apparent preference — but my preference is for safety, optionality, audit-trail visibility, client confidence, and time-saving for all.

The majority of people have terrible diets, and will continue to, unless those producing, distributing and marketing food offer better and more convenient. It's not just me I'm asking for, it is the majority, that may not know there's a better way — and it save me more time to help the majority with other things, too.

[msbt]

@marcusquinn if it's about logging, there are a few other plugins capable of doing that (e.g. "WP Mail Logging", which can also resend if required). For those special-need cases I just migrate the WP on a regular LAMP app and add it to my WP Manager.

[marcusquinn]

@msbt Thanks. Still not the point. There's a force-fed plugin reinstalling itself. That's just not good.

20 years with WordPress, many years with Cloudron. Many, many times I've found workarounds to things.

Appreciate the sentiment — but experience tells me that opportunities to improve the world rarely happen unless someone makes them happen the first time around.

It's technical debt and a time-costs. Time is too precious to have it repeatedly spent on something that could be avoided. That's the whole point of computers, to automate and iterate on wisdom, so we are free to create.

I chose Cloudron specifically for time-saving factors. It's all those little things that add up to a non-scaleable business if they aren't templated and automated out.

Automated problems are a crime against other's time.

I'm not changing the hosting setup of dozens of WordPress sites because a design flaw hasn't been solved yet.

That would be quitting — which isn't in my vocabulary.

I'm not working around this. I'm here for the long-haul, and if I see unnecessary time lost, risk, confusion, disparate solutions, it's a moral duty to stick with the problem until solved.

If the majority don't value their time as highly, or have the same issues, it doesn't mean they won't in future, or that everyone holds the same standards for auditing and time-efficiency.

Life is too short for workaround hacks that will cost more time than just solving the source of the problem:

There's a plugin being reinstalled after it was deleted.

No amount of "have you tried", "why don't you", is gonna change this fact.

[marcusquinn]

Reminder for everyone, the WordPress App has updated to 6.5, meaning the SMTP Mailer plugin is reinstalled and reenabled for everyone.

If you're using any other SMPT plugin, it won't be working until SMTP Mailer is deactivated again.

[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