Weave Code
Laravel Settings Laravel Package
unisharp/laravel-settings
Laravel Settings gives your app persistent, database-backed configuration with a simple helper API. Store and retrieve key-value settings at runtime, cache them for performance, and avoid editing config files. Supports defaults, type casting, and quick setup for any Laravel project.
Persistent settings manager for laravel, translations are supported.
Frequently asked questions about Laravel Settings
- How do I install unisharp/laravel-settings and create its settings table in Laravel?
- Install it with Composer using composer require unisharp/laravel-settings, then let Laravel service-provider auto-discovery register the package. Publish any package config and migration files, then run php artisan migrate to create the key-value settings table. Exact publish tags and provider behavior should be checked against the package version because the last release is from 2018. On modern Laravel, run this in a compatibility spike before adopting it broadly.
- Does unisharp/laravel-settings support Laravel 10, Laravel 11, or PHP 8?
- The package's last release was 2018-01-29, so it was built for the Laravel 5.x and PHP 7.x era rather than modern Laravel 10/11 and PHP 8.x stacks. The README alone is not enough to assume Composer constraints, service-provider discovery, facades, or migrations will work on those versions. Treat Laravel 9/10/11 and PHP 8.x as requiring a compatibility spike, and be prepared to fork with small patches or choose another package. This age-related compatibility risk is the main technical concern.
- How do I get a setting value using the setting() helper or Settings facade?
- The package exposes a global setting() helper and a Settings facade for retrieving values by key, including dotted keys for nested data. Typical usage is setting('site.name') or Settings::get('site.name'), with a default value passed as a fallback where supported. Wrap these calls in your own settings repository or service so helper and facade usage does not spread through the codebase. Check the package API for exact method signatures and default-argument behavior in your installed version.
- How does caching work in laravel-settings, and how do I clear stale cached settings?
- The package includes a built-in cache layer to reduce repeated database queries when settings are read often. Writes should invalidate or refresh the relevant cache entries, but the 2018-era code means you must verify write-path invalidation, cache-driver support, and multi-node behavior in your environment. After deployments or manual database changes, clear the configured Laravel cache store or use any package-provided refresh method. Test stale-read scenarios before relying on it for settings changed by admins.
- Can unisharp/laravel-settings store arrays, nested values, booleans, or null safely?
- The package is described as supporting array and nested data with dotted keys, and values are persisted in the database rather than config files. Serialization details matter: booleans, nulls, numeric strings, and complex arrays can round-trip differently depending on how the value is encoded and cast. Test the exact types your application needs, especially if you plan to store JSON-like structures. Avoid storing complex objects unless you control and verify the serialization behavior.
- How do I define default values for settings that do not exist yet?
- Defaults let you retrieve a fallback when a key is missing, typically by passing a default argument to the helper or facade call or by defining fallback values in your own settings service. Defaults are not a substitute for seeding known settings, especially for admin-editable options that should appear in the database. Define a clear fallback policy for each setting and test missing-key behavior. Wrapping access in an internal repository makes defaults easier to centralize.
- Is unisharp/laravel-settings safe for storing secrets, API keys, or passwords?
- No, it should not be treated as a secret store. The package provides a database-backed key-value store without built-in encryption, audit trails, or validation according to the technical assessment. Keep passwords, API keys, and regulated configuration in environment variables or a dedicated secret manager. Use laravel-settings only for low-risk operational settings such as site-wide options and admin-editable preferences.
- Can unisharp/laravel-settings handle multi-tenant or per-tenant settings?
- There is no built-in multi-tenant isolation described; it is a global key-value settings store unless you add tenant scoping around it. You could namespace keys by tenant or build a repository that adds tenant IDs, but that becomes your own design and must be tested for cache-key collisions and data leakage. For a real multi-tenant settings service, consider a custom table and repository or a package with explicit tenant support. Do not assume the helper API isolates tenants by itself.
- Is unisharp/laravel-settings maintained, and is it suitable for production?
- Maintenance risk is the main issue: the last release was 2018-01-29 and the project has community-scale traction, so support is limited. It can be suitable for low-risk, low-volume settings in a legacy Laravel app, especially when hidden behind your own SettingsRepository interface. For modern Laravel or business-critical configuration, budget for a fork, compatibility patches, or replacement, and set a fork-or-replace decision date. Avoid it for authentication secrets, billing controls, or regulated configuration.
- What are good alternatives to unisharp/laravel-settings for Laravel settings management?
- Alternatives include dedicated packages such as spatie/laravel-settings for typed settings, a small in-house settings table with a repository and cache layer, or Laravel config and environment variables for values that do not need runtime editing. Choose based on whether you need typed settings, encryption, audit logging, validation, multi-tenant isolation, or active maintenance. If you only need a handful of admin-editable options, a custom key-value table is often the lowest-risk path. Keep secrets out of any database-backed settings package.
Weaver
How can I help you explore Laravel packages today?