- What does laravel-admin-ext/config actually do?
- It is a laravel-admin extension that adds a web-based configuration manager to your admin panel. Administrators can create, edit, and delete config entries and maintain key/value application settings through the familiar dashboard UI instead of editing files in the config directory. Persisted values are loaded into Laravel's config repository at boot by the package service provider.
- How do I install laravel-admin-ext/config?
- Install the package with Composer and then import it into the admin panel with the admin:import Artisan command. The standard laravel-admin flow applies: publish and migrate as needed, then register the menu entry so the settings screen appears. Your application must already resolve encore/laravel-admin 1.x for any of this to work.
- Which Laravel and PHP versions does laravel-admin-ext/config support?
- Expect Laravel 5.5 through 6.x, PHP 7.1 to 7.4, and laravel-admin around 1.6 or 1.7, since the last tagged release was in December 2019. Those constraints should be verified with composer why-not before you commit. Anything newer than Laravel 6 should be treated as unsupported.
- Can I use laravel-admin-ext/config with Laravel 10 or Laravel 11?
- No. The Composer constraints will almost certainly fail dependency resolution, and even if they passed, the code would likely break at runtime on framework APIs removed since Laravel 6. For modern Laravel versions you should use Filament with a settings plugin, Laravel Nova with a settings card, or a small custom settings table and admin screen.
- Do I need laravel-admin to use this config manager?
- Yes. The admin panel is the entire integration surface: the package is essentially a CRUD screen over a config table plus a service provider that hydrates Laravel config at boot. Teams running Filament, Nova, or a bespoke back office get no leverage from it. It is only viable inside an existing laravel-admin 1.x deployment.
- Who can view and edit settings after installing it?
- The extension relies on laravel-admin's existing authentication and access control, so access is governed by the menu permissions you assign. Any user granted that menu permission can see and edit every stored value. If some settings are sensitive, you need additional restrictions beyond what the package provides.
- Is it safe to store API keys or credentials with this configuration manager?
- No, not without extra work. Values are written to the database in plaintext and are visible to anyone with the menu permission, which is a compliance and blast-radius problem. If any managed setting is a secret, the package is disqualified unless you add an encryption or vault layer on top.
- Why aren't my database config changes taking effect in Laravel?
- Config precedence is the usual culprit. Values hydrated from the database at boot can be silently shadowed by config files or by a stale bootstrap/cache/config.php, and multi-node deployments can drift out of sync. Clear and rebuild the config cache after changes, and validate the precedence rules in a proof of concept before relying on the package.
- Does laravel-admin-ext/config keep an audit trail or allow rollback?
- No. There is no record of who changed a value, when they changed it, or what the previous value was, and there is no built-in rollback. Teams subject to SOC2, PCI, or internal change-management rules would have to add logging and versioning themselves. Note also that a malformed value can break the very request cycle that hosts the editing UI.
- Is laravel-admin-ext/config still maintained, and what are the alternatives?
- The last release was December 2019, the repository has roughly 97 stars and zero dependents, so there is no ecosystem pressure to keep it compatible and adopting it means owning a fork. On modern stacks the practical alternatives are Filament with a settings plugin, Laravel Nova with a settings card, or a small in-house settings repository with caching and an audit log. Whichever you pick, confirm the Laravel, PHP, and admin-panel version matrix first and test config-cache behaviour in staging.