I am simply saying that the script should NOT assume that the path is www.mydomain. com, but should also be able to change it, it is a very simple change to make
As I said it is increasingly common for a designer to tell a company that the new website goes on your hosting, and suddenly that company that I take the hosting, I have to change the path of webmail, nextcloud, etc … because Virtualmin does not allow me to choose the part of www.mydomain.com and I have to create a subdomain having to change everything and everywhere.
Apparently, you’re experienced enough, why not deploy NextCloud manually and ignore the web app? Ticks all boxes and the devs wouldn’t need to change anything.
Yes, in some sites I have it that way, in fact I prefer it because virtualmin does not allow me to automatically update versions and plugins as for example with nextcloudpi but the issue of nextcloud is an example, it can be nextcloud, webmail or any other app, because the main problem is that virtualmin assuming that the web is with the domain, when a designer takes the web to another hosting, for example I have to update all customers their path webmail → domain. com/webmail to apps.domain.com/webmail for example, and who says webmail, says nextcloud, crm, etc. etc. etc. etc… and that is a problem, and all for not being able to choose in the installation script to change domain.com, which I can do manually, but for that I use virtualmin to not have to be fighting with the configuration files.
What script? Nextcloud has it configured in public_html/nextcloud/config/config.php, but that has nothing to do with the Virtualmin Nextcloud installer.
However, if you change it after installation, you should manually edit the Virtualmin script log I mentioned earlier.
@Jamie, what if the directory that the Virtualmin script log expects has been moved manually, triggering if ($sinfo->{'deleted'}) {}—why not make it possible when “Manage App” page is opened, display a text box to manually update the new script directory?
OP wants an option to automatically create an Alias for a Web App when installing it (so it can be accessed at nextcloud.domain.tld instead of domain.tld). That is not something Virtualmin does right now, and I don’t think I’m convinced it should.
@uinfor: If you create an Alias (no mail, just a regular alias) named nextcloud.domain.tld for this domain, your nextcloud installation will be accessible on it. If you put the install in the base directory it will be available without any extra path info in the URL. That’s orthogonal to email or the specific details of why you want this, but Ilia is misunderstanding what you’re after and giving unrelated advice.
I think what you want, though, is actually “Automatic alias with Rewrite rule to make subdirectory appname be the root”. But, that’s not trivial, as far as I know. A ServerAlias can’t have its own configuration for Rewrite rules. I think it would require a new VirtualHost which does the rewrites, which gets quite messy, and why a Subserver with your application is probably a better choice here, as it doesn’t hide the complexity, it is clear what’s actually happening.
If there is a way to have a ServerAlias use a different path as the DocumentRoot, maybe via a Rewrite or maybe via some Alias (Alias is a path alias), I would be happy to hear it. But, I think anything you do to make the nextcloud.domain.tld alias behave the way you want will make it apply to everything in the VirtualHost, so you can’t install any other apps on / in that VirtualHost (so only one such alias can exist). Again, I think making a new VirtualHost is the only way to really achieve what you’re after, which puts the DocumentRoot elsewhere (but that’s a good thing, because you presumably won’t want someotherapp.domain.tld/nextcloud to load Nextcloud, which is would in the thing you’re trying to do).
If it does, I’d be more inclined to say we could add a checkbox to make an app available on some subdomain name via an automatically created Alias. But I don’t want to hide the implementation and pretend it’s not an Alias and pretend it’s independent of the top-level domain (you can still reach the app on domain.tld/appname or any other ServerAlias that doesn’t get rewritten).