If I disable the mail config for all of my domains, does the service get disabled?

[Lonkle]

I have no need or want for mail handling inside the dashboard for my use cases, and I was wondering if I disabled all of those domains configs if it would save me server resources (CPU / RAM wise, I realize storage-wise the code would still be there).

[nebulon]

The mail service will always be there, as it also handles sending out emails from Cloudron itself (password reset, notification, ...) and also the apps.

[Lonkle]

@nebulon Ah, completely understood. Question, do app's have email capabilities then? I assumed they didn't since the SMTP Mail Plugin for Wordpress Unmanaged was pre-installed (making me assume it needed it).

[Lonkle]

@nebulon You just said "and also the apps" - missed that part. Then why does WP Unmanaged come with the SMTP Plugin by default, or did I just accidentally install it?

[girish]

@Lonk At a very high level (like the highest level ), Cloudron (ux wise) is trying to get to a point where you get a SaaS like experience for selfhosted apps. Just to be clear here, even though people compare it against the other control panels and also use it as a app development platform, it is not it's primary audience. What this means practically is a "batteries included" approach to apps. When you install an app, email/auth/domains/certs etc is all working. Generally, we dislike apps that use lots of plugins for exactly this reason (can you imagine a SaaS product telling you install some SMTP plugin for getting emails, or or choose from 10 caldav plugins to get calendar support etc).

Sorry, I lost track and have to get back to the topic. So when WP (or any other app) is installed, we pre-set it up to have domains/email etc all working. In WP, sadly this is done with a plugin and thus the plugin is pre-installed. If you don't want to send emails, go to Email -> domain -> Outbound -> Disable. This won't disable the plugin as such but no mails will go out. You can delete the plugin, if it bothers you.

Note that for all things like domain change, email setup etc, the correct way is to go via Cloudron dashboard. Trying to change things like domain/email/auth directly in the app, will inevitably break the packaging since the packaging scripts are doing basically just that and they will eventually overwrite user changes.

[Lonkle]

Is the SMTP plugin pre-configured to Cloudron's network? I figured I had to configure it tbh for it to work since it was a custom plugin pre-installed, but you do have Managed Wordpress working without user customization so maybe mail is pre-configured?

Also, when I change the URL in Cloudron for a Wordpress Managed or Unmanaged installation, does it likewise change the URL of the Wordpress site (database-wise there are a few locations) when doing so (or rather, I should say, is it supposed to - since it did not in my multisite install, but I can fix that with Cloudron API magic...wish you guys had webhooks tho)?

[nebulon]

The SMTP plugin should be setup and ready to go after installation, if not this is likely a bug. As @girish mentioned, our main focus is on ease of use out of the box and thus requires us to make some decisions on behalf of the user, like which plugin to use in the WordPress case.

URL or rather domain changes always have to be done through the Cloudron dashboard, the app will then be reconfigured, the reverse proxy adjusted, eventually SSL certs acquired, ... this is the reason it has to be done through the Cloudron dashboard and not within an app itself. The benefit is that apps don't need custom patches, which we would have to maintain. Using webhooks in this case seems to only add more complexity and potential races with no real benefit from my perspective at least. Ideally we would even have the option to disable the UI bits in the app settings, which let the user still configure things like the domain, they don't make sense on Cloudron and just cause confusion.

[Lonkle]

@nebulon I agree with you. I actually am seeing the vision you guys have for Cloudron and love it. My primary passion is UX and I think you guys are nailing it.

My reason for wanting a webhook was so that I didn’t have to dive into cloudron:box to fix your Wordpress Multisite domain changes. Because when I changed my domain from Cloudron. My whole Wordpress errored out because it stores it’s own domain in the database in a few important entries (4 or 5) and then a single line in wp-config.php.

I plan on making WP Multisite a first class citizen on Cloudron, and you’re right that webhooks shouldn’t be the way to go. I’ll edit the box subcontainer code directly. Thanks for your input @nebulon - your insight is always appreciated. ️

[Lonkle]

@nebulon That's not to say that I don't think Cloudron shouldn't receive webhooks for other reasons. I'm surprised you aren't using them for your multi-cloudron dashboard actually (to update the status of "subcontainers" from all servers instantly).