Admin Laravel Package

Getting Started

Install the package and run the admin installer — the setup path hasn't changed:

composer require divotek/tbtop
php artisan admin:install

For an app that needs authenticated admin access, v0.7.0 adds a first-class flag:

php artisan admin:install --auth

This publishes the sign-in page and the password-reset flow out of the package's base pages into your app, so you can edit them like normal Laravel views. That's the first thing to check after installing — if you need login, run the flag up front rather than bolting auth on later.

Where to look first:

1. The published auth views (after --auth) — these are the files you'll actually customize.
2. The AuthPage class — it now exposes currentUrl() and (new in 0.7.0) the signed-in user and a panel logout action from the package itself, so you no longer hand-roll a logout route or user accessor.

The minimal first use case: install → run admin:install --auth → hit /admin → you're redirected to the published sign-in page, log in, see the panel with a working logout action and the current user available to your views.

Implementation Patterns

Auth scaffold on a fresh app. Run admin:install once. If you skipped --auth and now need it, re-running the installer with --auth publishes the base sign-in / password-reset pages; treat any prior hand-written auth views as superseded and diff before overwriting.

Logout and current-user in your layout. v0.7.0 ships these from the package. The typical flow is to surface the signed-in user in your panel header and point the logout form/button at the package-provided action rather than a custom route. This keeps session invalidation consistent with the rest of the package's auth handling.

Building links with currentUrl(). Anywhere you previously reached for AuthPage::url(), use AuthPage::currentUrl() now. This is the pattern you'll want in redirects after login, in nav guards, and in tests asserting the post-auth destination.

Customizing published auth pages. Because the views are published into your app, the workflow is: publish → edit the Blade → keep the underlying form components/routes intact. Favor overriding presentation (copy, branding, layout) over form action/route structure, since the package owns the submit endpoints.

Integration with existing middleware. Wrap the panel routes with your own auth middleware only if you've disabled the package auth; with --auth the package handles the guard. Mixing both tends to produce double-redirects (see Gotchas).

Gotchas and Tips

Breaking change: AuthPage::url() → currentUrl(). This is the one thing to grep for before upgrading from 0.6.x. Any custom code, Blade, or tests referencing AuthPage::url() will break. Rename in one pass:

grep -rn "AuthPage::url(" app resources tests

Re-publishing overwrites. admin:install --auth publishes base pages. If you've already customized sign-in/reset views, running it again on an existing install can clobber your edits. Review the diff (git diff) after installing, and commit your customizations before running the installer on an established app.

Logout route expectations. Since the package now ships the logout action, verify your existing custom logout route still exists if you had one — you may end up with two logout paths competing. Pick the package action and remove the hand-rolled one to avoid stale-session surprises.

Auth flag is part of the installer, not a stand-alone command. The --auth behavior is bundled with admin:install. Don't reach for a separate admin:install:auth or similar — it's the flag on the base command.

Debugging the auth flow. If login redirects misbehave, inspect what currentUrl() returns at the point of redirect — it reflects the resolved current auth page URL, which is useful when you have multiple auth entry points. Log it early rather than guessing at the redirect target.

Extension points. Published views are your primary customization surface; the AuthPage class (currentUrl(), current-user accessor) is the programmatic one. Prefer these over patching package internals so future releases — this one already renamed one public method — stay upgradeable.