- How do I install cendekia/nova-setting-tool in a Laravel Nova application?
- Install it with Composer using composer require cendekia/nova-setting-tool, then register the tool in your NovaServiceProvider tools() method. Publish the package assets and configuration, run the migrations, and seed your current title, copyright, and version values before enabling editing. Confirm the Nova, Laravel, and PHP constraints in Composer match your application first, and test the full flow in staging rather than production.
- Which Laravel, PHP, and Nova versions does this package support?
- Version support is defined by the package's Composer constraints, so check them against your exact Laravel, PHP, and Nova major version before adopting. Nova major releases are a common source of tool breakage, so run a staging spike covering install, tool registration, persistence, and rendering. If your Nova version is not covered, pin an older release or wait for an update.
- Where does nova-setting-tool store settings, and are they cached?
- Settings are stored as key/value pairs in the database, which is why the package requires publishing and running migrations. Caching behavior is not clearly documented, so verify in staging whether values are cached and how edits invalidate the cache, since stale values after a save are a common failure mode. If caching is involved, include a cache clear in your deploy and rollback steps.
- Can I limit settings editing to specific Nova users or roles?
- Yes, access should be gated through Nova's standard tool authorization, typically a canSee callback on the tool registration or a Nova gate or policy. Restrict editing to trusted admin roles instead of exposing the tool to every Nova user. Even though these are presentation values, broad write access lets someone change branding across the entire admin panel.
- Does nova-setting-tool replace .env and config files for application configuration?
- No. Treat it as a convenience layer for presentation settings such as app title, copyright text, and version label, not as the source of truth for runtime or security-critical configuration. Keep .env and config files for secrets, infrastructure endpoints, and anything the application needs at boot. Preserve config fallbacks so pages still render if the package or its storage is unavailable.
- Does it support multi-tenant or per-environment settings?
- It is not designed as a multi-tenant or per-environment settings platform; it targets a single admin surface for branding-style values. If you operate multiple tenants or distinct environments, keep those overrides in configuration or a purpose-built settings package. Using this tool for multi-tenant overrides without a proven cache and invalidation model adds unnecessary risk.
- How do I add a custom setting such as a logo or support email?
- The package is described as simple to customize, so the usual path is publishing its config and views and extending the settings form with additional key/value fields. Inventory the settings you need first, map only safe presentation values, and keep fallbacks in your Blade views. Anything security-sensitive should stay in code or environment configuration.
- Are setting changes audited or attributable to an admin user?
- Audit history is not part of the described feature set, so assume changes are not attributable to a specific admin unless you add logging yourself. If traceability matters, log updates through an observer or Laravel activity logging. For branding text this is often acceptable, but make that decision deliberately before rolling out.
- What happens if a setting is missing or the database is unavailable?
- Because values live in the database, a missing row or an unavailable database can leave the UI without a value. Always read settings with a fallback to config() or a hardcoded default so pages still render. Test both the missing-value path and the database-down path in staging before production rollout.
- Is the package actively maintained, and what are the alternatives?
- Adoption signals are low and the maintainer footprint is small, so treat it as a convenience dependency rather than core infrastructure. Pin the version, assign an owner for Nova upgrade testing, and review package health periodically. Alternatives include a general settings package such as spatie/laravel-settings or keeping these values in config files, which may be safer if you need broader configuration management.