---
title: "Registro"
description: "Cómo se descubren automáticamente los módulos y cómo se almacenan en caché sus configuraciones para el acceso en tiempo de ejecución."
---

El **Registro** es la caché de configuración de módulos de Nibiru. Al arrancar, recorre cada directorio bajo `application/module/`, analiza cada archivo `settings/*.ini` de los módulos y expone la configuración analizada a través de un único acceso. Piensa en ello como el centro gravitatorio que mantiene a los módulos en órbita unos alrededor de otros.

## Cómo funciona la descubrimiento

Para cada módulo bajo `application/module/<nombre>/settings/`:

1. El Registro itera archivos que coinciden con `*.ini`.
2. Para cada uno, intenta primero el nombre de archivo **específico del entorno** (`<base>.<env>.<ext>`, por ejemplo, `users.production.ini`); si no, cae en el nombre base (`users.ini`).
3. Llama a `parse_ini_file($path, true)` (multi-sección).
4. Busca una sección nombrada después del módulo, *en mayúsculas* — `[USERS]`, `[CMS]`, `[ANALYTICS]`.
5. Los pares clave/valor analizados se convierten en un `\stdClass` indexado por el nombre del módulo.

## Leyendo la configuración de un módulo
```php
$users = \Nibiru\Registry::getInstance()->loadModuleConfigByName('users');
$users->session_lifetime;
$users->password_min_length;
$users->allowed_roles;        // array
```
Dentro del módulo mismo, la convención es envolver esto en un setter:
```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;
    }
}
```
## ¿Por qué los nombres de secciones en mayúsculas?

Los nombres de secciones INI suelen escribirse en mayúsculas para hacerlos visualmente distintos. El Registro asume esto, por lo que un módulo llamado `cms` busca `[CMS]`. Siempre use mayúsculas.

## Multi-INI por módulo

Nada te impide tener más de un archivo INI en la carpeta `settings/` de un módulo. El Registro los analiza todos y fusiona todo lo que coincida con `[<MÓDULO>]` en el mismo `\stdClass`. Útil para dividir las responsabilidades:
```
application/module/users/settings/
├── users.ini              # [USERS] base config
├── users.smtp.ini         # [USERS] mail-related keys
└── users.production.ini   # production override
```
## Cuándo usar el Registro frente a la Configuración

| | `Config` | `Registry` |
|---|---|---|
| Fuente | `settings.<env>.ini` (un archivo) | INIs por módulo (muchos archivos) |
| Alcance | configuración de marco a nivel de aplicación | configuración específica del módulo |
| Secciones | mixtas (DATABASE, SETTINGS, ENGINE…) | una por módulo |
| Búsqueda | `Config::getInstance()->getConfig()['DATABASE']['driver']` | `Registry::getInstance()->loadModuleConfigByName('users')` |

Un módulo que necesita leer el controlador `[DATABASE]` se dirige a `Config`. Un módulo que necesita leer su propia `[USERS] session_lifetime` se dirige a `Registry`.

## Listando todos los módulos cargados
```php
$registry = \Nibiru\Registry::getInstance();
foreach ($registry->getModuleNames() as $name) {
    $cfg = $registry->loadModuleConfigByName($name);
    echo "$name → " . print_r($cfg, true) . "\n";
}
```
Útil en un controlador de depuración o un panel de administración.

## Semántica de recarga

Como `Config`, el Registro es un singleton que se pobla **una vez** por solicitud. Si cambias la INI de un módulo, necesitas refrescar la solicitud para ver los nuevos valores. Hay un método `destroy()` en el singleton del Registro si realmente necesitas recargar a mitad de solicitud, pero en flujos normales no lo harás.

## Trucos comunes

- **El nombre de la sección no coincide con la carpeta del módulo.** Carpeta `users/`, se esperaba la sección `[USERS]`. Mismatch → configuración vacía.
- **Extensión de archivo INI.** Solo se analiza `*.ini`. Un archivo `*.conf` o `*.config` es ignorado.
- **El archivo de entorno anula silenciosamente el archivo base.** Si existe `users.production.ini` con `[USERS]`, lo oculta completamente a `users.ini` — no se fusionan. Mantenga ambos archivos sincronizados, o utilice uno más un superponer.
