litefront/default
LiteFront Default is the standard frontend preset for LiteFront, offering clean Blade templates, responsive layouts, and ready-to-use UI components. It provides sensible defaults and a simple structure so Laravel developers can launch and customize polished sites quickly.
Confirm the prerequisite before touching Composer. This package is a theme for the Litefront frontend layer of Lavalite CMS. It has no standalone value: without lavalite/* / litefront/* core packages and Theme, Menu, and Page contracts registered, the Blade files will render but the @yield/$page/menu injections they expect will be empty or throw. If you are on a bespoke Laravel app, stop here — read the views as reference code and copy what you need.
Read these four files first, in this order. Five minutes here saves a day of guessing:
composer.json — PHP and illuminate/* constraints, required Litefront packages, whether any tag exists at all (dev-master only is the likely answer), and the license field.src/*ServiceProvider.php — it is the whole contract: view namespace, loadViewsFrom, publishes() tags and destinations, any Blade::componentNamespace, view composers, and whether it registers anything beyond views/assets.resources/views/layouts/ — the layout file(s) and the @section/@yield/@stack names are the contract your pages must satisfy.resources/views/partials/ — the override seam you will actually use day to day.Install and publish. Pin to a commit SHA from the start; there is no meaningful release history to float against.
composer require litefront/default:dev-master#<sha>
# or, if you have already forked it internally:
composer require internal/litefront-default:^1.0
Then publish without guessing tag names — run it interactively and read the provider list:
php artisan vendor:publish
# select the Litefront default theme provider, then note which tags appear
php artisan vendor:publish --provider="Litefront\Default\DefaultServiceProvider" --tag=views
php artisan vendor:publish --provider="Litefront\Default\DefaultServiceProvider" --tag=assets
Verify the namespace actually registered rather than assuming the folder name:
php artisan tinker
>>> array_keys(app('view')->getFinder()->getHints())
Wire it into the CMS. Point the Lavalite theme setting (admin Settings → Theme, or the corresponding config key) at the published theme directory. The theme resolver, not this package, decides which layout gets rendered — that logic lives in Lavalite core and is the part worth reading once.
First use case — prove both seams in an hour. Get the default homepage rendering end to end, then override exactly one partial from your application to confirm the resolution order works. Create resources/views/vendor/<namespace>/partials/header.blade.php with a visible marker. If the marker shows up, you have a safe customization path (app overrides, vendor untouched) and you know your deploy script must publish views on a cold environment. If it does not, you have a namespace mismatch, and you should fix that before writing a single line of theme code.
Cold-deploy check, before you build anything on top. Clear caches, wipe public/vendor, and run the publish step as your deploy pipeline would. Most "the theme is broken" reports are asset-publish gaps, and it is far cheaper to learn that now.
Choose your ownership model on day one, and write it down. Two viable patterns:
vendor/. All changes go in resources/views/vendor/<namespace>/. Laravel's view finder checks the app's vendor view path before the package's loadViewsFrom hint, so overrides win without any config.composer.json name and the service provider namespace. Now composer update cannot silently change or delete your presentation layer, and you can add tests, a build step, and your own components without fighting the original.The first pattern is right for a spike. The second is right for a product. Decide explicitly; the failure mode is drifting into a fork by accident, with edits in vendor/ that a composer update silently deletes.
Extend layouts, don't copy them. The theme's value is the section contract. A page should look like:
{{-- resources/views/vendor/litefront-default/pages/show.blade.php --}}
@extends('litefront-default::layouts.app')
@section('title', $page->title)
@section('content')
<article class="prose">
{!! $page->rendered_body !!} {{-- see Gotchas: escaping --}}
</article>
@endsection
@push('scripts')
<script src="{{ asset('js/article.js') }}" defer></script>
@endpush
Read the layout once and record the available sections and stacks in your README. If the layout uses @yield('content') but your page uses @section('main'), you get a blank page with no error — the single most common way to lose an afternoon on Blade themes.
Override at the smallest possible granularity. Prefer replacing one partial (header, footer, nav, pagination, a card) over replacing a whole layout. Overridden views are pinned copies: when upstream changes, your copy does not, and you own the divergence. Keep an OVERRIDES.md listing every file under resources/views/vendor/ and why, so a future upgrade is a checklist rather than an archaeology project.
Move site chrome into components early. The default theme is a flat partial structure. As soon as you have more than one layout, promote repeated markup to anonymous Blade components in your own namespace and reference them from the theme views:
// AppServiceProvider::boot()
Blade::componentNamespace('App\\View\\Components', 'app');
<x-app.alert type="warning">{{ $message }}</x-app.alert>
This keeps the theme as thin presentation and puts your opinions in code you actually own and test.
Drive assets through asset() and a manifest, never hardcoded hosts. Verify what the theme ships: a raw CSS file linked with asset(), a CDN <link>, or a Vite/Mix manifest reference. If it hardcodes a CDN, replace it — that is an operational constraint under load and a supply-chain surface you do not control. If it references @vite, you must supply a real build step; the theme alone will not produce a manifest. Keep published assets in version control if there is no build, or add a build and let the publish step write only the entry point.
Roll out behind a theme switch. Wire the active theme through config (config('theme.active')) so a rollback is a config change and a view:clear, not a redeploy. This matters more than usual here because you have no upstream to fall back to.
Write one smoke test per top-level view. render() each layout and page shell in a test that runs in CI. With no upstream tests and no dependents, this is your only regression net against a Laravel upgrade or a bad override:
it('renders the theme layout', function () {
$this->view('litefront-default::layouts.app')->assertSee('html', false);
});
Local loop. Editing app-level overrides needs no publish or compile step — just php artisan view:clear if you change cached views. Editing the package's own views requires republishing or a fork; do not edit vendor/ and expect the change to survive anything.
Zero tags means your Composer constraint is the only guardrail you have. If dev-master is the only installable ref, pin the SHA (dev-master#abc1234) or vendor the code. An unpinned theme can change under you between two builds of the same commit.
vendor:publish is destructive and non-interactive by default. Without --force it skips existing files (safe but confusing when your edit "didn't take"); with --force it silently overwrites your customized views and assets. Never put --force in a deploy script. Treat public/vendor/<theme> as build output, not source.
Published views permanently shadow package views. Once resources/views/vendor/<namespace>/layouts/app.blade.php exists, upstream changes to that file never reach you. That is the point, but it also means a partial publish is a fork of those specific files — the most common cause of "we fixed it upstream but nothing changed."
Namespace mismatch produces a View [x] not found with no hint about the real name. Confirm the registered namespace from view()->getFinder()->getHints() rather than inferring it from the vendor path. php artisan view:clear after any provider or config change; stale compiled views and stale hints are two different caches and both bite.
Review every {!! !!} before rendering user content. Default themes routinely echo CMS content unescaped. That is fine for trusted editor HTML and an XSS vector for anything user-supplied. Grep the view tree, decide per occurrence, and put HTML sanitization at the render boundary rather than trusting the template.
The asset gap is the classic post-deploy bug. The page renders, the HTML is correct, and it is completely unstyled because public/vendor/<theme> was never published or was wiped by a clean build. Add the publish step to the deploy pipeline, make it idempotent, and assert on one known asset URL in your smoke test.
Blade helper and directive drift across Laravel majors is the realistic long-term maintenance cost. Old themes lean on removed string helpers, @php blocks, and legacy conditional directives. Do not chase a Laravel upgrade by patching the package in place — if you forked, the fix is yours and reviewable; if you did not, now is the time.
Hardcoded CDN and asset hosts are an operational constraint, not a style preference. Grep for http://, https://, and cdn. Replace with asset() and your own manifest so caching, CSP, and multi-environment deploys behave predictably.
The knowledge you actually need is in Lavalite core, not this package. How themes are registered, how layouts are resolved, and where menus and content get injected live in the CMS. This theme only consumes those contracts. Assign one named owner for that understanding rather than letting it spread thin across the team — it is the real ramp-up cost and it does not show up in the install instructions.
No tests, no CI, no issue tracker worth watching: build your own safety net. A render smoke test per top-level view plus a pinned SHA plus a fork is roughly a day of work and converts an unmaintained transitive risk into a small, owned, reviewable module. Verify the license permits forking and internal modification before the first internal commit, and record the fork-versus-reference decision in the repo README so the next owner does not rediscover all of this from scratch.
How can I help you explore Laravel packages today?