Drupal Install System

Kjartan correctly identified one of the problems
in creating a unified install system.

There's a lot of code that gets run by simply including the core files (bootstrap.inc, database.inc, session.inc and common.inc).

A lot of this code relies upon the database connection going off without a hitch, like for instance the current system variables, themes and session code. To work around this i created a new drupal_init() function, which needs to be called when you want the system to initialize.

drupal_init has a 'db_init' argument, which allows you to bypass the loading of all the database related code with a simple flag. install.php needs to run drupal core, while ignoring any database connections .. until atleast the point where the configuration settings for the database are entered, and confirmed to work.

There is a new function created called 'database_connected()' , which returns a boolean true only if the database both connected and the table was selected successfully. This patch does not have a suitable error message for index.php upon not being able to make a database connection ,but that message should very likely be discussed and finalized.

In the next level of the patch I will introduce the major changes, or rather additions. I haven't modified any existing files beyond the ones in this patch (at this time).

I have reworked the patch into a very minimal set of requirements.

To prevent the .inc files from running any code when you don't want them to , you 'define' a
constant called 'DRUPAL_NO_INIT' before including bootstrap.inc.

This relatively small patch is required for the install stuff to work.

i'll even attach it this time.

The following patch is a modification to the includes/database*.inc set of files,
to make db_connect return a boolean value depending on wether the connection was
successfully made.

I have changed database.inc to die() upon connection error with the message "Database Connection Unsuccessful".
Cleaning up that message and placing a help page might be a good idea from an user experience point of view.

This patch is required for the install system, in that it needs to test wether it has made a successfull database
connection before it allows you to actually install the schema.

This is an alpha version of the new install API code. It is completely capable of installing the drupal core system
without requiring any interaction with the database side. There are currently 5 configuration screens ,
but the API is sound for us to add / remove / change these screens as we need.

In it's current state, it isn't capable of updating the base system, however the backend stubs exist, and have been tested.

In the push to get the install process running smoothly i simply disabled the update interface.

The previous 2 patches on this node need to be applied, but have been combined into install_system_alpha.patch which is included
in this distribution.

The rest of the files are new , and should not interfere with the drupal core at all.

They are

includes/install.inc
... the file that hosts the install api.
install.php
... the front end script that initializes the install api (a total of 5 lines)
install/system.install
... the install module for the core. It contains the bulk of code from update.php,
and all the configuration information needed to successfully install the core.

In the future , the install api will be able to easily install any contrib module through
the modulename.install file that will hopefully become well supported.

Note: I need to update the postgres compatibility in this .install file, and as such only mysql
is fully tested now.

I have posted some screenshots at my site

Unconed just pointed out there is a conflict with windows installations in that
there can not be an 'INSTALL' file and an 'install' directory (which contains the system.install currently)

He suggested that we rename the README and INSTALL files to README.txt and INSTALL.txt.

I personally move that we store the .install files within the modules directory , as in the future
installing a contributed module should be as simple as dropping the module directory (containing .install , .module and whichever external files)
into modules/ , and then installing the module within drupal.

So I have spent far too much time over the last few weeks battling with this install system. My current results are in this here tarball. This time I am even less sure of it fully working in all cases, than last time.

With this release I added extensive error checking to the install process, finished MOST of what is needed for the update process , but most importantly... it is a lot more secure than previously, and is specifically built to allow people to host their multiple drupal installs from just a single root. I have handled this by adding a global variable to the config file (allow_override_config) , which is checked by the install script before a new configuration file is made that would override the currently active one.

There are three settings to this : 'no' , 'any' and 'auth'. I feel auth is generally the best option, as it requires anyone trying to override a working configuration file to enter the username and password for the site he is trying to override. Added checking also exists for the minimum requirements of running a drupal system (the tests probably need to be fleshed out), aswell as refusing to install a database dump into a db_url/db_prefix which seems to have a valid site installed.

When a working configuration is detected on startup , the default action is to require the administrator user of the site to log in. This is for security reasons. The install script has lots of code that stops it from ever overwriting any config file that has already been created, but as I said .. it allows for the creation of a config file that will be parsed before the current valid install, but only with the express permission of that config.

