Config Parameters

AtroCore configuration parameters are located in the data/config.php file. You can access and modify these values in the code by retrieving the config utility from the service container.

Accessing a Value

To retrieve a configuration value, use the get() method with the parameter's key. You can access nested values using dot notation (e.g., 'database.host').

Example:

/** @var \Atro\Core\Utils\Config $config */
$config = $container->get('config');

// Get a top-level key's value
$passwordSalt = $config->get('passwordSalt');

// Get a nested key's value
$dbHost = $config->get('database.host');

Store or modify a value

To change a configuration value, use the set() method. Changes are not applied until you call save(). This method persists the changes to the configuration file.

Example:

/** @var \Atro\Core\Utils\Config $config */
$config = $container->get('config');

// Set a new value for a configuration parameter
$config->set('applicationName', 'My Custom App');

// Persist the change to the configuration file
$config->save();

Computed and contributed parameters cannot be written this way - see Read-Only Parameters.

Read-Only Parameters

Some parameters are not stored in data/config.php at all - the system derives them on every load. Writing them is a programming error, so set() and remove() throw a LogicException for such a key:

• locales, mainLanguage, inputLanguageList, isMultilangActive - derived from the Language and Locale records
• onlyStableReleases - derived from minimum-stability in composer.json
• referenceData and everything else contributed by a module (see below)

Contributing Your Own Data

A module adds its own entries to the configuration through the static getConfigAdditionalData() method of its Module class. The method returns an associative array of key => value. A key may be segmented, so 'referenceData.Car' lands in $config['referenceData']['Car']:

namespace MyModule;

use Atro\Core\ModuleManager\AbstractModule;
use MyModule\Repositories\Car;

class Module extends AbstractModule
{
    public static function getConfigAdditionalData(): array
    {
        return [
            'referenceData.Car' => Car::getConfigData(),
        ];
    }
}

Keep the data-fetching itself in the repository that owns the records, so the configuration never has to know where or how they are stored:

namespace MyModule\Repositories;

use Atro\Core\Templates\Repositories\ReferenceData;

class Car extends ReferenceData
{
    public static function getConfigData(): array
    {
        $path = self::DIR_PATH . '/Car.json';

        if (!file_exists($path)) {
            return [];
        }

        $items = @json_decode(file_get_contents($path), true);

        if (!is_array($items)) {
            return [];
        }

        $res = [];
        foreach ($items as $key => $row) {
            $res[$key] = [
                'id'   => $row['id'] ?? null,
                'code' => $row['code'] ?? null,
                'name' => $row['name'] ?? null,
            ];
        }

        return $res;
    }
}

The method is static because the configuration is built before the service container can provide module instances. It is called once per process; DataManager::clearCache() drops the cached result.

Never Contribute Sensitive Data

Everything returned by getConfigAdditionalData() is exposed to the outside world. It reaches:

• the browser, where it is read as this.getConfig().get('referenceData')
• Twig templates that users edit through the UI, as config.referenceData
• PDF and export rendering contexts

Restrict every entry to the fields the UI actually needs. API tokens, passwords, connection details and any other secret must never be contributed this way.

A Key Can Have Only One Owner

A module may only add entries. If a key is already provided by the core, by another module, or is already present in data/config.php, loading the configuration fails with a LogicException instead of silently overwriting the value. Prefix your keys with something specific to the module to avoid collisions.

Every key a module contributes automatically becomes read-only.

General System Settings

Database Connection

Memcache Connection

Logging

User and Security

UI & Display

File Management

Fetching Files From URLs

Wherever the system downloads a file from a URL the user supplied - the Upload via URL field, the url property of POST /api/File, POST /api/File/uploadProxy - the request is made by the server, not by the browser. The server therefore reaches whatever it can reach, including services that are not exposed to the outside world at all.

For that reason only http and https URLs pointing at publicly routable addresses are accepted. Loopback, link-local, private and reserved ranges are rejected, redirects are not followed, and the address the connection actually reached is checked again once the transfer starts.

An installation that legitimately pulls files from its own network - an in-house DAM, a staging server - names those hosts in fetchAllowedHosts, and only those skip the address check:

'fetchAllowedHosts' => [
    'dam.internal.example.com',
    'files.staging.example.com',
],

List the hosts you actually fetch from. The parameter is empty by default, so reaching a private address stays a decision someone made on purpose.

Background Jobs & Workers