Unless I have got something about the install process really wrong, it's currently necessary to copy a "clean" settings.php to the place you wish the new site to have its settings folder (keeping to the naming convention for settings folders). If you do not do this, Drupal will install the site in the default directory.
This is a real hurdle when you want to set up a new site in a multisite environment with a few simple clicks. See an earlier post I made about it; I hope this suggestion will at least trigger a response.
This is too close to the code freeze for a big feature in 6.x, but here's my suggestion:
- add an extra step to the installer between "locale" and "database".
- have it display a select menu with all possible places where the settings file for the current URL can be located.
- on submitting, have it create a fresh settings.php in the selected location.
eg, on http://my.website.com/drupal have it display the options:
default
website.com
my.website.com
my.website.com.test
(Leaving out "com", which rarely makes sense, but adding "[port]." choices if Drupal detects it is being called on a non-standard port.)
The options where sites are already installed should be removed from the list, of course.
----
To avoid cluttering the installer for people who never use this, perhaps enable it only when at least one site is already installed, or even make it part of the "advanced" settings in the Database Configuration screen.
But really, this would be a great improvement for multi-site environments.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | multisite-installer-155309-6.patch | 13.79 KB | cburschka |
| #2 | optional-multisite.png | 46.88 KB | cburschka |
| #2 | already-installed.png | 29.54 KB | cburschka |
| #2 | required-multisite.png | 50.47 KB | cburschka |
Comments
Comment #1
cburschkaMoving to 7.x-dev.
Comment #2
cburschkaI have experimented a bit and ended up with a few promising screenshots that are attached here.
Unfortunately, several parts of the modification are hacks, and will have to be cleaned up (and tested with localized installations and custom installation profiles). Also, the documentation texts are ghastly and barely comprehensible even to multi-site experts. But I'm on my way to a working prototype.
---
What I'm finding especially hard is the addition of a new multisite to a location that is already "covered" by an existing installation - for example, if you try to install a site at example.com/multisite after already installing a site at example.com. The modified installer therefore provides an option to "override" the existing site with a new subfolder of higher specificity, after first notifying you that a site is already installed.
If there is no conflict with an existing directory, the directory selection menu is hidden away as an advanced setting, and set to "default".
Explanation for the screenshots:
1. The optional selection of a custom site folder (fieldset is collapsed by default).
2. The new install_already_done_error() page, explaining to the user which site folder is being used, and allowing them to proceed with a multi-site installation.
3. When the installation is overriding an existing site, the multi-site selection is expanded, asking the user to choose a new site folder.
Comment #3
wim leersSubscribing.
Comment #4
jstollerAfter spending hours this weekend trying to figure out how to set up a multi-site installation (I finally got it working), I fully support this enhancement. From a usability perspective, I should be able to setup multiple sites from the installer without ever needing to manually copy files. The installer should be able to create the appropriate folders and files in the sites directory for me. I also should be able to return to the installer at any time to add additional sites to my installation, or to reconfigure existing sites.
Comment #5
cburschkaRight on. The installer has come a good way since it was introduced in 5.0, but it could really use a bit more power.
Comment #6
cburschkaI think I just created a working overriding multisite, settings file, database, setup and all. It works!
Here is a preliminary patch - this is by no means a proposal yet, just a taste and an opportunity to point out improvements. That's why I'm not setting to CNR yet; I'm not even done testing it myself.
To test the patch, you only need to install a new site from scratch using the modified codebase. The installation directory should be an optional selection, with the default being sites/default. Then, you can either visit install.php at this same site or link another URL to the same codebase (with the other URL matching the existing settings file), then visit install.php there. The installer will warn you that a site is already installed, but that you can install a different site with higher specificity over it.
Comment #7
moshe weitzman commentedsubscribe ... would be great to get this in.
Comment #8
xano+1. Anybody else?
I suggest letting users provide a site name and automatically create a new folder in /sites based on that name. For novices it's far too complicated to start moving, and copying files. Since Drupal needs write access to settings.php anyway we can easily say D7 needs this permission for the entire /sites directory so new sites can be added on the fly, perhaps even through the administration panel if a first site has already been set up.
If Drupal has rights to /sites entirely it could copy default.settings.php to settings.php by itself. This would remove one necessary step from the installation process.
Comment #9
lilou commentedPatch #6 cannot apply against CVS/HEAD.
Comment #10
alexanderpas commentedComment #11
cburschkaWell, big surprise - the install process, the database layer and the settings file logic has changed substantially.
Now, we also have the elusive
sites.phpwhich allows sites to lie in arbitrary directories rather than a particular hostname/filepath construct. If we're going to make all this magic available in the graphical front-end, we could probably add support for sites.php at the same time.I wouldn't mind a feature of "The following sites are already installed. If you want, you can link this domain to one of them so that it will be displayed when this URL is visited."
Comment #12
Anonymous (not verified) commentedI think this request should be created as an install profile of its own. I don't like this idea for the default install profile because it opens the /sites directory for world read/write/execute. There are some things that should be remain in the control of the unix admin and this is one of them.
Comment #13
greenskin commentedWill there be a way to uninstall a multi-site site from a GUI stand-point? Possible my question deserves it's own issue.
Comment #14
jstoller@earnie: You shouldn't assume that all, or even most, Drupal users have access to "unix admins". An installer that requires users to manually copy and rename files isn't much of an installer at all. I realize there are some security concerns here, but I'm sure someone in the Drupal community can come up with a creative solution for those. From a usability standpoint, I should be able to install and uninstall as many sites as I want, all from the GUI, without any manual file manipulation.
Comment #15
Anonymous (not verified) commentedRe: #14.
I don't assume that. I assume that those projects that are most concerned about security will not like the feature in a default install profile. I assume that a profile that allows a less secure file system should be given but not as the default. I know there are technical and non-technical users and that the market share to the non-technical is lacking. I'm not against providing methods for the non-technical; I just don't want it to be the default.
Comment #16
jstollerI see your point, but non-technical users are the ones who must rely on default settings the most. Technical users may not have any problem locking down the security of their system after installation, or using a non-standard installation profile, but a non-technical user may be confused and overwhelmed if you ask them to deviate from the standard GUI-based controls. From this perspective, the default installation should be as straight forward and user-friendly as possible, to reduce the barrier to entry. There could then be simple instructions for technically-inclined users to better secure their system after installation.
Comment #17
Anonymous (not verified) commented@jstoller: I'll concede to that as long as a profile is delivered for the more secure method in the Drupal download tarball.
Comment #18
Jangmap commentedComment #19
sunRelated: #1730770: Drupal installer cannot be fully tested in a separate sub/multi-site
Comment #32
smustgrave commentedWonder if this is still a needed for D10?
Comment #34
quietone commentedThere hasn't been discussion here for 13 years despite the question asked about two years ago.
Therefor closing.
If there is interest in this re-open the issue and add a comment. Or open a new issue and reference this one.