- Which Laravel and PHP versions does laravel-admin-core v4.0.1 support?
- The v4.0.1 release note only states that Laravel 13 support was added, so treat it as requiring Laravel 13 on PHP 8.3 or newer until you confirm otherwise. The version moved from 3.0.22 to 4.0.1, which almost certainly means older Laravel versions were dropped. Always check the composer.json constraint in the tagged release before scoping any work. If your estate is on Laravel 10, 11, or 12, plan to stay on the 3.0.x line and track security patches there.
- How do I install laravel-admin-core in a Laravel application?
- Install it with Composer using the exact version you have validated, then publish the package's config, migrations, and assets. The service provider is auto-discovered, so manual registration is usually unnecessary. Run the migrations and review the published config before exposing any admin routes. In brownfield apps, register the package's route group and middleware alongside your existing admin routes rather than replacing them.
- What features does laravel-admin-core include out of the box?
- It provides the foundational pieces of an admin panel: admin authentication, role and permission management, menu and settings modules, and reusable CRUD scaffolding. It is intentionally a core layer rather than a full UI framework, so you own and extend the Blade views, controllers, and routes. That makes it a good fit for teams who want a lightweight, forkable, in-repo admin base instead of a batteries-included product.
- Is there an upgrade guide for laravel-admin-core 3.0.22 to 4.0.1?
- No upgrade guide, breaking-change list, or deprecation notice ships with v4.0.1; the release note only mentions Laravel 13 support. Because the version jumped a major, diff the 3.0.22 and 4.0.1 tags directly before upgrading. Pay particular attention to published config keys, route names, middleware aliases, view namespaces, and database schema changes. Treat this as a framework-coupled migration, not a routine package bump.
- How does laravel-admin-core compare to Filament, Nova, or Backpack?
- laravel-admin-core is a lightweight admin scaffolding layer, not a full admin framework with a rich component ecosystem. Filament, Nova, and Backpack give you batteries-included UI, form builders, and large plugin communities, at the cost of tighter coupling to their conventions. Choose laravel-admin-core when you want a small, forkable base you can own and shape. Choose a full framework when you need a mature UI and long-term third-party support.
- Will laravel-admin-core conflict with my existing admin routes, middleware, or auth guards?
- Greenfield integration is usually only days of work, but brownfield applications are where the friction lives. The package makes assumptions about route groups, middleware aliases, and auth guards, and those must be reconciled with your existing admin setup. Any views or routes you have already published and customised become merge conflicts on upgrade. Inventory your overrides before installing or upgrading.
- How do I test laravel-admin-core before deploying it to production?
- Branch first, upgrade Laravel in a scratch environment, and install the pinned package version there. Run the package's own tests plus your application's smoke tests, then exercise the admin surface: login, CRUD, menus, and permissions. Do the regression pass in staging, and roll out behind a feature flag if the admin panel is customer-facing. Do not bundle this upgrade with unrelated feature work.
- What transitive dependencies does laravel-admin-core introduce?
- The package pulls in whatever it needs for admin auth, permissions, and Blade-based views, and each of those dependencies must have a Laravel 13-compatible release before you upgrade. Build an explicit compatibility matrix covering Laravel version, PHP version, package major, and every dependent package. Because Laravel 13 support landed very recently, adjacent packages may lag behind. Verify each one before committing to an upgrade window.
- Is laravel-admin-core actively maintained, and is there a security policy?
- Release cadence is low and punctuated by major jumps with thin release notes, and the project appears to be single-maintainer, which is a bus-factor-of-one risk. Support is community-only, with no documented response-time commitment. No formal security policy or CVE process is described, so plan your own patch path. Budget for owning a fork, because some patches will likely be local.
- Should I pin laravel-admin-core to ^4 or an exact version?
- During the upgrade window, pin to an exact or tilde constraint rather than ^4. The release note does not enumerate breaking changes, so a patch release inside v4 could still shift behaviour you depend on. Once your compatibility matrix and admin-surface regression pass are green, you can loosen the constraint. Also track upstream commits rather than waiting for tags, given the low release cadence.