Configurations

As our community transitions from Chamilo 1 to Chamilo 2, there might be a bit of confusion as to where configurations that were usually found in Chamilo 1 will be in Chamilo 2. And it's not super easy, because Chamilo 2 is still considered a "work in progress" as to what we want to achieve. But here is a little guide to help you get sorted out.

Configuration through the web

Whatever was there in the "Platform settings" in Chamilo 1 will still be there in Chamilo 2.

Also, a lot (almost all of it) of what was in app/config/configuration.php in Chamilo 1 will now be in the "Platform settings" in Chamilo 2, making it easier to configure.

As such, settings that were in app/config/configuration.php and that required database changes have been added to Chamilo 2 with their database changes already executed. That means that no additional database change will be needed to enable a feature in Chamilo 2 (at least for the features that existed in Chamilo 1). Definitely easier to manage.

Some settings, however, have been kept away from the web interface and inside configuration files. This is usually when the corresponding settings have some kind of security risk bound to them, or when adding them to the interface would have changed the level of access necessary for some critical feature.

For example, settings bound to the limits of users/courses/sessions that can be created on a portal have remained in files. Database settings (username/password/port/host) have also been kept in a file.

config/configuration.php

So you will still find config/configuration.php (instead of app/config/configuration.php) in Chamilo 2. Only that it's been stripped off most of its content.

This file contains a few settings that have some critical meaning (see end of previous section).

.env.local

The .env.local file is created on installation (or upgrade) of Chamilo 2.0. It is created using .env as a template, and it gets filled with, between other stuff:

• database credentials
• operating environment ('prod', 'test' or 'dev')
• locale
• API keys
• mail configuration
• CORS rules

However, the .env.local is not "interpreted" directly by the Symfony components of Chamilo 2. Instead, the contents are declared as environment variables which are later used to fill the real configuration files in config/packages/

config/packages/ YAML files

The config/packages/ directory contains a series of .yaml files which are interpreted by the different components of Symfony.

If the files directly located in config/packages/ can be used as "default", Symfony will prioritize files that are located in the subfolder that matches your operating environment.

For example, if APP_ENV was set to 'dev' in .env.local, then Symfony will first look for its .yaml configuration files in config/packages/dev/.

This can lead to a high level of confusion, in particular if you change operating environments.

So for example, the mail sending configuration is located in a file called mailer.yaml. If you are in dev mode, Symfony (inside Chamilo 2) will first look for config/packages/dev/mailer.yaml. If it is not found there, it will look for config/packages/mailer.yaml.

One additional tricky bit: this mailer.yaml can use a hardcoded configuration, for example:

framework:
    mailer:
        dsn: 'null://null'

(to avoid sending mails whatsoever in this development context) or it could use environment variables defined in .env.local, for example:

framework:
    mailer:
        dsn: '%env(MAILER_DSN)%'

In this case, you would find, in .env.local something like:

MAILER_DSN=sendmail://default

It is important to understand that, in a "production" environment, all settings should naturally be based on what can be found in .env.local. Other settings in config/packages/ should be considered fixed or only to be changed in case of a change in operating environment.