feat: considerar env vars para instalación vía docker

[abdedarghal111]

Se añade soporte para leer variables de entorno en el proceso de instalación, pensado principalmente para despliegues con Docker. Estas son las modificaciones mínimas para que funcione el añadir las variables de entorno vía docker. Se han añadido las siguientes:
FS_LANG
FS_DB_HOST
FS_DB_NAME
FS_DB_PASS
FS_DB_PORT
FS_DB_TYPE
FS_DB_USER
FS_INITIAL_USER
FS_INITIAL_PASS
FS_DEBUG

Cambios detallados:

Core/Tools.php — nuevo método Tools::env()

Se añade el método estático env(string $key, $default = null) que envuelve getenv() devolviendo el valor de la variable de entorno si existe, o el valor por defecto en caso contrario. Se ubica junto a Tools::config() por ser su contraparte para variables de entorno. Adicionalmente, siteUrl() pasa a usar Tools::env('FS_SITE_URL', 'http://localhost') como fallback en contextos CLI/cron en lugar del string hardcodeado.

Core/Kernel.php — idioma por defecto

El idioma predeterminado del sistema pasa a resolverse como Tools::config('lang', Tools::env('FS_LANG', 'es_ES')), permitiendo configurarlo via variable de entorno cuando no existe config.php.

Core/Controller/Installer.php — pre-relleno del formulario desde env vars

Todos los valores por defecto de los campos del instalador (host, nombre, contraseña, puerto, tipo de BD, usuario, usuario inicial, contraseña inicial) pasan a leerse de las variables de entorno correspondientes (FS_DB_HOST, FS_DB_NAME, FS_DB_PASS, FS_DB_PORT, FS_DB_TYPE, FS_DB_USER, FS_INITIAL_USER, FS_INITIAL_PASS) si están definidas, manteniendo los valores hardcodeados anteriores como fallback. Se añade también la propiedad pública $debug que se inicializa desde FS_DEBUG.

Core/View/Installer/Install.html.twig — checkbox de modo depuración

El checkbox de modo debug añade el atributo checked cuando fsc.debug es verdadero, de forma que si FS_DEBUG=true está definido como variable de entorno el campo aparece marcado al cargar el formulario.

[NeoRazorX]

Gracias por el PR. La idea (instalación desatendida vía env vars para Docker) es muy útil, pero el soporte queda incompleto en el punto que de verdad persiste la configuración:

Bloqueante — saveInstall() ignora las propiedades rellenadas desde env para lang, debug, initial_user e initial_pass

run() rellena $this->debug, $this->initial_user y $this->initial_pass con Tools::env(...), pero saveInstall() vuelve a leer del request con defaults hardcodeados:

• lang → $this->request->input('fs_lang', 'es_ES') (ignora FS_LANG)
• FS_DEBUG → $this->request->input('fs_debug', 'false') (ignora $this->debug y FS_DEBUG)
• FS_INITIAL_USER / FS_INITIAL_PASS → $this->request->input('fs_initial_user', '') (ignora $this->initial_user/$this->initial_pass)

En un POST desatendido (con unattended=1 y confiando en las env vars, sin enviar esos campos del formulario) solo se persisten bien los parámetros de conexión a BD, porque esos sí usan $this->db_*. El resultado: config.php queda sin FS_INITIAL_USER/FS_INITIAL_PASS → no se crea el administrador inicial, y FS_LANG/FS_DEBUG se ignoran. Es decir, el caso de uso que motiva el PR no funciona del todo. Hay que hacer que saveInstall() use las propiedades ($this->debug, $this->initial_user, …) o añada el Tools::env(...) también en sus defaults.

Menor — (bool) sobre el valor de la env hace que FS_DEBUG=false active el debug

getenv() siempre devuelve string y (bool)"false" es true en PHP (solo "0" y "" son falsy). Con (bool)$this->request->input('fs_debug', Tools::env('FS_DEBUG', false)), definir FS_DEBUG=false deja el debug activado. Mejor normalizar con filter_var($value, FILTER_VALIDATE_BOOLEAN) para que false/0/no desactiven. Incluso podría hacerse dentro de Tools::env().

Lo dejo en WIP a la espera de que las env vars se apliquen también en el camino de saveInstall().