Assuming for a moment that each of the scripts are installed within their own “directory” and that the “top-level” comment originally posted was a typo…
Perhaps @Ilia might be able to chime in to see if this is a bug or the intended action. It’s quite possible that installing a script at the “top-level” (speaking about WordPress) would cause the child folders (where other scripts are allegedly setup) to be wiped out as a logical model given the “top-level” script wants a clean slate.
So, perhaps doing things in a different order would be more appropriate.
install WordPress at the “top-level”
install OS Ticket in a “sub-directory”
install phpBB in a “sub-directory”
In theory at least, this model shouldn’t disrupt the “top-level” as it’d be creating a sub-directory and using it “after” creating the initial script at the “top-level”.
I don’t know from WordPress because I almost never use it. I think the last one I installed was between five and ten years ago.
I do believe, however, that the problem can be completely avoided by setting up sub-servers to the virtual server for Roundcube et al. and installing those scripts as top-level in the subservers (for example, https://roundcube.domain.tld).
If you would like Roundcube to also be accessible from domain.tld/roundmail or domain.tld/webmail to preserve users’ existing shortcuts, that can be done in .htaccess in the root of domain.tld (or probably better, in httpd.conf in case WP overwrites .htaccess during updates).
That’s because the scripts belong to domain.tld and live in /home/[user]/public_html for domain.tld. Neither would be the case if the scripts were in subservers. The scripts would then be top-level in /home/[user]/domains/[sub].domain.tld/public_html.
As I said, I know little about WP; but I doubt the installation script reaches out to touch anything outside of /home/[user]/public_html. I’d have to actually try it to be sure, but I can’t think of a reason why it would.
I think you could. It might be a pain in the ass, but I’m almost certain that it’s doable. I never used OS ticket and I haven’t used phpBB in years, but they have to have some backup and restore capability. You might have to manually change some paths, however.
As an aside, I recently did the same thing with FusionInvoice. I actually was expecting it to be more difficult than it was. It turned out to need nothing at all other than to be pointed to the database.
The other “maybe” option would be a kludge, and that would be to install WP to its own subdirectory and then make the changes in .htaccess or httpd.conf to make it open when the root of the domain is requested. I’m not sure how to do that with WP nor if its even possible. It’s not something that I use.
I’d put my money on the ‘sub server option’ … possible pitfall is is your using the pro version as one ‘domain’ can gobble all of your allowed domains on a 10 seat plan … I fell foul of that … so I use GPL and still pay for pro to get support (tbf with this newer system that is not so good i.e when pro support was different to gpl support it was better)
I wouldn’t expect it to have any problems, as long as there are no directories in WordPress that match names of the directories you put the other apps in.
The stuff in the top-level directory is pretty likely to get overwritten, though.
You should make a backup before you try it, just in case, but I’d be surprised if there are any serious issues with it.
Just keep in mind that you can’t uninstall WordPress in Virtualmin once it’s done, because it’ll deleted everything in the directory (including all your other stuff). Which is why top-level apps are generally recommended to be the only app on the domain. If you never plan to delete WordPress, then you never have to worry about that.
That’s not easy. Something like WordPress can install plugins and such after installed by Virtualmin, and those files wouldn’t be tracked by Virtualmin.
I could see keeping an index of files and dirs created by the Virtualmin install, though. Just pipe the output of tar tf to a file, or something. That’d be pretty useful. Could then delete all those files and directories, specifically.