The init.php file

How to use the init.php file

Settings of any Daiquiri application are governed by the init.php file. In this file you define database connections, application settings, and user access settings. We will discuss these in details below.

init.php can be initiated from the command line using

./init.php

and its command line options are shown when using the -h flag:

Usage: ./init.php [ options ]
-h|--help            Displays usage information.
-a|--application     Creates the application.ini file (must be invoked first).
-l|--links           Creates the neccessary softlinks.
-m|--minify          Minifies the static js and css files.
-u|--user            Displays the commands to create the database user.
-c|--clean           Displays the commands to clean the database.
-v|--vhost           Displays the virtual host configuration.
-w|--wordpress       Displays the wp-config.php entries.
-d|--drop            Drops the databases including the user databases.
-s|--sync            Creates the databases and tables as long as they do not exist yet.
-i|--init            Runs the initalisation process.

Content of the init.php file

The main part of the init.php file is one big PHP array called $options. It holds all the configuration properties. Settings are encoded using PHP arrays as Key => Value pairs. The value can then be another array and a settings hierarchy is built using arrays of arrays. All settings have a default setting and need to be specified in the array only when changed from this value.

Database connection configuration

The first key of $options, database defines the database connections. For Daiquiri to run, you need to define a web adapter which points to the database that will host all the data for the web application. If you use the query interface, a user adapter needs to be defined for the database where the user tables will be created. The user adapter can be different to the web adapter.

An example setup looks like this:

'database' => array(
        'web' => array(
            'dbname' => 'daiquiri_web',
            'host' => 'localhost',
            'username' => 'foo',
            'password' => 'bar',
        ),
        'user' => array(
            'dbname' => 'daiquiri_user_%',
            'host' => 'localhost',
            'username' => 'foo',
            'password' => 'bar',
        )
    ),

Each adapter contains the following Key => Value pairs (technically Daiquiri configuration parameters are stored as PHP arrays and each array consists of Key => Value pairs encoding the configuration. Thus we also have arrays of arrays and so on.):

Mail configuration

In order to send mails, a SMTP connection to a mail server needs to be configured, e.g.:

'mail' => array(
    'host' => 'localhost',
    'email' => 'admin@example.com',
    'name' => 'Daiquiri Admin'
),

The options are as follows:

Module configuration

You can switch on and off different modules of daiquiri. The different modules are:

There are dependencies between the modules and they are resolved automatically. Therefore a configuration like this:

'modules' => array('query','contact')

will enable the core, auth, contact, data, and query modules.

Application configuration

The $options['config'] key is an array of arrays that hold the general configuration for each separate Daiquiri module as a separate array. The different configuration entries are described in detail on a seperate page.

Initial data

The initial data for the application is specified under the $options['init'] key. Most of the initital data will be automatically generated depending on the $options['config'] array, but can be overridden.

The $options['init']['auth'] key defines default users, roles and rules. The only item that needs to be defined in any case is an admin:

'user' => array(
    array(
        'username' => 'admin',
        'password' => 'admin',
        'email' => 'admin@example.com',
        'status' => 'active',
        'role_id' => 'admin',
        'firstname' => 'n/a',
        'lastname' => 'n/a'
    )
),

Metadata consist of three different kind of entities: databases, tables, and columns and is defined in $options['init']['data']. First you define all the database metadata in an array, then the tables, and then the columns. Each entry in the databases metadata array contains the following properties:

When all metadata for the databases are defined, you need to define metadata for all the tables you want to publish. They are defined as such:

When you are done with this, you need to define the column metadata. They allow for the definition of Virtual Observatory compliant metadata (needed for instance when generating VOTables out of your data).

An example might look like:

'data' => array(
    'databases' => array(
        array(
            'name' => 'daiquiri_science',
            'description' => 'A science database for the daiquiri demo app.',
            'publication_role' => 'user',
            'publication_select' => '1'
        )
    ),
    'tables' => array(
        array(
            'database_id' => 1,
            'name' => 'particles',
            'description' => 'The 10k top rows of the particle table from MD1',
            'publication_role' => 'user',
            'publication_select' => '1'
        )
    ),
    'columns' => array(
        array(
            'table_id' => 1,
            'position' => 1,
            'name' => 'particleId',
            'description' => 'unique id for particle',
            'type' => 'bigint',
            'unit' => '',
            'ucd' => 'meta.id; meta.main'
        ),
        array(
            'table_id' => 1,
            'position' => 2,
            'name' => 'snapnum',
            'description' => 'number of snapshot',
            'type' => 'smallint',
            'unit' => '',
            'ucd' => 'time.epoch'
        )
    ),
),

Semi-automatic creation of metadata

All the metadata which can be extracted from the database itself, like all tables and columns with types, can be fetched automatically using the autofill option. For the example above corresponds this to:

'data' => array(
    'databases' => array(
        array(
            'name' => 'multidark_test',
            'description' => 'A test database for multidark.',
            'publication_role' => 'user',
            'publication_select' => '1',
            'publication_show' => '0',
            'autofill' => '1',
        ),
    )
),

The descriptions, UCDs, and units need to be added manually over the admin interface or by scripting.