Config Laravel Package

Getting Started

This is a settings editor for laravel-admin: it gives you an admin screen where non-developers can create/edit named config values, and it lets your application read those values back at runtime. Small package (97 stars, one maintainer, last release Dec 2019), so treat it as "a UI over a key/value table," not as infrastructure you build a platform on.

Minimal steps:

1. Confirm you're on laravel-admin 1.x and a Laravel version the extension was built for (roughly 5.5–6.x). If you're on Laravel 8+, expect to patch the package or skip it.
2. Install and import via the standard extension flow:

   composer require laravel-admin-ext/config
   php artisan admin:import config
   

   The import registers the menu entry, routes, and permission rows.
3. Look at config/admin.php (extensions array) and the admin_extensions table to confirm the extension is actually enabled — a missing menu item is almost always one of these two, not a bug in the package.
4. Read the source before trusting it: src/ (controller, Config model, routes) and the migration. The migration tells you the exact table/columns; the controller tells you how values are persisted and whether anything is cached.
5. First use case: a "Site settings" page with site_name, contact_email, footer_text, support_phone. These are the values marketing/support ask you to change weekly — perfect fit. Secrets (API keys, SMTP passwords) are a poor fit; keep those in .env.

The one thing to nail down immediately is the read path: how does the package expose a stored value to your app (a model call, a helper, or values merged into Laravel's config repository so config('site_name') resolves)? Check the README for your pinned version, then wrap it (see below) so nothing else in your codebase depends on the answer.

Implementation Patterns

Wrap the package behind one accessor. Your controllers, Blade views, and jobs should never call the extension directly. A thin Settings class gives you caching, defaults, and a migration path off the package later.

// app/Support/Settings.php
class Settings
{
    public static function get(string $key, $default = null)
    {
        return Cache::rememberForever("settings.{$key}", function () use ($key, $default) {
            return Config::where('slug', $key)->value('value') ?? $default;
        });
    }

    public static function flush(): void
    {
        Cache::flush(); // or a dedicated tag/store if your cache driver supports it
    }
}

Hook Settings::flush() into the model's saved/deleted events (or an observer) so edited values take effect immediately. Without this you get the classic "I changed it in admin and nothing happened" ticket.

Read once per request, share to views. Don't scatter Settings::get() calls through Blade — resolve the handful of values you need in a view composer or AppServiceProvider::boot() and View::share() them. That also makes the cache hit pattern obvious in profiling.

Use it for flags, not for secrets or structure. Good: display names, toggles (maintenance_banner_enabled), contact routing, feature flags read inside a middleware or policy. Bad: anything that must differ per environment and must be reproducible from git (queue names, storage disks, third-party credentials). If losing the row would break the app, it belongs in code or .env.

Type your values deliberately. A key/value table stores strings. Decide the contract per key: booleans as '0'/'1', arrays as JSON encoded on save and json_decoded on read, money as integer minor units. Centralize the casts in your Settings wrapper so Settings::bool('x') and Settings::array('x') exist and callers stop guessing.

Group by domain in the admin UI. One page/tab per concern — Site, Mail, Payments, Feature flags — rather than a 90-row wall of fields. The person editing should be able to find "footer text" without reading a list of slugs.

Seed defaults. Write a seeder or migration that inserts every key with a sane default. New environments then work without a manual admin session, and your code can assume keys exist. Pair it with Settings::get($key, $default) as a second line of defense.

Guard the screen. The import adds permission entries, but explicitly assign the config page to a super-admin or a dedicated "settings manager" role. Treat writing settings as a privileged action — it changes behavior for every user.

Deployment note. DB-backed settings are data, not code. Staging edits don't reach production, and production edits aren't in git. Decide this explicitly per key, and if a value is environment-specific, resolve it as Settings::get('key') ?: config('services.key') so .env stays the fallback.

Gotchas and Tips

• It's frozen in 2019. No releases since 2019-12-11, 0 dependents, single-maintainer extension. Before adopting, run the install on your actual Laravel version and check for PHP 8 deprecation notices, array-syntax issues, and str_*/array_* helper migrations. If it breaks, you're forking it — budget for that.
• laravel-admin itself is the bigger risk. If you're starting fresh, weigh this against a 30-line custom settings page using laravel-admin's form builder over a single settings row, or spatie/laravel-settings. For a handful of keys, the custom page is often less total work than debugging a 2019 extension.
• The migration is the first thing to read. Table and column names may collide with your existing schema; check whether it publishes a migration you control or runs one from the package. Never let a third-party migration auto-run against a table you already own.
• Plaintext in the database. Values are visible in the admin UI, in DB dumps, and potentially in query logs. Don't store API tokens or passwords here unless you add encryption via a model cast — and if you do, document that a lost APP_KEY means lost settings.
• No validation by default. The admin can save empty strings, malformed emails, or invalid JSON that only explodes in production. Add validation in your controller/model layer or through a mutator, and treat empty string vs. null as distinct (decide which one means "unset" and be consistent).
• Caching is yours to get right. php artisan config:cache does not cache these values; your own Cache::rememberForever does. Include a cache flush in your deploy script, and remember queue workers and multiple app servers need a shared cache store to see edits.
• Debugging a missing menu item, in order: extension row present in admin_extensions; extension listed in config/admin.php; php artisan admin:import config re-run; php artisan admin:import permission rows; menu cache cleared. That sequence resolves almost every install complaint.
• Extension points worth knowing: the shipped controller and model are ordinary classes — subclass or copy them to add field types, custom validation, or cache invalidation hooks. Publish and override the views if the form layout doesn't fit. And because everything goes through your Settings wrapper, swapping the whole package out later is a one-class change rather than a grep across the app.