October 21 to 23, 2011

UC Berkeley, California

A culmination of the brightest Drupal minds in the technology hub of the world


Writing the installer as a module

The installer that runs when Drupal is first installed represents a "fork" of the standard module system and fakes various core systems (like the cache) which results in duplicate/redundant code and inconsistent behavior. Allowing the installer to run in a standard Drupal environment would remove the need for most of the scripted installer code and the inconsistencies in the way the two systems work. The idea is to install a minimal Drupal system and run the installer in that system. The installer will then create the final Drupal setup and the temporary minimal environment will be removed.

To reiterate some of the benefits:

- installer can be written as a module and has access to a proper Drupal environment
- all normal hooks are fired when installing modules (opens up all kinds of interesting possibilities in addition to fixing bugs/inconsistencies depending on when module is installed (by profile or later))
- we remove the inconsistent behavior of the initial installation system as compared to the module administration once Drupal is running
- get rid of a ton of code that we never have to see or maintain again

Having consistent behavior, which also means gaining some features, would be very beneficial to install profiles (or distributions) in addition to maintenance in core. Also having a full Drupal environment will allow for more interesting and innovating things to be done during installation.

There are several approaches to achieving the initial minimal environment which need to be discussed and a decision reached. The issue this idea stems from is http://drupal.org/node/1226380.