Building a Settings System Clients Can Actually Use
Hard-coded text is the number one reason clients email you for trivial changes. A simple key-value settings table fixes it — if you get the caching and grouping right.
Every hard-coded string in a Blade template is a future email. Phone numbers change, taglines get rewritten, the hero heading is never right the first time. A settings table turns all of those from a developer task into a client task.
The Schema
Schema::create('settings', function (Blueprint $table) {
$table->id();
$table->string('key')->unique();
$table->text('value')->nullable();
$table->string('group')->default('general'); // drives the admin tabs
$table->string('type')->default('text'); // text|textarea|image|richtext
$table->string('label'); // human-readable field label
$table->timestamps();
});
The group, type and label columns are what make this more than a config file: the admin UI can render itself from the data.
Cache the Whole Table, Not Individual Keys
A page reads twenty settings. Twenty cache lookups is worse than one.
public static function allCached(): array
{
return Cache::remember('site_settings', 3600, fn () =>
static::pluck('value', 'key')->toArray()
);
}
public static function get(string $key, mixed $default = null): mixed
{
return static::allCached()[$key] ?? $default;
}
Invalidate on Write
public static function set(string $key, mixed $value): void
{
static::updateOrCreate(['key' => $key], ['value' => $value]);
Cache::forget('site_settings');
}
Without this, an admin saves a change, sees nothing happen, and loses confidence in the whole panel.
Always Provide a Fallback in the View
{{ $settings['site_tagline'] ?? 'Full Stack Web Developer' }}
A missing key should never white-screen the site. This also means a fresh install looks correct before anything is configured.
Group for the Admin UI
Grouping by general, hero, contact, seo lets you render tabbed sections automatically. A flat list of forty fields is technically the same data and practically unusable.
Know Where the Line Is
Settings are for content an admin changes. Anything that changes application behaviour — API endpoints, feature flags, credentials — belongs in config/ and .env, under version control and code review.