This RFC is about discussing changes in the configuration system.

Current status is a mix of:

• INI files
• Configuration values in code
• Objects created in the code

Currently too many things are configured at runtime instead of in a configuration file. For example some things are configured through events. By separating configuration and execution, we end up with a more explicit config and simpler code (ridden of configuration). And we offer more extension points since plugins can override everything in the config (not that they always should ;) ).

Changes proposed:

• move config options from INI files to DI config
• move configuration logic (that is in the code) to DI config
• move objects creation to DI config (or factory objects called by DI config)
• plugins can provide an optional config file (e.g. named config/config.php?)

List of DI configuration files and their order of inclusion:

• config/main.php
• plugins/.../config/config.php (Plugins configs)
• config/environment.dev.php
• config/environment.test.php
• config/config.php (User config)

Environment config allows to override default config and to avoid doing so dynamically it in the code.

Example

When configured to log to file, the logger reads the file name from the Config object.

Then it gets the tmp path and append the filename to it.

Then it gets the Piwik Instance ID and appends it to the path (if not null), which is a special case for the CloudAdmin plugin.

This could be replaced by a config looking like this (this is an abstract config syntax for simplicity):

• default config:
  • tmpPath = PIWIK_ROOT . '/tmp'
  • logFile = tmpPath . '/logs/piwik.log'

This covers the most common cases. Then if a plugin (e.g. CloudAdmin) wants to customize the path:

• CloudAdmin config:
  • tmpPath = tmpPath . '/' . instanceId (replace the default config value)
• User config:
  • instanceId = 123

In the end, we end up with the same result except configuration is separated from execution (the file is not configured in code). The config is more explicit, and also more extensible. No need to add custom "instance ID" code in Piwik Core just for a feature of the CloudAdmin plugin.

Do we keep INI files?

2 things:

• global/internal Piwik config
• user config

Global config should be moved to DI config because it's much more powerful so I don't see the point to maintain 2 separated configs.

However user config can be changed by users (obviously) so it might be best if it's as simple as possible (PHP syntax might be too much).

I think DI config files is not incompatible with being simple. If we stick to INI, we'll seriously limit what users can do and override. With DI config they have much more power, yet we can still provide simple configuration options on a use case basis (i.e. no complex PHP syntax).

Quick and dirty example with the logger:

// User config
return [
    'logger' => 'file' // or "stdout" or "database"
];

// Global config
return [
    'Psr\Logger\LoggerInterface' => DI\factory(function ($container) {
        $choice = $container->get('logger');

        if ($choice === 'file') {
            // ...
        } else // ...
    }),
];

Then it still leaves the possibility to advanced users (e.g. Piwik Pro Cloud) to override Psr\Logger\LoggerInterface in their user config to something completely different.

By the way this is how Symfony works with Bundle: you can set up objects manually (e.g. set up your logger and all) or use a bundle that will abstract and simplify the config for you so that you just have to set 1 or 2 options.