Public Laravel Package

Getting Started

litefront/public is a frontend theme for Lavalite CMS, not a general Laravel package. The only day-to-day usage that makes sense is inside an existing Lavalite install. There is no reusable logic, no API surface, and no framework-agnostic component to extract — the value is the Blade markup and assets.

Minimal steps to get it running:

1. Confirm Lavalite is the host. The theme assumes Lavalite's theme resolution, menu/widget registries, view namespaces, and admin theme manager. It will not boot usefully on a vanilla Laravel app.
2. Require and pin it. With zero stars and zero dependents, treat it as an unmaintained starter. Pin an exact version rather than relying on ^ resolution:

   composer require litefront/public:1.0.0
   

3. Register the provider. Check composer.json under extra.laravel.providers for auto-discovery first. If absent, add the theme service provider manually to config/app.php.
4. Publish views and assets. This is the step people miss — the theme is inert until published into Lavalite's theme directory:

   php artisan vendor:publish --provider="Litefront\Public\Providers\...ServiceProvider"
   

   Run php artisan vendor:publish with no provider first to list the available tags (public, theme, litefront, etc.) and confirm the exact names.
5. Activate the theme through the admin panel (Appearance/Theme) or the theme config key. The registered slug lives in the service provider's register()/boot() or in a theme.json/config file — read it, don't guess.
6. Clear caches and load the homepage:

   php artisan view:clear && php artisan config:clear && php artisan cache:clear
   

Where to look first, in order: the service provider (what views/assets/config it registers), resources/views layouts (what Blade sections and variables it expects), and config/ or theme.json (what is configurable). A mid-level Laravel developer can read the whole theme end-to-end in a day; the real ramp is understanding Lavalite's theme contract, menus, and widgets.

The first use case is proving the theme renders against your content types and menus rather than the author's demo data — home, listing, single page, search, 404, contact form, menu rendering.

Implementation Patterns

Fork-and-own, don't depend. The correct day-to-day posture is to vendor the published views into your own theme namespace (e.g. resources/views/themes/yourname/) and own the upgrade cadence. You keep composer only for the initial scaffold. Given two-layer abandonment risk (theme and Lavalite core), consuming it as a live dependency is the wrong trade for a package this small.

Keep the registration contract intact. Even after forking, preserve Lavalite's theme registration so the admin experience (theme selection, menus, widgets) keeps working. Break the contract and the theme stops showing up in the admin manager.

Replace the asset pipeline as you fork. If assets ship pre-built and committed, that blocks CSP, cache-busting, and design-system work — migrate to Vite and re-point the theme's asset calls. If they require npm/Mix, assume the toolchain is stale and budget a rebuild, not a tweak.

Rebuild the layout against your design tokens. Adopt the structure and Blade scaffolding, not the shipped CSS wholesale. This is where the theme earns its keep — the markup reference saves days of layout/navigation work; the styling is disposable.

Work through the content path methodically. After activation, exercise each surface against real content: home, archive/listing, single page, search results, 404, contact form, and menu rendering. View composers and menu/widget queries are where theme assumptions surface — unbounded queries there are the scaling risk, not the blade themselves.

Treat it as disposable during validation. Get an MVP live fast, then budget a designer-led rebuild once the product earns it. Don't over-invest in a generic theme pre-product-market-fit.

Do not let this package make decisions it shouldn't. It must not influence CMS selection, and it does not support brand-critical work, compliance-sensitive surfaces, or teams standardizing on Vue/React/Inertia/component libraries over server-rendered Blade.

Gotchas and Tips

• The description oversells it. Marketing copy calls it "a lightweight Laravel package" with "sitemap helpers" and "cache-friendly rendering." In practice it is a Blade/asset theme for Lavalite. Don't expect framework-agnostic routing or SEO abstractions you can lift into another app.

• XSS via unescaped CMS fields is the highest-severity risk. Themes render editor-controlled content. Audit every Blade template for raw {!! !!} on fields non-admin editors can control — titles, excerpts, and rich-text bodies especially. Do this before first deploy, not after.

• Silent visual regression after upgrades is the most likely failure. Blade compiles fine but markup degrades, and there are no tests to catch it. Pin the theme version, record the Lavalite/Laravel versions it targets (infer from composer.json), and diff against CMS upgrades so view overrides don't break silently.

• Laravel version ceiling. Themes pin Blade syntax and helpers to a Laravel generation. A theme that never tracked Laravel 10/11 (removed helpers, Mix → Vite) will not boot cleanly on a modern host. Boot a current Laravel + Lavalite install and exercise the full path before committing.

• Two-layer abandonment. Lavalite itself has low activity; the theme has zero adoption signal. Assume you maintain it. Budget a recurring owner, document the fork, divergences from upstream, and the upgrade procedure — or the next team re-litigates the decision.

• No vendor support. No SLA, no issue triage, no release cadence. Internal support only. Confirm the license permits modification and redistribution in a commercial product before you fork into a private repo.

• Debugging theme-not-loading: verify provider registration, confirm the published views landed in Lavalite's expected theme directory, check the active theme slug matches the one the provider registers, then clear view/config/cache. Most "theme doesn't appear" issues are a publish or slug mismatch.

• Extension points worth knowing: the service provider (view/asset/config registration), theme.json/config (theme metadata and options), and Lavalite's menu/widget registries — that's where customization cleanly lives. Anything outside those means editing vendored views, which you already own post-fork.

• Scaling lives in Lavalite core, not here. Themes serve statically and scale at the web tier. Watch image handling and unbounded menu/widget queries in view composers — that's the only place this package touches performance.