Laravel Nova Simple Setting Laravel Package

Getting Started

This package is a Nova tool that gives you a database-backed key/value settings screen inside the Nova admin panel, so non-developers can change copy, feature flags, and similar values without a deploy. v0.3.1 is a compatibility release: it adds Laravel 11 support. Functionally it is the same as v0.3.0, so treat this as an upgrade-readiness release rather than a feature release.

1. Confirm your stack first. Laravel 11 drops support for older Nova versions, so check that you're on a Nova release that itself supports Laravel 11 (Nova 4.32+ or Nova 5). If you're still on Laravel 10 + Nova 4.x, stay on v0.3.0 — nothing in v0.3.1 improves your setup.

2. Install and pin. The package is still pre-1.0, so use a tilde constraint rather than a caret:

composer require elipzis/laravel-nova-simple-setting:~0.3.1

3. Publish and migrate. List the available tags before assuming names, then publish the config and migration and run it:

php artisan vendor:publish --provider="ElipZis\NovaSimpleSetting\NovaSimpleSettingServiceProvider"
php artisan migrate

4. Register the tool in app/Providers/NovaServiceProvider.php:

public function tools()
{
    return [
        new \ElipZis\NovaSimpleSetting\NovaSimpleSetting(),
    ];
}

5. First use. Open the Nova sidebar, add a setting, then read it back in a Tinker session to confirm the accessor name and return type before wiring it into views. Do this once manually — it clarifies more about the package's behaviour than the README will.

Where to look first: the published migration (column names and value column size), the published config (table name, caching options), and vendor/elipzis/laravel-nova-simple-setting/src/ for the read helper or facade. The source is small enough to skim in ten minutes, and you'll need to.

Implementation Patterns

Wrap access in a single app-level service. Don't scatter the package's helper across Blade templates and controllers. Create one class — App\Support\Settings — that reads through the package and applies casting. Every setting in the package is effectively a string, so booleans, integers, and JSON need to be decoded in one place:

class Settings
{
    public static function bool(string $key, bool $default = false): bool
    {
        $value = static::raw($key);

        return $value === null ? $default : filter_var($value, FILTER_VALIDATE_BOOL);
    }
}

This indirection also means swapping the package out later is a one-file change.

Seed defaults in a seeder, not in the UI. Nova settings screens are easy to leave half-configured, and then production silently relies on ?? fallbacks scattered through the code. Ship an idempotent seeder using updateOrCreate so fresh environments and new keys are consistent and code-reviewable.

Group keys by prefix. Use namespaced keys like billing.invoice_footer and mail.from_name. When the settings list grows past a couple of dozen rows, an ungrouped flat list becomes unusable in the Nova UI, and prefixes let you build a filtered view or a custom field later without migrating keys.

Read at the right time in the lifecycle. For most values, read lazily at request time. Avoid reading settings in a service provider's register() or boot() — with config:cache in production this can mean a database hit on every artisan invocation, including deploys and queue workers, and it will hard-fail if the DB isn't reachable yet.

Overlay onto config rather than replacing it. A pattern that ages well: keep real config in config/*.php, then in a middleware or service provider apply database overrides on top via Config::set(). Your code keeps calling config('mail.from.name'), and settings become an override layer rather than a hard dependency.

Authorize the tool explicitly. Nova tools are visible to anyone who can reach Nova unless you gate them. Add a Gate check in the tool's canSee/authorize method or a Nova policy so only admins can edit settings — this is the difference between a convenience and an incident.

Testing. Use RefreshDatabase and set the rows you need in setUp() rather than relying on whatever the seeder produced. Because the package stores plain strings, tests should assert on your Settings wrapper's typed output, not on raw rows.

Gotchas and Tips

Verify the release before trusting it. v0.3.1's notes are three Dependabot commits plus a "Laravel to 11" line — no code changes are described. Diff v0.3.0...v0.3.1 (or at minimum the composer.json constraints) before upgrading. If the illuminate/* requirement was widened without the package being tested against Nova 5, smoke-test the tool screen immediately after upgrading, not a week later.

No cache invalidation is provided. If you add caching around reads (you should, for values used on every request), you must clear it when a setting is saved. Hook the package's save event if one exists; otherwise, don't cache and accept the query, or run values through Cache::rememberForever with an explicit bust in your own save path. Silent staleness here is the most common complaint with settings packages.

Pre-1.0 semver is real. 0.3.x patches can and do change behaviour. Pin with ~0.3.1, commit the lockfile, and read the diff on every bump.

Watch the value column type. Settings migrations often use string(255). A long JSON flag blob or an HTML footer will be silently truncated. Check the published migration and change it to text before migrating in production — altering it afterwards on a populated table is a small but avoidable chore.

Laravel 11 upgrade specifics. Laravel 11 removed the default app/Http/Kernel.php and trimmed default config files. If you published this package's config under Laravel 10, re-publish and diff rather than assuming it merged cleanly — config:cache will happily bake in stale keys. Run php artisan config:clear and php artisan optimize:clear after upgrading.

Missing keys return null, not exceptions. Always supply a fallback at the call site. A setting deleted from the UI should degrade gracefully in a Blade template, not throw.

Never store secrets here. API keys and passwords belong in env or an encrypted cast. The settings table is rendered in Nova to every authorized user and often ends up in database dumps shared with contractors.

Debugging workflow. When a value "isn't changing", check in this order: is the row actually persisted (query the table directly), is your app reading a cached copy, is config:cache serving a stale override, and is the key spelled identically (prefixes and dots are easy to typo). Four checks, in that order, resolve nearly every report.

Upgrade path if you skip it. Nothing in v0.3.1 is a breaking change for existing users, so there is no urgency — but if you're moving to Laravel 11 anyway, do both in the same branch so failures are attributable, and keep a rollback to v0.3.0 if the Nova screen breaks.