Settings Laravel Package

Getting Started

1. Install Dick CRUD first — dick/settings depends on dick/crud, which is not auto-discovered on Laravel 5-era versions:

   composer require dick/crud
   composer require dick/settings
   

2. Register the provider in config/app.php (providers array):

   Dick\Settings\SettingsServiceProvider::class,
   

3. Publish and migrate:

   php artisan vendor:publish --provider="Dick\Settings\SettingsServiceProvider"
   php artisan migrate
   

4. Look first at the published SettingsCrudController (usually app/Http/Controllers/Admin/SettingCrudController.php) — this defines the fields available in the admin UI (key, value, type, and optionally a group/description). Extend it rather than editing the vendor copy.
5. Add a menu entry to your Dick admin sidebar pointing to admin/setting, so editors can reach the interface.
6. First use case: create a site_name setting in the UI, then read it anywhere with Setting::get('site_name') (or the package-provided helper, depending on version). Confirm the round-trip in php artisan tinker before wiring it into views.

Implementation Patterns

• Seed defaults. Create a seeder that inserts every setting key your app expects. This means Setting::get('key', 'fallback') calls never have to handle "missing row" in production, and new environments bootstrap predictably.
• Wrap retrieval in a helper. A small settings('mail.from', config('mail.from')) function keeps controllers/views clean and gives you one place to add caching later.
• Cache the whole table. The settings table is tiny but queried on nearly every request. Load all rows once (e.g. in a repository bound as a singleton, or a Cache::rememberForever('settings') call) and bust the cache from the CRUD controller's store/update/destroy methods.
• Grouping. If the flat key/value list becomes too long, add a group column and either split into multiple CRUD panels or filter the list in the controller. This preserves the "one settings screen per area" UX (e.g. "Mail", "Social", "Branding").
• Typed values. Use the type column (or a switch in the CRUD controller) to store booleans as 1/0, images as paths, arrays as JSON. Retrieve through accessors on an extended Setting model so callers get real types back.
• Config override. A common pattern: seed settings from config, then have settings take precedence at runtime — config(['mail.from' => settings('mail.from', config('mail.from'))]) in a service provider's boot().
• Multi-environment. For local/testing, point settings at a SQLite connection or skip the table entirely via a Setting::get wrapper that short-circuits when the table is missing.
• Extend the CRUD controller to add upload fields (image, file) with the appropriate type => 'upload' config — this is where most day-to-day customization happens, not in the vendor code.

Gotchas and Tips

• This package is abandoned. dick/settings and dick/crud were renamed to backpack/settings and backpack/crud. If you are starting today, install Backpack instead — the concepts are identical but Backpack is maintained. Migrating an existing install is a namespace/config-key rename and is not trivial.
• Laravel 5.x only. Composer will likely refuse to install on Laravel 5.5+ without --ignore-platform-reqs or a fork. Do not attempt to use it on Laravel 8+.
• key is a reserved word in MySQL. Quote it in raw queries or alias it (settings.key as setting_key) — otherwise you get cryptic syntax errors. Some migrations in this era renamed it to key_name for exactly this reason.
• value is TEXT. Booleans come back as "1"/"0", arrays as JSON strings. Cast on read; don't rely on the column type.
• No cache invalidation out of the box. If you cache, wire the bust into the CRUD's save hooks (or use a model observer on Setting), or editors will change a value and see nothing happen.
• Everything is exposed to anyone with /admin access. Add your own policy or middleware if some settings (e.g. SMTP credentials) should be super-admin only.
• Secrets sit in plaintext in the DB. Consider an encrypted cast on value if you store API keys, and remember backups of the settings table then contain those secrets.
• vendor:publish is required — there is no auto-discovery in this era. If the UI 404s, you usually forgot to register the provider or forgot to publish the CRUD routes.
• "Class 'Dick\CRUD..." not found almost always means dick/crud is missing or its provider is unregistered — fix that before debugging settings itself.
• Extension points: override the published Setting model (in app/) to add accessors/casts; override SettingsCrudController to add fields; use the service provider's bindings if you need to swap the repository. Never edit vendor/tabacitu/... directly — you will lose changes on composer update.