Files

fs 25370a1a55 add composer-unused, comprehensive docs, and project restructure

- Add icanhazstring/composer-unused as dev dependency for dependency hygiene checks
- Add German documentation (docs/) covering architecture, conventions, workflows, and developer checklists
- Add API layer (ApiAuth, ApiBootstrap, ApiResponse), audit, scheduler, custom fields, and SSO services
- Add Microsoft OIDC SSO, API token management, and user lifecycle features
- Add swagger-ui vendor integration and OpenAPI spec
- Add production Docker setup and bin/ scripts
- Update composer dependencies, config, templates, and frontend assets throughout

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-02-22 15:27:35 +01:00

2.1 KiB

Raw Blame History

Einstellungen: Speicherung (DB + Cache)

Letzte Aktualisierung: 2026-02-21

Kurzfassung

Source of truth ist immer die Tabelle settings in der Datenbank.
config/settings.php ist nur ein Teil-Cache für wenige, sehr häufig gelesene UI-Basiswerte.
Nicht alle Settings müssen oder sollen im Datei-Cache stehen.

Warum es beides gibt

Die Kombination ist bewusst so gebaut:

DB als Wahrheit
- Alle Settings werden persistiert in settings.
- Validierung und Schreiblogik laufen über SettingService.
Datei-Cache für Hot-Path-Reads
- config/settings.php wird durch SettingCacheService geschrieben.
- Verwendet wird er über appSetting(...) nur für globale Basiswerte wie:
  - app_title
  - app_locale
  - app_theme
  - app_theme_user
  - app_registration
  - app_primary_color

Was nicht im Cache der Datei liegen muss

Sicherheits- oder Integrationswerte werden direkt aus DB gelesen, z. B.:

SMTP (smtp_host, smtp_port, smtp_user, smtp_from, ...)
Microsoft SSO Shared App Settings
API-spezifische Policies
User-Lifecycle-Policies (user_inactivity_deactivate_days, user_inactivity_delete_days)
Scheduler-/Job-Konfiguration (scheduled_jobs, scheduled_job_runs)

Daher ist es korrekt, wenn diese Werte in settings (DB) vorhanden sind, aber nicht in config/settings.php.

Laufzeitfluss

Admin speichert Settings in admin/settings.
SettingService::set* schreibt in DB.
SettingCacheService::update(...) aktualisiert den Datei-Cache nur für den definierten Teilbereich.
UI-Helfer appSetting(...) liest danach aus Datei-Cache.

Wenn DB und Datei scheinbar nicht zusammenpassen

Das ist oft erwartbar, solange es um nicht-gecachte Keys geht.

Prüfregel:

Geht es um appSetting(...)-Keys? Dann Datei-Cache relevant.
Geht es um SMTP/SSO/API-Details? Dann DB ist massgeblich.

Betriebs-Hinweis

Direkte DB-Änderungen an gecachten appSetting(...)-Keys werden erst wirksam, wenn der Datei-Cache aktualisiert wurde (z. B. durch erneutes Speichern in den Settings).

2.1 KiB Raw Blame History