---
title: "Registrierung"
description: "Wie Module automatisch entdeckt werden und ihre Konfigurationen für den Laufzeitzugriff zwischengespeichert werden."
---

Der **Registry** ist der Modulkonfigurations-Cache von Nibiru. Beim Booten durchläuft er jedes Verzeichnis unter `application/module/`, analysiert die jeweilige `settings/*.ini`-Datei eines Moduls und macht die geparste Konfiguration über einen einzigen Accessor zugänglich. Denken Sie daran, dass es sich um das Gravitationszentrum handelt, das die Module gegeneinander in Orbit hält.

## Wie die Erkennung funktioniert

Für jedes Modul unter `application/module/<name>/settings/`:

1. Der Registrierungsprozess durchsucht Dateien mit dem Muster `*.ini`.
2. Für jede Datei versucht er zunächst den **umgebungspezifischen** Dateinamen (`<base>.<env>.<ext>`, z.B. `users.production.ini`); falls dies nicht möglich ist, greift er auf den Basisnamen zurück (`users.ini`).
3. Er ruft die Funktion `parse_ini_file($path, true)` (mehrere Abschnitte) auf.
4. Er sucht nach einem Abschnitt mit dem Namen des Moduls, in **Großbuchstaben** — `[USERS]`, `[CMS]`, `[ANALYTICS]`.
5. Die geparsten Schlüssel-Wert-Paare werden zu einem `\stdClass`-Objekt, das durch den Modulnamen indiziert ist.

## Ein Modul konfigurieren lesen
```php
$users = \Nibiru\Registry::getInstance()->loadModuleConfigByName('users');
$users->session_lifetime;
$users->password_min_length;
$users->allowed_roles;        // array
```
Innerhalb des Moduls selbst ist die Konvention, dies in einen Setter zu verpacken:
```php
class Users extends ModuleAdapter implements IModule
{
    const CONFIG_MODULE_NAME = 'users';
    protected static \stdClass $usersRegistry;

    protected function setUsersRegistry(): void {
        self::$usersRegistry = Registry::getInstance()
            ->loadModuleConfigByName(self::CONFIG_MODULE_NAME);
    }

    public static function lifetime(): int {
        return (int) self::$usersRegistry->session_lifetime;
    }
}
```
## Warum Großbuchstaben in Abschnittsnamen verwendet werden?

INI-Abschnittsnamen werden üblicherweise in Großbuchstaben geschrieben, um sie optisch zu trennen. Der Registrierungsmechanismus setzt dies voraus, daher sucht ein Modul namens `cms` nach `[CMS]`. Verwenden Sie immer Großbuchstaben.

## Multi-INI pro Modul

Nichts hindert Sie daran, mehr als eine INI-Datei im Modulordner `settings/` zu haben. Der Registrierungsmechanismus analysiert alle Dateien und fügt alles zusammen, was mit `[<MODULE>]` übereinstimmt, in das gleiche `\stdClass`. Nützlich für die Aufteilung von Verantwortlichkeiten:
```
application/module/users/settings/
├── users.ini              # [USERS] base config
├── users.smtp.ini         # [USERS] mail-related keys
└── users.production.ini   # production override
```
## Wann der Registry gegenüber der Config verwendet werden sollte

| | `Config` | `Registry` |
|---|---|---|
| Quelle | `settings.<env>.ini` (eine Datei) | pro-Modul INIs (mehrere Dateien) |
| Umfang | app-weit, Framework-Konfiguration | Modulspezifische Konfiguration |
| Abschnitte | gemischt (DATABASE, SETTINGS, ENGINE…) | ein pro Modul |
| Suche | `Config::getInstance()->getConfig()['DATABASE']['driver']` | `Registry::getInstance()->loadModuleConfigByName('users')` |

Ein Modul, das den `[DATABASE] Treiber` lesen muss, greift auf `Config` zu. Ein Modul, das seine eigene `[USERS] session_lifetime` liest, greift auf `Registry` zu.

## Auflistung aller geladenen Module
```php
$registry = \Nibiru\Registry::getInstance();
foreach ($registry->getModuleNames() as $name) {
    $cfg = $registry->loadModuleConfigByName($name);
    echo "$name → " . print_r($cfg, true) . "\n";
}
```
Nützlich in einem Debug-Controller oder einer Admin-Dashboard.

## Neuladen-Semantik

Wie `Config` ist das Registry ein Singleton, das **einmal** pro Anfrage aufgefüllt wird. Wenn Sie eine INI-Datei eines Moduls ändern, müssen Sie die Anfrage aktualisieren, um die neuen Werte zu sehen. Es gibt eine `destroy()`-Methode im Singleton-Registry, falls Sie wirklich während der Anfrage neu laden müssen, aber in den normalen Flows wird dies nicht passieren.

## Häufige Fallen

- **Abschnittsnamen stimmen nicht mit dem Modulordner überein.** Ordner `users/`, erwarteter Abschnitt `[USERS]`. Nicht übereinstimmend → leere Konfiguration.
- **INI-Dateierweiterung.** Nur `*.ini` wird verarbeitet. Eine `*.conf` oder `*.config`-Datei wird ignoriert.
- **Umgebungsdatei schattet Basisedatei stumm.** Wenn `users.production.ini` mit `[USERS]` existiert, schattet sie `users.ini` vollständig – nicht zusammengeführt. Behalten Sie beide Dateien synchron oder verwenden Sie eine + ein Overlay.
