Adminlte Theme Laravel Package

Getting Started

Before you write a single line, verify the package is even installable in your app. This is an AsgardCMS backend theme, not a standalone AdminLTE wrapper — it assumes asgardcms/platform (the modular CMS core), the Menu, Setting, and User modules, and a Laravel version consistent with the era the repo was published (almost certainly Laravel 5.4–5.7 / PHP 7.0–7.2). Read composer.json first; the require block is the real compatibility contract. If your project is Laravel 8+, expect a dependency wall and plan to fork rather than composer require.

Minimal path once compatible:

1. composer require idavoll/adminlte-theme (or add a path/vcs repository pointing at a fork, which is what you'll almost certainly end up doing).
2. Confirm the theme is discovered: php artisan theme:list (AsgardCMS registers themes via the Themes/ directory or a package service provider — check src/ for the provider and any theme.json/config/theme.php).
3. Activate it as the backend theme. In AsgardCMS this is a setting/config value (typically config/core.php → themes.backend, or via the Settings module in the admin UI), not the frontend theme. Setting the wrong one is the most common first-run mistake.
4. Publish assets: php artisan vendor:publish or php artisan theme:publish, then verify files landed in public/themes/<name>/. Hard-refresh the admin — a white/unstyled dashboard means assets 404'd, not that the theme failed.
5. php artisan view:clear && php artisan cache:clear.

Where to look first, in order of payoff:

• resources/views/layouts/ — the master layout and the sidebar/navbar partials. This is where 90% of your day-to-day edits will land.
• The service provider in src/ — it tells you the view namespace, asset namespace, and any Blade directives or view composers the theme registers.
• resources/assets/ (plus gulpfile.js/elixir/bower.json if present) — the build pipeline, if any. Many themes of this vintage ship pre-built CSS and a build chain that no longer runs on a modern Node.
• The theme's composer.json autoload/extra blocks — theme metadata (name, author, version) is sometimes duplicated there and in a config file; keep them in sync if you fork.

First use case to validate end-to-end: log into /admin, load the dashboard, then visit the index page of two or three modules (Pages, Media, Users). If the theme's layout wraps module views correctly and the sidebar renders with active states, the integration is sound. Everything past that is styling.

Implementation Patterns

Don't edit the vendor package. The dominant pattern for a theme this thin and this unmaintained is a child theme: create Themes/YourAdmin (or a local package), declare this one as its parent/base, and put only your overrides in it. AsgardCMS's theme view resolution lets you override specific Blade files while inheriting the rest. This keeps composer update survivable and makes your diff reviewable.

View overriding by namespace. Extend the theme's layout rather than copying it:

{{-- resources/views/vendor/<module>/... or your child theme --}}
@extends('adminlte::layouts.master')   {{-- confirm the real namespace via the provider --}}

Check the provider for loadViewsFrom(..., 'somenamespace') — the namespace string is what you must use, and it frequently does not match the package name. A "View [adminlte::layouts.master] not found" error is a namespace mismatch or a stale view cache, in that order.

Dashboard widgets as partials. AdminLTE's value is its box/infobox/small-box vocabulary. Establish a convention early: one partial per widget under resources/views/partials/widgets/, each self-contained (its own markup + any data passed in), included from the dashboard view. This keeps the dashboard editable by non-Laravel people and avoids a 600-line dashboard.blade.php.

Wire the sidebar through the Menu module, not hardcoded HTML. AsgardCMS exposes a Menu facade/service. Fetch the admin menu and iterate it in the sidebar partial, applying active classes based on the current route. Hardcoding <li> entries works for a demo and becomes unmaintainable the moment a module is added or a permission changes. If the theme ships a hardcoded sidebar, replacing it with a menu-driven loop is the single highest-value refactor you can do.

Asset handling. Use the theme's asset helper (usually Theme::asset('...') or a theme_asset()-style function) rather than asset() with a hand-written path — it resolves the active theme's public directory and survives a theme rename. If you're adding CSS/JS, add it to the theme's asset manifest and rebuild; don't drop loose files into public/, they're invisible to the publishing step and vanish on redeploy.

Local development loop. Add the fork as a Composer path repository with a symlink so edits to the theme are live without composer update on every change. Pair with view:clear on file save (a watcher or a php artisan view:clear in your dev script) — Blade's compiled-view cache will otherwise serve you stale markup and cost you an hour.

Integration with module views. When a core module's page looks broken inside the new theme, don't patch the module. Compare the module's view against what the theme's layout expects (content section name, breadcrumb variable, flash-message partial). The mismatch is almost always a @section name or a missing variable the module assumed the default theme provided. Bridge it with a view composer in your child theme's provider rather than editing vendor module code.

Auth and error pages. Login, password reset, 403/404/500 are all theme-rendered in AsgardCMS. Override them deliberately — an unstyled exception page in production is a bad look — but keep the error views logic-free.

Gotchas and Tips

• Treat this as unmaintained. Zero stars, zero dependents, no visible activity. Assume no security patches, no Laravel-version bumps, and no answers to issues. Pin the exact commit in composer.json (a dev-master#<sha> constraint or a VCS fork) so a force-push upstream can't silently change your admin UI. Fork it into your own org on day one.
• The AsgardCMS ecosystem is the real risk, not this theme. If the core platform is dormant, the theme's staleness is a symptom. Before investing, confirm which Laravel/PHP your app runs and whether the core itself is still receiving updates. If not, budget for the theme being a one-way migration, not a maintained dependency.
• Two caches will lie to you. view:clear for Blade overrides and cache:clear for theme discovery/config. When "my change did nothing," clear both before debugging anything else.
• Asset 404s are a publish problem, not a CSS problem. Check public/themes/<name>/ exists and is populated. Re-run the publish command; if it's still empty, the provider's publishes() tag is probably wrong or the service provider isn't auto-discovered (composer dump-autoload after adding it manually).
• jQuery plugin load order. AdminLTE's JS (datatables, datepicker, slimscroll, etc.) is jQuery-dependent and order-sensitive. If you see $.fn.<plugin> is undefined, a plugin script is loading before jQuery or before the plugin's own dependency. Fix the layout's script stack; don't patch individual pages.
• Sidebar active states are route-driven. Custom routes, routes with parameters, and routes outside the admin prefix won't highlight correctly out of the box. Centralize the active-class logic in one helper/partial so you fix it once.
• Permission-blind menu items. A menu-driven sidebar will happily render links the current admin can't access. Filter by the User/Permissions module's checks or you'll ship 403s in the UI.
• Check the LICENSE. AdminLTE itself is MIT, but the glue repo may have no license at all — which technically means no grant to redistribute. If this ships inside a product, get that clarified or vendor AdminLTE directly and write your own thin AsgardCMS theme.
• Smoke-test checklist after any theme change: login → dashboard → one index page per installed module → a create form → a validation-error round trip → a 404 page. Themes break on flash messages and validation error bags far more often than on the happy path.
• Extension point worth knowing: if the theme registers view composers or Blade directives, you can hook additional data into every admin view from your own service provider without touching theme files. That's the cleanest seam for injecting environment banners, build version, or support links.
• Have an exit plan. Because the surface area is small (layouts, sidebar, assets, a handful of overrides), the realistic long-term move is to extract your customizations into your own theme package and drop this dependency entirely. Design your overrides as if that migration is already scheduled.