mrKamooandClaude Sonnet 5
c35833ed0b
L'édition de fichier nécessitait que le process web ait un accès en écriture sur .env — problématique en prod (permissions, plusieurs instances). À la place : - Table `settings` (clé/valeur) + SettingsRegistry, une liste blanche explicite des réglages modifiables (mail, OnlyOffice, GLPI, nom/URL de l'app) mappés vers leur chemin de config Laravel. - Volontairement exclu : tout ce qui touche à l'infrastructure (APP_KEY, DB_*, SESSION_DRIVER, CACHE_STORE, QUEUE_CONNECTION...) — ces valeurs sont nécessaires avant même qu'une connexion BDD existe, donc une surcharge en base ne serait pas fiable et reste réservée au .env. - AppServiceProvider applique les surcharges au boot (cache 5 min, invalidé immédiatement à l'enregistrement) ; le reste du code continue de lire config() normalement, sans changement ailleurs. - Tant qu'aucun réglage n'est enregistré, le comportement reste identique au .env actuel — transition sans rupture. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
24 lines
535 B
PHP
24 lines
535 B
PHP
<?php
|
|
|
|
use Illuminate\Database\Migrations\Migration;
|
|
use Illuminate\Database\Schema\Blueprint;
|
|
use Illuminate\Support\Facades\Schema;
|
|
|
|
return new class extends Migration
|
|
{
|
|
public function up(): void
|
|
{
|
|
Schema::create('settings', function (Blueprint $table) {
|
|
$table->id();
|
|
$table->string('key')->unique();
|
|
$table->text('value')->nullable();
|
|
$table->timestamps();
|
|
});
|
|
}
|
|
|
|
public function down(): void
|
|
{
|
|
Schema::dropIfExists('settings');
|
|
}
|
|
};
|