- How do I install and set up janiskelemen/laravel-setting?
- Install it with composer require janiskelemen/laravel-setting, then publish the package config file and migration and run the migration. The package follows the conventional Laravel shape, so the service provider is auto-discovered and you get a Setting facade plus a setting() helper without any bootstrapping. You can optionally override the table name through an environment variable in the published config. A working read/write path takes well under a day for a competent Laravel engineer.
- Which Laravel and PHP versions does laravel-setting support?
- The package is built as a standard Laravel package with a service provider, facade, publishable config and publishable migration, so it targets current Laravel releases. The exact Laravel and PHP compatibility range is declared in its composer.json, so check that constraint against your target version before committing. Because community signal is low, also confirm which versions are actually exercised by its automated tests and CI rather than trusting the constraint alone.
- How do I read and write settings, and how is this different from config()?
- You read and write through the Setting facade or the setting() helper, using a simple expressive API that supports grouping and typed values. The difference from config() is timing: config() is deploy-time and immutable at runtime, while this package persists values in the database so an operator can change them without a release. Typical uses are feature flags, mail throttles, branding and integration endpoints. Think of it as the runtime-editable tier above static config, not a replacement for your config files.
- Can laravel-setting store booleans, arrays and other typed values?
- Yes, the package supports typed values and grouping, so booleans, floats and arrays are round-tripped through JSON rather than stored as raw strings. The caveat is that JSON round-tripping invites edge cases such as the string "false" versus the boolean false, null versus an absent key, and array merge versus replace on partial updates. Test your specific value shapes against the driver you choose before relying on them in business logic.
- What happens when a setting key is missing or the stored value is corrupt?
- The package supports config fallback and default values, which means a mistyped or missing key generally resolves to a default rather than raising an exception. That is convenient in development but a footgun in production, because the misconfiguration surfaces as wrong business behavior instead of an error. Explicitly test the cases that matter to you: missing key, corrupt JSON payload, and a missing table. Where correctness is critical, treat the returned default as a signal to validate rather than a safe outcome.
- How does caching work and is it safe across multiple servers?
- Settings are wrapped in a cache layer so frequently used values stay fast, and the persistence layer itself is abstracted behind a contract with multiple driver implementations. The highest-severity unknown is cache coherence: if values are memoized per process, multi-node deployments can serve divergent values after a write unless invalidation goes through a shared store. Before committing, read the cache and store classes and verify the flush mechanism and driver semantics. Also check whether writes from another node are visible to the node serving the request.
- Can I use laravel-setting for multi-tenant applications?
- Only if the group and scope mechanism can be namespaced per tenant, which you should verify in the source before adopting. Without tenant-aware scoping the store is effectively global per application, which makes it a shared global rather than a per-tenant configuration layer. The package fits best in a monolith or modular monolith with a small internal admin surface. If you need per-tenant settings, namespace groups deliberately and keep naming conventions strict.
- Can I use laravel-setting in tests without hitting the database?
- Yes, that is one of the benefits of the design: storage is abstracted behind a contract with driver implementations, including lighter-weight alternatives to the database driver. Swapping to an in-memory driver keeps your test suite off the database and makes read/write assertions fast. Check which drivers ship with the version you install and how the config selects them. This also gives you a clean seam for isolating settings in feature tests.
- Is laravel-setting suitable for storing API keys and secrets?
- No. The package is a configuration store, not a secrets manager, and values land in a plain database column. Keep credentials, tokens and private keys in your environment or a dedicated secrets backend, and reserve this package for runtime-editable non-sensitive settings. Treat any secret that reaches this table as exposed and plan rotation accordingly.
- Is laravel-setting actively maintained and what are the risks?
- It is MIT licensed with a small codebase, a single maintainer and modest community signal, so the realistic failure mode is abandonment rather than anything malicious. Recent release activity is a positive sign, but activity is not a support contract, and a bus factor of one means you should be prepared to vendor or fork it. An afternoon reading the provider, store and cache classes will tell you more than the star count. If you need audit trails, versioned settings or guaranteed multi-node invalidation, verify those behaviors or consider building the thin layer yourself.