Config files have been moved to './conf/' , and the default config has been renamed to 'conf/default.php'.
I have split install.inc into install.inc and install.module, as there was a lot of interface code specifically for the update/install sequence (and it is best available for reuse .. so i didnt wanna put it in install.php).
This has an unrelated quirk for xtemplate .. I left it in the patch because for some reason I was unable to get a working default theme because xtemplate refused to populate the 'path' template variable.

I also have an extensive 'gallery' of the new changes if you just want to see what it looks like.

Directions for use :

untar in a drupal cvs tree , and 'patch -p0 < install_alpha_2.patch'
go to http://mysite/install.php ... previous configs in includes/ will be ignored

for extra fun , create a hostname entry to sitea.siteb.sitec.sited.mysite , and watch the install script pick up the valid configs.

taking out of patch queue.

Still on my todo list, but I have to get some other things done first.

Attached is the first iteration of my new install system.

To install :

Extract tarball into a clean checkout, and apply the install_api_phase_1.patch file.

This patch implements the following :

1. Core install api. (includes/install.inc)
2. Modifications to drupal_load that disables a module that has an out of data schema. (includes/bootstrap.inc)
3. Does not allow modules to be enabled unless they have been installed, or updated and the allow for them to be
   installed and updated directly from admin/modules. (modules/system.module)

This patch does NOT :

Install or update Drupal core, however it is possible to do so with the api (and I have done
so before), significant changes to Drupal need to happen before it is practical to handle core with it.

Description :

This is the first phase of a four or five phase project, so it's not meant to solve the whole problem. I am
writing a post for the Drupal forums at present detailing the progress with the install system, and directions
I want to take it.

To enable a module to be installable, you add an implementation of hook_info() to it , i.e. :

  function buddylist_info($key) {
    $info['schema'] = 1;
    return $info[$key];
}

This tells the system that a schema version of 1 is required to operate this module.

You then create a file called modulename.install (preferably in the same directory in the module, although it doesn't
really matter. You then need to specify which schema version it implements by :

  function buddylist_schema($key) {
    $info['version'] = 1;
    return $info[$key];
}

Although, in the current implementation this function is optional when you only have a single schema version (the default is 1).

Then you implement your hook_install().

function buddylist_install() {
  $query = "
CREATE TABLE {buddylist} (
  uid int(10) UNSIGNED NOT NULL,
  buddy int(10) UNSIGNED NOT NULL,
  timestamp int(11) NOT NULL,
  PRIMARY KEY (uid, buddy)
)";
  db_query($query);
  db_query("ALTER TABLE {buddylist} ADD received tinyint(1) NOT NULL;");
}

This function would be called for any database type that has not specified it's own function.
To add Postgres support, the function would be called buddylist_install_pgsql();.

If the schema of your module ever changes, to allow for it to be updated, you proceed as follows :

1. increment the 'schema' value in your hook_info() function.
2. increment the 'version' value in your hook_schema function, within your modulename.install file.
3. modify your schema as required, by changing it in the hook_install() function.
4. provide an update script for users of the previous version.

The following is an example of an update script.

function buddylist_update_1() {
  db_query("ALTER TABLE .... ..... ");
}

These updates can also be database specific (ie: buddylist_update_1_pgsql() etc).

When a module needs to be updated, it will execute each of the functions
in order (exactly like one would in updates.inc currently.)

I have included copies of the Trackback and Buddylist modules for testing.

Yeah. I've been planning that from the start (before it had a fancy name), I'm currently planning to have it
happen around phase four or five.

Here is that overview of the install system i promised weeks ago : http://drupal.org/node/22472

This is the first phase.

Updated this patch to work with HEAD.

as before, there are copies of the buddylist and trackback modules, just to illustrate the usage of the patch.

1 ) Extract into a HEAD install
2 ) patch with install_api_phase_1.patch
3 ) 'delete from cache' in your database (the menu cache is much maligned by myself)
4 ) Go to admin/modules and see the install links in place of enable.