Impostazioni modificabili dall'amministratore senza codice complesso
Le applicazioni affrontano un problema costante. Alcune impostazioni appartengono a un file .env. Altre devono poter essere modificate tramite un pannello di amministrazione senza dover distribuire nuovo codice. Gli esempi includono nomi del sito, fusi orari o impostazioni di registrazione.
Molti sviluppatori le memorizzano in un database, ma creano un caos. Si finisce per avere due modi per leggere i dati. Una parte della tua app usa config() mentre un'altra usa un modello del database. Ciò porta a bug in cui le impostazioni sono incoerenti.
Puoi evitare questo problema utilizzando un unico percorso di lettura. Tratta il database come uno strato che si sovrappone alla tua configurazione all'avvio.
Ecco come costruirlo:
• Usa un'unica fonte di verità. Il database contiene il valore, ma l'applicazione legge solo tramite config().
• Usa classi tipizzate. Invece di array generici, usa classi con tipi rigorosi. Questo previene errori di battitura ed errori silenziosi.
• Carica le impostazioni durante il processo di avvio. Usa un service provider per estrarre i valori dal database e inserirli nell'array di configurazione.
Fai attenzione a queste due trappole tecniche:
La trappola del fuso orario Laravel imposta il fuso orario nelle prime fasi del processo di avvio. Se modifichi il valore della configurazione in seguito, PHP utilizzerà ancora il vecchio fuso orario. Devi chiamare
date_default_timezone_set()manualmente per sincronizzare l'impostazione globale di PHP con il nuovo valore di configurazione.La trappola della nuova installazione Una nuova applicazione non ha tabelle nel database. Se il processo di avvio fallisce perché manca la tabella delle impostazioni, l'app non partirà. Non puoi eseguire le migrations se l'app non riesce ad avviarsi. Avvolgi la logica delle impostazioni in un blocco
try/catch. Questo permette all'app di tornare ai valori predefiniti del file .env finché non esegui le migrations.
Un altro consiglio per la sicurezza: Quando disabiliti una funzionalità come la registrazione, non limitarti a nascondere il pulsante nell'interfaccia utente. Rimuovi completamente la funzionalità dalla configurazione. Se rimuovi la funzionalità dalla configurazione, le rotte scompaiono. Un modulo nascosto con un endpoint attivo è un rischio per la sicurezza. Una rotta mancante restituisce un 404.
Mantieni il codice semplice. I tuoi controller e le tue view non dovrebbero sapere se un'impostazione proviene da un file o da un database. Dovrebbero vedere solo config().
Fonte: https://dev.to/nasrulhazim/admin-editable-settings-without-giving-up-config-2cj0