- How do I install outl1ne/nova-settings in a Laravel Nova app?
- Install it with composer require outl1ne/nova-settings, then publish the package config and migrations and run the migrations. Register your settings classes in config/nova-settings.php, defining groups and native Nova fields. You need Laravel Nova installed and licensed because the editing UI lives inside Nova.
- Does outl1ne/nova-settings require Laravel Nova?
- Yes. It is a Nova tool, so the admin UI only works in a Laravel application with a valid Nova license. Without Nova the package has no editing surface, although the underlying settings are stored in a normal database table. Treat Nova licensing as part of your procurement and renewal plan.
- How do I read settings values in my Laravel code?
- Use the package helpers: nova_get_setting() for a single key and nova_get_settings() for a set of values. Write values with nova_set_setting(), typically from Nova fields rather than application code. Keep reads behind these helpers or your own repository so you are not coupled to the table schema.
- Can I use outl1ne/nova-settings for multi-tenant or per-locale settings?
- Not out of the box. Settings are stored once globally, not per tenant, environment, or locale. If you need scoping, plan to wrap or extend the storage layer from the start, which adds work beyond the basic install.
- Does this package keep an audit trail or version history of settings changes?
- No. Changes are destructive overwrites, with no first-class audit, versioning, or rollback. For compliance or customer-facing values, add your own audit trail with observers or an activity log, or restrict the tool to low-risk settings.
- What happens if a setting has no value or is missing?
- The package does not define a single default-value story for every case, so absent settings can surface as null unless you seed values or provide fallbacks. Unhandled nulls are a common production surprise. Decide whether missing values should be null, seeded, or read from config, and handle that in your access layer.
- Is it safe to store secrets or infrastructure config in nova-settings?
- No. It is intended for runtime-editable operator values such as site name, support email, branding, or short-lived feature flags. Secrets and infrastructure configuration belong in environment variables or config files. Keep an explicit allowlist of settings that are genuinely safe to edit from the admin panel.
- Which Laravel and Nova versions does outl1ne/nova-settings support?
- The package targets Laravel 9/10/11-era applications with Nova 4/5 and PHP 8.1+, and works with any relational database and cache driver. Check the composer constraints in the repository before upgrading Laravel or Nova major versions. Nova major-version licensing means upgrades can affect both the package and your license.
- How do I test settings changes or avoid cache issues in production?
- Because values live in the database, watch cache coherency across app servers and queue workers if you cache settings. Clear or version your cache when settings change, and test reads through the helpers rather than querying the table directly. A short test that writes via nova_set_setting() and reads via nova_get_setting() catches most integration issues.
- What are the risks of relying on outl1ne/nova-settings, and what is the exit plan?
- The main risks are Nova license coupling, a small maintainer footprint, and no built-in audit or scoping. It is acceptable as a convenience layer, not as the only path to critical operational values. Your exit plan is straightforward because values are stored in a single table: read it directly, keep helper access isolated, and be ready to swap the UI.