Ladmin Laravel Package

Getting Started

Install the package via Composer and run the Ladmin installer. For a dedicated admin login, run the installer with the new admin-table flag:

php artisan ladmin:install --with-admin-table

Start by reviewing these files after installation:

• config/auth.php — the installer adds an admin guard and provider.
• Modules/Ladmin/Models/Admin.php — the new default admin user model for Ladmin.
• Modules/Ladmin/Database/Migrations/*_create_ladmin_accounts_table.php — the admin accounts table.
• Modules/Ladmin/Database/Seeders/DatabaseSeeder.php — overwritten to seed Ladmin data.
• Modules/Ladmin/Database/Factories/AdminFactory.php — factory for tests and local seeding.

First use case: create an admin account, log in through the admin guard, and start generating CRUD modules. If you already have an application users table and want admins to share it, omit --with-admin-table and confirm which model the admin guard uses.

Implementation Patterns

Dedicated admin authentication

Use the admin guard explicitly rather than relying on the default guard:

Auth::guard('admin')->attempt($credentials);
auth('admin')->user();

Protect admin routes with the matching guard middleware and configure password resets/notifications against the admin broker if needed.

Admin model and relationships

Reference Modules\Ladmin\Models\Admin where Ladmin expects an admin user. If your domain models need an admin author/owner relation, point them at this class or configure the guard provider to your own model. Keep the Admin model in the module namespace so package updates remain predictable.

Seeding and factories

Use AdminFactory in tests and local seeders:

$admin = \Modules\Ladmin\Models\Admin::factory()->create();
$this->actingAs($admin, 'admin');

If you customise Modules\Ladmin\Database\Seeders\DatabaseSeeder, keep your changes in a separate seeder where possible. The installer overwrites the module seeder, so local edits inside that file can be lost on reinstall.

Migration and deployment workflow

Run the new ladmin_accounts migration in fresh environments. For existing environments, review the generated migration before running it and confirm it does not clash with an existing admin/users table. In CI, run migrations and use AdminFactory to create test admins rather than relying on production seed data.

Guard-based authorization

Apply role/permission logic to the admin guard. Policies and gates should resolve the admin user from auth('admin')->user() rather than auth()->user(). If both public users and admins exist, keep route groups and middleware separated by guard.

Gotchas and Tips

• Installer overwrites config/auth.php. Back up or diff this file before installing, especially if you already have custom guards/providers. Merge the generated admin guard manually if needed.
• --with-admin-table is opt-in. Without it, Ladmin may continue using your default user model. Confirm the guard provider in config/auth.php after installation.
• Seeder overwrite risk. The installer replaces the Ladmin module DatabaseSeeder. Move custom seeding logic into separate seeders/classes to survive reinstallation.
• Migration collisions. If ladmin_accounts already exists, or you previously used a shared users table for admins, do not blindly run the new migration. Inspect it and adapt your data migration strategy.
• Clear config cache after auth changes. Run php artisan config:clear (and cache rebuild in deployment) after the installer edits config/auth.php.
• Factory namespace/autoload. Ensure the Ladmin module is autoloaded so Modules\Ladmin\Databases\Factories\AdminFactory resolves in tests. If using PHPUnit with a non-standard module path, regenerate Composer autoload.
• Guard leakage. Code using auth()->user() or default auth middleware will not see admins logged in through the admin guard. Audit middleware, policies, notifications, and password reset flows for guard awareness.
• Upgrade path. Treat 2.1.0 as a feature release but review the auth/config and seeder overwrites as potentially disruptive in existing projects. Test installation in a branch and compare generated files before applying to production.