Hi -- I'm a long time member of the Drupal community, and I thought I'd offer some perspective. Feel free to contact me directly if there is anything else I can do to help.
First of all, a base Drupal install supports "multisite" operations out of the box. The default website is at /sites/default -- additional sites / domains can be created by simply creating additional folders underneath /sites. e.g. /sites/example.com. To start serving example.com from the Drupal install, simply configure httpd.conf to point to the top level drupal folder -- index.php detects and routes to the appropriate domain based on the contents of the /sites folder. This multisite support is probably a good argument for putting drupal somewhere like /usr/drupal6 > How and where are users expected to install the > modules? By adding > subdirs under 'modules'? Will that be supported? > Where/how are they > configured? Typically, they are installed in one of two locations per best practices. /sites/all/modules -- available to all sites /sites/example.com/modules -- installed on a per site / domain basis and available only to that site > > Drupal core itself consists of less than > 4MB of PHP scripts and > > configuration files, designed to be copied > into and reside in the > > Webserver's top-level document directory. > As such, no new "/usr" > > subdirectory needs necessarily be created > for Drupal installation. > > Please classify the delivered files into > > a) those which are always read-only (i.e. the core > "binaries" of the > implementation) > those which are may be edited by users to customize > the system (if any) > c) those which are always written into, such as > configuration and log files > > This will help understand what's what and where > should things go. The only files / directories which should be user editable / customizable all live inside the /sites folder. I'll skip locations for modules as described above, here are the other files in particular: /sites/example.com/settings.php -- part of install sets this, this is where DB user / pass lives /sites/example.com/files -- site specific files, permissions need to be set for webserver write /sites/example.com/tmp -- site specific tmp folder /sites/example.com/themes -- site specific themes, and this is likely the place where users will edit / update CSS, PHP template files, etc. As mentioned under the modules section, things could also be placed under /sites/all -- but if you would like to support / encourage multisite, I would recommend doing it on a per site basis. The only other spot that might have user downloadable files is the top level /profiles directory -- where Drupal install profiles can be downloaded. > BTW does Drupal need/recommend any configuration in > apache config files? It's designed to run "out of the box" on random ass shared hosting (aka RASH), so it ships with an .htaccess file that attempts to do the right thing. AllowOverride will need to be set correctly, in particular mod rewrite support so that "clean urls" work. > > which suggest maybe it can't get along peacefully > with other docroot content? > > What's the issue there? The base .htaccess file for clean urls -- it will grab all paths underneath docroot unless you exclude some paths. Drupal does everything, why would it want to share docroot :P > ) Somewhere under /usr and you provide a script a > user can run to > hook it up into the final location (and the script > can do > additional groundwork beyond just bits). I would recommend this process. And leave it there (i.e. don't "move" it anywhere...), but configure httpd.conf / drupal.conf to support domains served from this location. A useful addon would be a small script to add / create additional websites -- e.g. newdrupal example.com -- that set the correct conf settings plus created a new subfolder under /sites. Bundling the drush.module and/or provisioning.module (http://drupal.org/project/drush and http://drupal.org/project/provisioning) to enable this might be an option. > > 4.6. Installation/Configuration > [...] > > 4) Manually create Drupal database/schema > > Manually by running some provided script, or > literally "manually" by > telling the user to start typing in SQL? This shouldn't be manual -- install.php takes care of this. HOWEVER ... there must exist a MySQL or PostgreSQL user and database to connect to. --- My only other comment is that if you want to add more value, then shipping with correctly configured APC or eAccelerator PHP opcode cache -- this would provide excellent performance out of the box. This message posted from opensolaris.org
