Unfortunately, with some web-applications such as Drupal 8 going all Composer the current way of how Virtualmin creates virtual servers is becoming more and more problematic.
In particular, if you want to install the latest version of Drush then according to instructions on http://docs.drush.org/en/master/install you will need to follow their recommendation to built Drupal 8 using Composer with Drush listed as a dependency. So everything now comes in one package.
Reading the https://github.com/drupal-composer/drupal-project page further, you will see Drupal 8 is installed with a command:
composer create-project drupal-composer/drupal-project:8.x-dev some-dir --stability dev --no-interaction
some-dir
being a directory which is one level up than Drupal's root, where all the Composer files and directories are stored. Drupal 8 itself goes into some-dir/web
directory.
Now naming is not that much important, because you can change the composer.json file and use other names like to replace the two above to, for example, username/public_html
, so the whole path becomes Virtualmin compatible like /home/username/public_html
. However, what is most important here is the difference in the structures: Virtualmin's /home/username
directory does not come empty, but with the some directories as:
cgi-bin etc fcgi-bin logs Maildir public_html
while Composer requires complains some-dir
, in our case /home/username
to be empty and stops installing giving complaint if it is not empty, to place its own files and sub-directories there. So we have to give /home/username/public_html
as some-dir
instead and Composer then proceeds ok, deploying its structure:
composer.json composer.lock drush LICENSE load.environment.php phpunit.xml.dist README.md scripts vendor web
where web
is Drupal 8's core. Then to access Drupal 8 website through it's domain name without appending subdirectory web
we have to additionally change the document root from /home/username/public_html
to /home/username/public_html/web
.
At the same time caring about all other types of websites which reside in /home/username/public_html
directories, so we simply can not change the Apache document root system-wide, but only for Drupal 8 websites.
Please read further details on https://drupal.stackexchange.com/questions/258329/what-is-the-right-way-... The accepted answer explicitly states:
Coming to the folder structure: It is advisable to keep the folder above the Drupal 8 root as base folder of your root package (project), location for the composer dependencies (vendor folder), Drush site settings, and auxillary files that should not be directly accessible from your web URLs (e.g. exported configuration files, private files, temporary files, Node.js packages, ...). Therefore you should consider pointing your virtual hosts' root directories for example to /home/username/public_html/web (or /home/username/public_html/public, if you customized your composer.json like that) while using the regular root directories of your hosting panel /home/username/public_html as composer root package folder.
So this changes the whole automation process which we had using Virtualmin before. And hopefully Virtualmin will provide the best way of getting around this problem. For example, Virtualmin could allow to set custom document root during creation of virtual server. I know it is possible to change after the fact, but I am talking about doing it during the process both on UI and CLI.
Jamie, please read the above provided information and give your feedback, so we could plan changing things on our end accordingly.
Comments
Submitted by yngens on Sat, 03/24/2018 - 21:13 Comment #1
Submitted by JamieCameron on Sun, 03/25/2018 - 20:22 Comment #2
This can be done already, by using virtualmin's template feature. Just create a new template, and in the "Apache webserver" section set the "Users' website subdirectory to create" to something like
web/public_html
. When creating a new domain from the UI or API, you can then select this template to force use of this custom directory.Submitted by yngens on Mon, 03/26/2018 - 08:51 Comment #3
To say frankly, I knew that, however I brought this up hoping we gonna get way from template-per-application-type approach that we are using now. We really wanted to plug in and start Virtualmin's application installation process.
Anyway, the suggested method is fair enough for now, so let's concentrate on https://www.virtualmin.com/node/44979 and close this one.
Submitted by Jfro on Mon, 03/26/2018 - 09:42 Comment #4
Offtopic ik know. ;)
But reading a topic in supportforum, then at the end a link for further..readings. but not "allowed to read" is not forumuser friendly?
A read only for such parts is more friendly.