- What is glorand/laravel-model-settings used for in a Laravel application?
- It adds flexible, per-model settings to Eloquent models so you can store configuration or preferences against individual records instead of a global config file. You define defaults, then read, write, check, and remove values through a small API on the model. Storage is pluggable with field, table, Redis, and generic cache drivers, and the package fires events so settings changes can hook into queues, broadcasting, and notifications. It suits things like notification preferences, feature toggles, or UI options scoped to a user, team, or tenant.
- How do I install laravel-model-settings and which Laravel and PHP versions are supported?
- Install it with composer require glorand/laravel-model-settings, then add the HasModelSettings trait to every Eloquent model that needs settings. Pick a storage backend globally with the MODEL_SETTINGS_DRIVER environment variable or per model with a protected $settingsDriver property. The current release targets PHP 8.2+ and Laravel 12+, so verify the package version against your project if you are still on an older Laravel release such as Laravel 9.
- Which driver should I choose: field, table, redis, or cache?
- Use the field driver for simple cases where settings live in a JSON column on the model's own table, and the table driver when you want a shared settings table with model_type and model_id columns. The redis and cache drivers keep settings outside your relational schema, which is fast but means the store becomes the only copy of the data. Define your persistence requirements first: durable business data belongs in the field or table drivers, while ephemeral or reconstructable preferences can safely live in Redis or cache.
- What are the risks of storing model settings in the cache driver?
- With the cache driver, Laravel's Cache facade is the only copy of the data rather than a read-through cache, so anything that flushes the store such as php artisan cache:clear or Cache::flush() wipes the settings of every model using that driver. Stores that evict entries under memory pressure can also drop settings at any time. The package documentation explicitly recommends the field or table drivers when settings must survive these events. If you use cache, pick a durable store and back the data up or make it reconstructable.
- Why does a bad MODEL_SETTINGS_CACHE_TTL throw ModelSettingsException?
- The cache driver validates the configured TTL before calling Cache::put(), so a value of 0, a negative number, or a non-numeric value throws a ModelSettingsException instead of silently deleting data. Settings are stored forever by default, and when a TTL is set it is refreshed only on write, never on read. That means a value read constantly will still expire if nothing writes to it, so do not treat a TTL as a sliding session lifetime. Keep MODEL_SETTINGS_CACHE_TTL a valid integer and validate environment configuration during deployment.
- Why do I get ModelSettingsException for an unsaved model when reading settings?
- In version 9.1.0 the table, redis, and cache drivers now require the model to actually exist in storage, not merely to have a primary key assigned. Code such as (new User(['id' => 5]))->settings()->all() that used to act as a lightweight reference read now throws an exception. Audit any code that fabricates models with a manual key before upgrading, and load the real model instead. The field driver and other behavior are otherwise unaffected by this change.
- How do I define default settings for a model?
- You declare an array of default settings on the model, and the package returns those values when a setting has not been stored yet. Defaults keep the get API predictable so callers do not have to null-check every setting. Once a value is written through the settings API, the stored value takes precedence over the default, and removing the setting falls back to the default again.
- Can I validate settings before they are saved?
- Yes, the package integrates with Laravel's validation system so you can apply rules to the data you set on a model. This keeps malformed values out of your storage backend and lets you reuse familiar rule arrays and custom rule objects. Combined with defaults, validation gives you a predictable contract for what a given model's settings may contain.
- Does the package fire events when settings are saved, restored, or deleted?
- Yes, ModelSettingsSaved, ModelSettingsRestored, and ModelSettingsDeleted events are dispatched around settings lifecycle changes. You can listen for them to trigger broadcasting, queued jobs, notifications, or cache invalidation in other parts of your application. Because these are standard Laravel events, they work with listeners, subscribers, and event fakes in tests.
- How do I handle concurrent settings updates or use a custom driver?
- There is no built-in optimistic locking, so concurrent writes can race in multi-user environments; wrap read-modify-write sequences in a transaction with lockForUpdate() or retry at the application level. Also watch performance on database-backed drivers, since settings are JSON serialized and deserialized and can add queries to hot paths. If the bundled drivers do not fit, you can register a custom driver and select it globally or per model, and you can rename the settings() accessor if it collides with an existing method.