- How do I install Ladmin in a Laravel application?
- Install the package with Composer using hexters/ladmin, then run the package's install command to scaffold the admin module, routes, and Blade UI. The 2.1.0 installer includes an optional --with-admin-table flag that creates the ladmin_accounts table and related admin model and factory. Treat installation as a configuration change: review what the installer writes before running it in any shared environment.
- Which Laravel and PHP versions does Ladmin support?
- The provided overview does not state exact Laravel or PHP version constraints, so check the package's composer.json on Packagist or GitHub before committing. Validate the 2.1.0 requirements against your application's framework and PHP versions in a disposable environment. Do not assume compatibility with older Laravel releases or with applications pinned to legacy PHP versions.
- What does the --with-admin-table option actually create?
- The option creates the ladmin_accounts table, a default Modules\Ladmin\Models\Admin model, an AdminFactory, and an admin authentication guard written into config/auth.php. It separates Ladmin administrators from your main application user model, but only if your existing authorization assumptions are audited. Run it only in non-production environments first and verify the generated migration, model, guard, and factory.
- Does Ladmin overwrite my config/auth.php file?
- Yes, the 2.1.0 installer writes an admin guard into config/auth.php, which raises upgrade and coexistence concerns for applications with customized authentication. Back up the file and diff it against the package's version before deploying. Where possible, determine whether the guard can be published or merged manually instead of being overwritten.
- Will Ladmin's admin guard conflict with my existing guards?
- There is a real risk of guard name collisions, provider conflicts, or interference with password reset and session handling. Confirm that the Ladmin guard name is unique and that existing providers, policies, gates, and middleware still behave correctly. Auth regression tests covering login, logout, authorization, and any password reset flows are essential before rollout.
- How should I upgrade an existing Ladmin installation to 2.1.0?
- Treat 2.1.0 as an auth-affecting upgrade rather than a routine dependency bump. Back up the database and configuration, diff config/auth.php and the seeder against your app, review migrations for existing-data safety, and test in a non-production copy. Then run auth regression tests in staging before production rollout with a documented rollback plan.
- Does Ladmin overwrite the module seeder or existing Ladmin seed data?
- The 2.1.0 release overwrites the module seeder and the Ladmin DatabaseSeed, which can replace or alter existing seed data. Review the seeder diff before running it against any database that already contains administrator accounts. Never run the installer or seeder in production without confirming what data it preserves versus replaces.
- How are Ladmin administrator passwords, password resets, and authorization handled?
- Ladmin provides a separate Admin model and auth guard, but the provided materials do not detail password reset flows, remember tokens, or policy integration. You must validate these behaviors against your application's existing auth and authorization design. Audit policies, gates, middleware, and session handling to ensure administrators cannot bypass intended access controls.
- Is Ladmin suitable for production or enterprise SSO applications?
- Ladmin fits greenfield or controlled modular Laravel monoliths that want a packaged admin identity separate from the main user model. It is a weaker fit for API-only services, enterprise SSO environments, or organizations with strict change control over config/auth.php. Prove it in a representative application before adopting it for production.
- Are there tests covering upgrades from previous Ladmin versions?
- The assessment explicitly flags upgrade testing as an open question, so do not assume coverage exists. Require proof in a representative app, including migration ordering, seeder side effects, and auth behavior after upgrading. If coverage is missing, add your own regression tests before allowing the package into production.