Nova System Settings Laravel Package

Getting Started

This is a Nova tool that adds an admin-facing settings screen to your Nova panel, letting you manage application-level key/value configuration from the UI instead of shipping code changes for things like site name, contact email, feature toggles, or API credentials. It is a small, low-adoption package (3 stars, no dependents), so treat the README and source as the source of truth rather than assuming a stable public API.

Minimal setup:

1. composer require devloops/nova-system-settings
2. Publish and run whatever migrations ship with it (typically php artisan vendor:publish --provider="Devloops\\NovaSystemSettings\\..." then php artisan migrate). Verify the migration creates a settings table before running against anything shared.
3. Register the tool in your NovaServiceProvider (Nova 4+ style Nova::tools([...]) inside tools(), or the older config/nova.php tools array depending on the version you’re on).
4. Publish the config file if one exists and skim it — it usually defines the settings groups/fields shown in the UI.
5. Run php artisan nova:assets (or npm run dev if the tool ships uncompiled assets) and hard-refresh Nova.

First use case: take the values your team currently edits in .env or hardcodes in a config file — support email, footer text, "maintenance mode" banner, default pagination — and move the ones that change without a deploy into the Nova settings screen. Keep secrets in .env; this tool is for operational settings, not credentials.

Where to look first: the published config (defines the shape of your settings), the migration (shows storage model), and the tool's Vue components under resources/js (shows which field types are actually supported).

Implementation Patterns

Read through a single accessor. Whether the package exposes a facade, helper, or model, wrap it in your own thin service or config repository so the rest of your app doesn't depend directly on the package. If you ever swap the package out, you change one class.

// app/Support/Settings.php
public function get(string $key, $default = null)
{
    return \Devloops\NovaSystemSettings\...::get($key) ?? $default;
}

Always supply defaults at the call site. The database row may not exist yet on a fresh environment. settings('support_email', config('mail.from.address')) is safer than assuming a value is present.

Group settings to match how admins think. If the tool supports tabs/sections (most do), mirror them to your domain: General, Mail, Social, Feature Flags. A flat list of 80 keys is unusable.

Use it for toggles, not schema. Booleans for feature flags, strings for copy, JSON blobs for small structured config. Don't store relational data here — you'll fight the key/value model.

Blade and views: read once in a view composer or middleware and share the values, rather than hitting the settings store repeatedly in a loop. If the package caches internally, that's cheap; if not, you don't want N queries per page.

Seeding: ship a seeder or an artisan command that writes the default set on migrate --seed, so staging and production start from the same baseline as local.

Permissions: gate the Nova tool or individual sections behind Nova policies or canSee/authorize callbacks so non-admin Nova users (support, marketing) can't edit mail credentials or feature flags.

Environment parity: commit the published config, run the migration in every environment, and include the settings table in your deploy/seed scripts. A settings screen that works locally but not in staging is almost always a missing migration or a stale config cache.

Gotchas and Tips

• Cache invalidation is the classic bug. If the package caches settings (many do, to avoid a query per request), confirm it flushes on save. If not, add a saved hook or a middleware that clears the cache — otherwise admins save, refresh, and see the old value.
• Boolean and JSON casting. Stored values often land as strings ("1", "true", '{"a":1}'). Cast explicitly in your accessor; don't rely on PHP truthiness of "false".
• Config cache. If you expose settings through config(), remember php artisan config:cache freezes them at deploy time. Read directly from the settings store or clear the cache in your deploy hook.
• Nova version compatibility. This package was last released in Feb 2025 and has no dependents, so it has not been battle-tested across Nova 4/5 upgrades. Pin the Nova version in composer.json and smoke-test the tool after any Nova bump. Check the tool's composer.json constraints against your installed Nova before adopting.
• Low-maintenance risk. With 3 stars and 0 dependents, expect to read the source when something breaks and be prepared to fork. Budget for that in your evaluation; it's fine for a small internal admin panel, riskier as core infrastructure.
• Assets. If the tool ships uncompiled Vue, you need Node in your build pipeline. If it ships compiled assets, php artisan nova:assets after every update. Symptoms of mismatch: blank settings screen, console 404s.
• Secrets. Don't put API keys in the settings table unless you're encrypting the column and controlling DB access. Prefer .env + config for anything sensitive.
• Testing. Wrap your settings accessor in a fake/bound interface in tests so RefreshDatabase doesn't require the tool's tables, and add one integration test that saves a setting through the model and reads it back — that's where casting and cache bugs surface.
• Extension points. If you need a field type the tool doesn't offer (date, file upload, rich text), check the Vue components directory — most of these tools expose a field registry you can extend. If not, that's your first fork candidate.