Basic Laravel Admin Panel Laravel Package

Getting Started

Install the package and let it scaffold the admin surface:

composer require balajidharma/basic-laravel-admin-panel
php artisan vendor:publish --provider="BalajiDharma\LaravelAdminPanel\AdminPanelServiceProvider"
php artisan migrate
php artisan db:seed --class="AdminPanelSeeder"

Then create or promote an admin user and log in at /admin. The first files to read are:

• config/admin-panel.php — guard, route prefix, middleware stack, menu locations, and feature toggles.
• routes/admin.php (published or in the package) — the canonical route names you will link to.
• src/Http/Controllers/ — the CRUD controllers you will either extend or replace.
• resources/views/vendor/admin-panel/ after publishing — the Blade overrides you are expected to make.

The first real use case is replacing a hand-rolled admin area: user management, roles/permissions (Spatie), menu/navigation management, settings, and activity logs come wired together, so you can spend the first day mapping your existing models into the package's CRUD and menu conventions rather than rebuilding auth screens.

Implementation Patterns

Use it as a starter kit, not a black box. Most teams get the most value by publishing everything once and committing the published config, migrations, routes, and views into the app. From then on you upgrade deliberately instead of inheriting vendor behaviour.

Gate everything through roles and permissions. The package leans on spatie/laravel-permission. Seed a stable permission list (users.view, users.update, settings.manage, etc.), assign them to roles in a seeder, and protect your own routes with the same middleware the package uses. Keep permission names in a config or enum so package routes and your custom routes stay consistent.

Drive navigation from the menu layer. Register your application's admin screens as menu entries (seeder or config, depending on version) rather than editing the sidebar Blade directly. That keeps the menu cache, active-state highlighting, and permission filtering working as designed.

Extend by subclassing, not editing. For custom columns or business rules, extend the package controller/model, bind your class in a service provider, and point the route at it — or publish the controller and change the namespace. Avoid patching vendor/.

Wrap package routes in your own group. Re-declare the admin route group in routes/web.php with your own middleware (2FA, IP allowlist, audit logging) and register the package routes inside it. This is the cleanest place to add cross-cutting admin concerns.

Use the settings repository as the config layer for runtime values. Values that operations staff should change (site name, mail from-address, feature flags) belong in settings; values that require a deploy belong in config/. Read settings through the package's helper/repository and cache them.

Pair it with your existing auth. If the app already has users, map the package's user model to yours (or configure the model class in config) before running seeders; retrofitting after seeding roles against the package's default User model is painful.

Gotchas and Tips

v4.0.1 is a major bump from 3.0.5. The release notes only show a back-merge from the 3.x branch, so there is no usable changelog detail. Treat the upgrade as breaking: read the diff between v3.0.5...v4.0.1, re-publish config/migrations/routes/views to a temp directory, and diff them against your committed copies before overwriting. Expect changes to route names, config keys, migration columns, and asset pipeline assumptions.

Re-publish, then reconcile — don't blind-copy. vendor:publish --force will silently discard your customisations to views, config, and menu seeders. Publish to a scratch path and merge by hand.

Clear the right caches. After any upgrade, run php artisan optimize:clear, then php artisan permission:cache-reset. Permission and menu caches are the usual cause of "the new route 403s" and "the menu item doesn't appear".

Migration order matters. Spatie's permission tables must exist before the package seeders run. If you publish package migrations, check their timestamps don't collide with your existing Spatie migrations.

Watch the guard. A mismatch between the package's configured guard and the guard your users authenticate against produces permission checks that fail closed and silently — users see a 403 with no log entry. Verify config/auth.php guards against admin-panel.guard.

Make seeders idempotent. Use firstOrCreate/updateOrCreate for roles, permissions, and menu items. Re-running the seeder on deploy is common, and non-idempotent seeders will duplicate menu rows.

View overrides are namespace-scoped. Overrides belong in resources/views/vendor/<package-namespace>/.... A file in the wrong directory is ignored with no warning, which looks like a caching bug.

Front-end assets. If you publish compiled assets, re-publish them after every upgrade; a stale CSS/JS bundle against new markup is a frequent "the layout is broken" report.

Test against seeded permissions. In feature tests, seed roles/permissions in setUp and assert access with actingAs($admin). Tests that bypass middleware will happily pass while production 403s.