- Does efriandika/laravel-settings support Laravel 9, 10, or 11?
- The package targets Laravel 5.1.x, and its last release (v1.2.5, January 2017) added Laravel 5.4 support. The declared PHP and illuminate/* constraints almost certainly exclude PHP 8 and Laravel 9 and above, so composer require will likely fail outright on a current application. The realistic path on a modern stack is a maintained internal fork with updated constraints. Verify the exact composer.json requirements before planning any adoption.
- How do I install and register efriandika/laravel-settings in a Laravel 5.x app?
- Install with composer require efriandika/laravel-settings, then register the package service provider and facade alias manually in config/app.php. The package predates Laravel 5.5 package auto-discovery, so nothing is registered automatically and a fresh environment will boot broken if the runbook omits these steps. Publish and run the migration for the settings table before reading or writing values. Document the provider and alias registration alongside your other environment setup steps.
- Is efriandika/laravel-settings still maintained?
- The last release was January 2017, the repository has roughly 54 stars, and there is no evidence of a security policy or an active maintainer cohort. Nine years without a release on a package that touches both the database and the cache is a signal of abandonment rather than stability. Any adoption should be treated as taking on a maintenance commitment. An SBOM and vulnerability scan of the resolved dependency tree is advisable before merging anything.
- How do I get, set, and forget settings with this package?
- The package exposes a facade and helper methods to get a value by key, set a key to a new value, and forget a key entirely. Values are persisted in a database table and can optionally be cached for faster reads. Typical usage is a settings('key') style lookup in code paths that need a runtime-editable value. Because it is a thin convenience layer, the main design question is whether you want application behaviour editable at runtime at all.
- How does the caching layer work and can I disable it?
- The package can place a cache in front of the settings table, so reads may be served from your configured cache store rather than the database. Correctness depends entirely on invalidation happening on every write to every key. If cache invalidation is unreliable or your store cannot be targeted per key, stale values can be served indefinitely. Many teams disable caching and accept the database read, or verify the fork busts cache on every set and forget.
- Can I use this package safely on a multi-node production fleet?
- Cache coherency is the sharp edge here. On a multi-node fleet with a cache store that lacks tag or per-key targeting support, a set on one node can leave other nodes serving stale values until the entry expires. That class of bug surfaces as the setting did not take and is expensive to diagnose. Use a shared cache with reliable per-key invalidation, explicitly flush after every write, or disable caching entirely in clustered environments.
- What migration does the package publish, and will it affect my schema history?
- The package almost certainly publishes a migration that creates its settings table. Once run, that migration enters your schema history permanently and its ordering relative to your own migrations needs to be explicit. Review the published file before the first migrate and rename or adjust it if the ordering matters for your deployment. On a fork, keep the migration stable to avoid divergence between environments.
- Are setting values typed, or do they come back as strings?
- A database-backed key-value store typically returns raw strings, so booleans, integers, arrays, and nulls generally need coercion at every call site unless the wrapper does it for you. Typing disappearing is one of the hidden costs of moving configuration from code into a table. Confirm what the published migration creates and how values are cast before relying on any type assumptions. If the package does not coerce, wrap it in your own typed accessor layer.
- How do I test code that depends on this settings package?
- The facade sits over a shared global store, so any code path can read and mutate settings, which makes tests order-dependent unless you reset the store between cases. Clear both the table and the cache in setUp or use a fresh database per test. Wrapping the package behind your own small interface makes it injectable and lets you swap in an in-memory implementation for unit tests. This also isolates your codebase from a future fork or replacement.
- What are the alternatives to a database-backed settings package in Laravel?
- Native config files and environment variables cover most of the stated use case and stay versioned, diffable, and reviewable. Feature-flag tooling handles the runtime-toggle scenario with better auditing and rollback. If you genuinely need non-engineers to change values without a deploy, evaluate a maintained package such as spatie/laravel-settings or build a small internal table with explicit typing and invalidation. Name the capability gap first, then decide whether a 2017 dependency is the right way to close it.