Admin-editierbare Einstellungen ohne komplexen Code

Apps stehen vor einem ständigen Problem. Einige Einstellungen gehören in eine .env-Datei. Andere Einstellungen müssen über ein Admin-Panel geändert werden können, ohne dass ein neues Code-Deployment erforderlich ist. Beispiele hierfür sind Website-Namen, Zeitzonen oder Registrierungseinstellungen.

Viele Entwickler speichern diese in einer Datenbank, verursachen dabei aber Chaos. Man landet bei zwei verschiedenen Wegen, um Daten zu lesen. Ein Teil der App nutzt config(), während ein anderer ein Datenbankmodell verwendet. Dies führt zu Fehlern, bei denen Einstellungen inkonsistent sind.

Dies lässt sich vermeiden, indem man einen einzigen Lesepfad verwendet. Behandeln Sie die Datenbank als eine Ebene, die Ihre Konfiguration beim Booten überschreibt.

So bauen Sie es auf:

• Nutzen Sie eine einzige „Single Source of Truth“. Die Datenbank hält den Wert vor, aber die Anwendung liest ihn ausschließlich über config(). • Nutzen Sie typisierte Klassen. Verwenden Sie anstelle von losen Arrays Klassen mit strikten Typen. Dies verhindert Tippfehler und stille Fehler. • Laden Sie die Einstellungen während des Boot-Prozesses. Nutzen Sie einen Service Provider, um Datenbankwerte abzurufen und in das config-Array zu übertragen.

Achten Sie auf diese zwei technischen Fallen:

  1. Die Zeitzonen-Falle Laravel legt die Zeitzone früh im Boot-Prozess fest. Wenn Sie den Konfigurationswert später ändern, verwendet PHP weiterhin die alte Zeitzone. Sie müssen date_default_timezone_set() manuell aufrufen, um die globale PHP-Einstellung mit Ihrem neuen Konfigurationswert zu synchronisieren.

  2. Die Neuinstallation-Falle Eine neue App hat noch keine Datenbanktabellen. Wenn Ihr Boot-Prozess fehlschlägt, weil die Tabelle für die Einstellungen fehlt, wird die App nicht starten. Sie können keine Migrations ausführen, wenn die App nicht bootet. Kapseln Sie Ihre Einstellungslogik in einen try/catch-Block. Dies ermöglicht es der App, auf die .env-Standardwerte zurückzugreifen, bis Sie Ihre Migrations ausgeführt haben.

Ein weiterer Tipp zur Sicherheit: Wenn Sie eine Funktion wie die Registrierung deaktivieren, verstecken Sie nicht einfach nur den Button in der Benutzeroberfläche. Entfernen Sie die Funktion vollständig aus der Konfiguration. Wenn Sie die Funktion aus der Konfiguration entfernen, verschwinden auch die Routen. Ein verstecktes Formular mit einem aktiven Endpunkt stellt ein Sicherheitsrisiko dar. Eine fehlende Route liefert einen 404-Fehler zurück.

Halten Sie Ihren Code einfach. Ihre Controller und Views sollten nicht wissen müssen, ob eine Einstellung aus einer Datei oder einer Datenbank stammt. Sie sollten nur config() sehen.

Quelle: https://dev.to/nasrulhazim/admin-editable-settings-without-giving-up-config-2cj0