I think automating the install sounds like a very good idea. However, I have quite a few concerns on this, which I will go through and list, as well as some of the possible solutions.
First, there is the issue of what database is going to be used. So far, everything has been in MySQL. However, there may end up being installations that will want or need to use MS SQL Server. I've been trying to get MS SQL Server up and running. Moshe tells me that it is fairly easy, but I haven't seen that yet. Ruling out SQL Server for the time being, we do have the problem of only having access to one database from an ISP. I don't know how likely this is going to be, but it is a problem we need to be aware of and ready to handle. I like the idea of all drupal tables starting with Drupal_ or even better, starting with a prefix defined in conf.php (That way you could have multiple drupals defined within the same database). However, my guess is that that would be a major change to Drupal, affecting every module. That said, should we start doing something like that for our development? (I would be especially interested in Moshe's opinion here). Perhaps a bigger problem is, what happens if multiple people want to use the same ISP? In that case they will have to have different database names. We must make sure that our script is capable of handling that smoothly. My guess is that this has a potential to be a bit of a problem. If an ISP turns out to be a 'good host' we may find a lot of people wanting to use the same host. To get around some of this, my gut feeling is that a database dump is not a good way to go. Instead an SQL script may make more sense. We should see what is involved in writing the SQL to insert or update rows that will do the configuration. This is likely to be more usable by more people. The next big issue, and this isn't so much of a technological issue, is to determine what the default configuration should be. Will we turn on blogs? Will we turn of Forums? Will we turn on Static Pages? And who will get to see what? Will anonymous users be able to see content? Will we turn on the jabber module? Will we have default imports and/or exports? Currently, it seems like we have at least five different sandboxes, and each sandbox seems pretty different. I think we need to work towards a concensus about what the standard install should look like. Enough random thoughts for right now. Aldon -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ka-Ping Yee Sent: Tuesday, July 22, 2003 1:57 AM To: Neil Drumm Cc: Hack4Dean List Subject: Re: [hackers] is an automatic installation script feasible? On Tue, 22 Jul 2003 [EMAIL PROTECTED] wrote: > On this same line of thinking, (perhaps Moshe will know this best), is it > feasible to customize a sandbox with everything we want - right themes, > right modules - and then package that for distribution? Great idea. I totally agree -- we definitely should (and can) do this. On Tue, 22 Jul 2003, Neil Drumm wrote: > We can easily make a tarball of Drupal with our extra modules and > themes in all the right places. [...] > An install.php could definately handle the database installation. With a little additional cleverness it ought to be possible to configure include/conf.php using a setup.php script as well. > As for something that goes through and configures everything in > the admin pages, maybe a database dump? Yes, i'm pretty sure that will do the trick. All the settings (modules, themes, blocks, etc. etc.) are stored in the database as far as i can tell. So when we want to do a release, we just set up an empty instance of Drupal and "freeze" it by dumping the tables. Then the user installation procedure is reduced to: 1. Upload our tarball to your web site and unpack it. 2. Use your ISP's admin interface to create a new MySQL database. 3. Visit setup.php and follow the instructions. How important do you think the case is where people won't be able to create a new database for Drupal, and will instead have to use an existing database? Are there lots of ISPs that only give you one database? If that case turns out to be important, we might want to consider modifying Drupal so all the table names have a common prefix like "drupal_" (just like Movable Type has "mt_"), so that it's safe to merge all the tables into an existing database; then step 2 becomes optional and installation is reduced to steps 1 and 3. -- ?!ng
