I think this would be relatively easy to fix, but if you have a non standard document root set up for a server, the install scripts (at least phpmyadmin) still installs to the users ~/public_html directory. I had a client who changed their document root to /home/user/public_html/path/to/app and then installed phpmyadmin via the script installer and it installed to /home/user/public_html, which is inaccessible. Should vm check to see if the document path is not standard and use that value as the base path for installing scripts?
Also, is there any way once a script is installed to change its location so it can be upgraded via script installers? I physically moved the phpmyadmin dir to /home/user/public_html/path/to/app/phpmyadmin. The installer still thinks the location is ~/public_html because thats where it installed to. Id like to change the path so the client can upgrade the script with no problem and without having to move directories around.
This is using vmpro 3.76
Thanks, Steve
Comments
Submitted by JamieCameron on Wed, 02/10/2010 - 16:48 Comment #1
How did the client change the document root exactly?
Virtualmin can handle different root directories, but only if it knows about the change ... and it may not detect a change made directly in the httpd.conf file.
Submitted by SteveHeinsch on Wed, 02/10/2010 - 17:10 Comment #2
Via webmin/servers/apache webserver/virtual server options for their domain/document root. This particular client is trusted and has access to this as he manages many domains for his clients.
But regardless of how it changed, shouldn't it check for what document root is set at for the domain for installing scripts at the time of installation? It seems that would work universally.
I imagine this is a very rare occurrence, but if document root is changed it makes the whole script installer application useless for that domain.
Submitted by JamieCameron on Wed, 02/10/2010 - 18:26 Comment #3
Yes, a fix to re-check the real document root before installing a script makes sense -this will be implemented in the next Webmin release (3.78)
Submitted by Issues on Wed, 02/24/2010 - 20:19 Comment #4
Automatically closed -- issue fixed for 2 weeks with no activity.