Install Script without removing other scripts

So i was testing out some of the scripts and stuff for a domain/server. I installed OS ticket and phpBB and MediWiki, and at the top level, just a couple basic HTML pages as a landing page.

Well now i want to install WordPress at the top level and pretty up the site. But installing the WordPress script at the top level wants to delete everything in the public_html folder.

Is there no way around that?

Edit: All other scripts are installed in their own levels/directors at this time

installing all on top level you be a nightmare,you would have multiple index.(php,html) files, how do you handle that?

im not installing all at the top level…please re-read…i want to install WordPress at top level. My other scripts are in directories(not at the top level)

Sorry, I read this that you have phpBB and MediWiki at top level.

Still the index file is still the problem. You can backup the current files in the “top level” install WP then replace them. I don’t think the install should effect folders (backup first)

P.S. I just did a test on a domain I don’t use. Install roundcube in the roundcube directory then Wordpress top level and roundcube folder was not effected. But be careful and backup first.

@pologoalie8908 @stefan1959,

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.

1. install WordPress at the “top-level”
2. install OS Ticket in a “sub-directory”
3. 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”.

Yea that is my plan. Its not the end of the world. I dont have a ton built out on it. But firgured id ask the question.

I do realize that a top level install of a script would want to do a check to make sure its got a clean place to install…but i would think of it from an example with Windows files:

• Lets say we have a folder called root
• in that contains folders and files
• you can select all the files and folders of the root folder
• then copy them
• and paste them in another folder that already has folders and files it it.
• the pasting of files and folders from root does not overwrite what was in the destination folder

You do make a good point that it might be a bug, or at least, an undesired behavior?

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

Richard

yea that is another possibility i failed to consider. but if i want to install wordpresss at the domain.tld, then it still wants to nuke the scripts i already have installed and set up

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.

Richard

But as mentioned, the scripts are already setup as sub directory of the domain.tld. I cant really move them manually to the sub domain.

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.

Richard

i mean if im gonna have to do extra work either way, im probably jsut gonna re do it with WordPress at top level since its so robust, and then add scripts to sub directories. (shrug)

The only problem with that would be the chance that WP hoses them again on an update. Someone more familiar with WP would have to chime in about that possibility.

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’ve had WP running at root with other scripts with no issue.Updates with only effect WP folders and files.

thats fine, but did you install WP at root AFTER installing additional scripts in sub directories like in this case?

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.

But, please make a backup first! I haven’t tested this. I’m just making a guess based on how I assume it works (but I think I have good reason to assume that).

@Jamie, why don’t we keep track of files that are being installed with the script to the top-level directory, and delete only those files upon script uninstall?

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.