There has been some preliminary work on an install; see: http://drupal.org/node/view/1599
other points: I know that the db_prefix is being talked about on the Drupal lists, in the past there were some hacks, but it may become the standard(but not in time for the new release.) I started to implement Drupal on MS-SQL2000, but backed off because of the work involved in implementing modules that did not include an MS-SQL script ... if you establish a "standard package" of modules, then using MS-SQL would be less of a problem. On Tue, 2003-07-22 at 08:15, Aldon Hynes wrote: > 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 >
