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

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

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