mariojgt/skeleton-admin
Skeleton Admin is a Laravel package that provides a ready-to-use admin panel skeleton for bootstrapping back-office interfaces. It offers a starting structure for admin screens, navigation, and configuration, helping you focus on application-specific management features instead of repetitive setup.
Skeleton Admin is a scaffolding package, not a runtime dependency — most of its value is delivered once, at install time, by publishing files into your app. Treat the published code as yours and expect to edit it heavily.
Minimum path:
composer.json constraints on the tagged commit before upgrading Laravel — the archive means no new compatibility shims will arrive).composer require mariojgt/skeleton-adminskeleton:install-style artisan command; confirm the exact name in the repo's src/Commands directory since docs are thin. Typical flags select whether to install the admin guard, the user guard, or both.resources/js is the part you will live in day to day.php artisan migrate then seed the default admin user (AdminSeeder or equivalent).npm install && npm run dev (Vite) — DaisyUI, Tailwind, Inertia, and Vue 3 are wired into the stub tailwind.config.js and vite.config.js.First use case: log in at the admin route (usually /admin/login), land on the admin dashboard, and click through the sidebar layout. That single round-trip exercises every layer — the admin guard, the Inertia middleware, the Vue layout, and the DaisyUI theme — so it is the fastest way to confirm the install is healthy.
Where to look first, in order: config/skeleton.php (or whatever the published config is named), the routes/ files the installer drops, and resources/js/Pages/Admin/. Those three tell you how the multi-auth split is actually implemented — a lot of the package's opinions live in route middleware and in the Vue auth store, not in PHP classes.
Two guards, two session cookies. The signature of this package is a second auth guard (admin) alongside web, backed by its own admins table and Admin model. Day-to-day implication: every place you touch Auth::user() must be rewritten as Auth::guard('admin')->user() inside admin controllers, and Inertia's shared props must expose both users separately (e.g. auth.user and auth.admin). The Vue usePage().props.auth tree is the contract — keep it stable across pages or half your components break.
Route group + middleware composition. Admin routes get their own group with auth:admin, a RedirectIfAuthenticated:admin guest middleware, and a dedicated login/logout controller. When you add a feature, add it inside that group — the most common bug is a controller using the web guard by accident, which silently produces a null user and a redirect loop back to /admin/login.
Inertia page flow. Controllers return Inertia::render('Admin/Foo/Index', [...]). Pages live under resources/js/Pages/Admin/... and inherit the layout declared in the page's layout property (or in app.js via a layout resolver). New admin pages should mirror the existing directory structure and reuse the layout component that brings in the DaisyUI sidebar and navbar — do not hand-roll chrome.
DaisyUI as the component vocabulary. Buttons, modals, dropdowns, and form controls use DaisyUI class names (btn btn-primary, modal, form-control). Theming is done with a daisyui: { themes: [...] } block in tailwind.config.js; a per-tenant or per-brand theme is a one-line change to that array plus a data-theme toggle. This is the package's best feature — it lets non-designers ship a coherent admin UI quickly.
Extending auth to a third role. The pattern the package models is generic: copy the admins migration, model, guard entry, middleware alias, and login controller, then wire the sidebar's role switcher. Doing this as a copy-and-rename is far less painful than trying to parameterize the existing code — the stubs are not written to be generic.
CRUD generation workflow. The intended loop is: create migration + model → create a resource controller returning Inertia responses → create Vue page stubs in the same folder as the section's other pages → register the route inside the admin group. There is no code generator beyond the initial scaffolding, so a team usually settles on a hand-written stub pair and reuses it.
Archived status is the dominant risk. Last release mid-2025, 12 stars, no maintainer. Do not plan to receive Laravel 12/13 compatibility fixes, Tailwind v4 migrations, or Inertia 2 upgrades from upstream. Pin the tag, commit the published files into your repo, and treat the package as a one-time template. Never composer require it in CI without a lockfile.
Package classes persist after publishing. Some of the scaffold (Admin model, middleware, login controllers) may still resolve from vendor/ rather than your app. Before editing anything, check composer.json autoload overrides and whether the installer actually republished the class or merely referenced it. If it lives in vendor, copy it into App\ and update the reference, or your edits will vanish on the next composer update.
Inertia + multi-guard shared props. The default HandleInertiaRequests::share() shipped in Laravel only reads Auth::user(). You must edit it to add the admin user, and you must do so guarded — Auth::guard('admin')->user() throws if the guard isn't configured, and returning a lazy closure that throws will blow up every page including public ones. Wrap it defensively and return null when there is no admin session.
Session/cookie collision. Both guards share the same session driver by default. If users log in as both a regular user and an admin in one browser, the login flash and remember-me tokens can cross over. Set a distinct session key or use separate browsers for testing — bugs here look like "random logout" and are miserable to debug.
Ziggy route references. Stubs frequently use route('admin.dashboard') in Vue. Ziggy must be regenerated (php artisan ziggy:generate or the Vite plugin) after adding admin routes, or you get a runtime "route not defined" that only appears in the browser console.
Tailwind content globs. DaisyUI + admin pages often fail to style correctly because tailwind.config.js content was not updated to include ./resources/js/Pages/Admin/**/*.vue. Symptom: unstyled form controls on admin pages while the public site looks fine. Check this first any time an admin screen renders without styling.
Config cache after publish. After editing the published config or the auth config, run php artisan config:clear && php artisan optimize:clear. The package's install command may have cached config mid-flight, leaving stale guard definitions that cause confusing 302s.
Debugging auth redirects. A loop between /admin/login and /admin/dashboard almost always means the guard name on the route middleware (auth:admin) does not match the guard key in config/auth.php, or the Admin model's $guard / getAuthPassword is wrong. php artisan route:list --columns=method,uri,middleware is the fastest way to confirm what's actually applied.
Extension points to favor. The Admin model and the layout Vue component are the two seams worth touching; everything else (controllers, pages) is better overwritten wholesale than extended, because the stubs aren't written with inheritance in mind. Keep your own App\ versions and stop depending on the vendor copies as soon as the scaffold is proven working.
How can I help you explore Laravel packages today?