Weave Code
Laravel App Settings Laravel Package
qcod/laravel-app-settings
Add a settings manager with UI to your Laravel app. Settings are stored in the database and cached for zero-query performance, with configurable inputs, sections, and styling (Bootstrap 4 by default). Includes a facade for easy access.
Laravel App Settings adds a complete settings manager with a UI to Laravel apps. Settings are defined declaratively in config/app_settings.php as inputs grouped into sections with titles, descriptions, and icons, then stored in the database. The package ships with Bootstrap 4 styling by default, but you can configure it to work with any CSS framework.
- Config-driven inputs grouped into titled sections
- Database storage cached for zero SQL queries
- Facade API via
AppSettings::get('app_name') - Customizable UI compatible with any CSS system
- Simple setup: publish config, run migrations
Frequently asked questions about Laravel App Settings
- How do I install qcod/laravel-app-settings in a Laravel app?
- Run composer require qcod/laravel-app-settings. On Laravel 5.4 or lower you must manually register the AppSettingsServiceProvider in the providers array and the AppSettings facade in the aliases array of config/app.php. Then publish the config with php artisan vendor:publish --provider="QCod\AppSettings\AppSettingsServiceProvider" --tag="config" and run php artisan migrate to create the settings table.
- Which Laravel and PHP versions does laravel-app-settings support?
- The README still documents Laravel 5.4 and 5.5 service provider registration, and shows a Travis CI badge, Vue 2 examples, Bootstrap 4 defaults, and Intervention Image v2 style mutators. That is documentation drift at minimum and possibly an unmaintained test pipeline, so support for current Laravel and PHP releases is unclear. Check the Composer constraints and run a real install against your target versions before committing.
- How do I define which settings appear on the settings page?
- Settings are declared in config/app_settings.php inside a sections array, where each section has a title, optional description and icon, and an inputs array. Each input defines the setting name plus its label, input type, and validation rules. Treat this as config-as-code with a database sidecar: adding a new setting is a code change plus a config deploy.
- How do I read a saved setting in Blade, a controller, or JavaScript?
- Use the setting() helper or the AppSettings facade, for example AppSettings::get('app_name'). Reads hit the cache rather than the database, so they are cheap to call in views and controllers. For the front end, the package suggests dumping setting()->all() into a window.App object as a pragmatic alternative to building an API endpoint.
- Is the settings page protected by authentication or authorization middleware?
- The package ships a write-capable settings form mounted at a configurable route, but the README documents no authorization hook or middleware configuration. You must wrap the route in your own auth and authorization middleware and verify that this is actually possible with the package's route registration. There is also no built-in audit trail recording who changed what, so plan a compensating control if that matters.
- How does the settings cache work and does it really reduce SQL queries to zero?
- Every setting saved through the package or its API is cached, so reads return from cache and issue no SQL queries. The tradeoff is coherence: only saves through the UI or package API clear the cache, so direct database edits will leave stale values behind. Use a shared cache store and check whether a documented invalidation hook exists for your workflow.
- Can I store API keys, SMTP passwords, or other secrets with this package?
- No. Values are persisted unencrypted in your application database, are not versioned, and have no audit trail. It is designed for a small bounded set of operator-editable values like app name, from address, maintenance flag, logo, or date format. Credential-like values such as API keys, SMTP passwords, and payment keys should stay in a dedicated secrets manager.
- Does laravel-app-settings work on a multi-node or containerized deployment?
- It can, provided you configure a shared cache store, since file or array cache causes per-node staleness across a load-balanced fleet. File and image uploads are another concern: ephemeral container filesystems will not survive restarts or scale-out. Also keep the remove_abandoned_settings option in mind, which must be false if you also use the package as a raw key-value store.
- What is the difference between qcod/laravel-app-settings and qcod/laravel-settings?
- This package is a thin, opinionated layer over qcod/laravel-settings: it adds a config-driven form schema and a Blade UI on top of the key-value settings table and cached read path. The core logic lives in the base package, so architecturally this is a convenience package rather than infrastructure. If you later want key-value settings without a UI, evaluate moving to qcod/laravel-settings directly.
- Is qcod/laravel-app-settings still maintained and safe for production?
- It is a single-maintainer package with modest adoption, so bus factor is a real consideration and you should plan to fork or vendor it if you adopt it. Before committing, confirm the current release supports your Laravel and PHP versions, that the settings route can be gated by middleware, and how the cache is invalidated. Also note that staging and production values can diverge silently because there is no promotion path between environments.
Weaver
How can I help you explore Laravel packages today?