Lara Pro Demo Theme Laravel Package

Getting Started

Recognize what you're installing. This is not a standalone package and not a UI kit. It's a child theme for Lara CMS, which itself is a commercial Laravel CMS from Firmaq Media. Installing it into a bare Laravel app will get you a composer dependency and nothing renderable. The real prerequisite chain is: Laravel app → Lara CMS core → Base Theme → this demo theme.

Minimal steps

1. Stand up a throwaway Lara CMS 10.x install (do not start from your production app — see Gotchas).
2. composer require appdezign/lara-pro-demo-theme and pin the exact tag (10.7.7 or whatever your spike validates), then commit the lockfile.
3. Activate the theme through the Lara CMS admin panel theme switcher, not by editing config by hand — theme activation typically writes the active theme handle somewhere the CMS reads at boot.
4. Seed/import the demo content set so pages render with something other than empty blocks.
5. php artisan serve and open the homepage.

Where to look first, in this order

• composer.json — this is the single most informative file. It tells you the exact Lara CMS / Base Theme package names, the Laravel constraint, and whether Filament 5 / Livewire 4 (introduced in 10.5.0) and Tailwind (10.1.x → 10.3.0) are hard transitive requirements. Resolve these before writing any Blade.
• The theme's service provider — for view namespace registration, view paths, and any asset/component registration.
• resources/views/ — the actual theme surface. Directory layout mirrors the Base Theme's structure; that mirroring is the override mechanism.
• tailwind.config.js / vite.config.js / package.json — confirm whether assets ship precompiled or you must run npm install && npm run build. In a Tailwind-era theme this matters constantly.
• The official developer guide at docs.laracms.nl. It's external to the repo, and it is the only real documentation. The README in this package is three paragraphs.

First use case to attempt. Not "build a feature" — prove the override loop works. Open the Blade view rendering the homepage in the Base Theme, copy it into this child theme at the identical relative path, change a heading, clear the view cache, reload, and confirm your version wins. That single exercise validates the entire mental model: child theme overrides base theme, nothing else. If that round-trip is slow or fails, stop and fix it before going further — every day-to-day task depends on it.

Implementation Patterns

The override-and-extend loop. The child theme's core contract is path-mirroring: a view at resources/views/pages/show.blade.php in this theme shadows the same path in the Base Theme. Day-to-day work is almost entirely "copy from base, edit in child." Extend rather than rewrite — @extends the base layout, @section into its slots, @push into its asset stacks — so base-theme updates remain pullable. The moment you fork a base layout file wholesale, you've taken on its maintenance permanently.

Asset workflow. Since 10.3.0 the frontend is Tailwind, not Bootstrap. Practical consequences:

• Customize via tailwind.config.js theme.extend and a small theme CSS entrypoint rather than editing compiled output.
• Classes must appear in Tailwind's content globs. If your theme's content array only covers the theme's own views and you start emitting classes from a package view or a database-stored content block, those classes get purged from the production build and only work in dev. This is the classic "works locally, unstyled in prod" bug in this style of theme.
• Keep a npm run build step in your demo deploy script; don't rely on a dev server in staging.

Content comes from the CMS, not from Blade. Lara CMS is admin-driven — pages, blocks, and menu structure live in Eloquent models and are edited by non-engineers. The pattern that pays off is: Blade handles presentation and layout, the admin handles copy and structure. Hardcoding marketing copy into Blade defeats the entire value proposition and puts demo-content edits back on the sprint board. Where you do need to touch data, query through the CMS's models/repositories rather than raw DB::table() calls, so schema changes on upgrade surface as errors in one place.

Templatize the demo, not just the page. Once one demo renders end-to-end, codify the repeatable parts: a branding layer (logo, palette, typography in Tailwind config), a seed/demo-content fixture, and a deploy script. The target metric is "new branded demo in under a day." That's where the leverage is — the theme itself is small; the pipeline around it is the deliverable.

Isolation pattern. Run demos as separate installs with separate databases, ideally on their own composer context and subdomain, with teardown scripts. Never co-install this into the production app: its Filament 5 / Livewire 4 constraint becomes a constraint on your host application's admin panel, and you can end up forced into an unplanned admin upgrade.

Track divergence deliberately. Keep a short internal changelog of every view you override and why. When you upgrade, that list is your smoke-test plan — because the release notes won't give you one.

Gotchas and Tips

"Several improvements" is not a changelog. Roughly thirty releases in the 10.x line, most with that exact note. Four of them are stack pivots: Bootstrap → Tailwind (10.3.0), Filament 5 + Livewire 4 (10.5.0), Laravel 13 (10.6.0). You cannot plan from these notes. Practical countermeasure: when upgrading, download both tags and diff the trees, or diff your rendered demo before and after. Assume every minor is potentially breaking and treat patch-level stability as unproven.

Never edit vendor/. Composer will overwrite it on the next composer update and you'll silently lose work. All customization belongs in the child theme's own resources/, tailwind.config.js, and provider. If you find yourself needing to change something inside the Base Theme package, that's a signal to publish it or override at the child layer — or to file it as an upstream need.

Cache clears are not optional. After adding or moving an override, run php artisan view:clear (and config:clear if you touched config). Blade's compiled-view cache will happily serve the base theme's version after you've added a child override, and the failure looks like "the child theme isn't working" rather than "the cache is stale." Make view clearing part of your edit loop, not an afterthought.

Verify which view actually rendered. When an override appears not to apply, resolve the concrete path — View::getFinder()->find('pages.show') in tinker, or an artisan command that reports the resolved view — rather than guessing between Base Theme, child theme, and published-override locations. There are three plausible sources and only one wins.

Is the theme even active? A surprising share of "nothing changed" bugs are the CMS still pointing at the Base Theme, or a cached theme handle in config. Check the active theme setting in the admin before debugging Blade.

Assets may be precompiled. Some themes ship a built CSS/JS bundle and don't expect you to run the frontend toolchain. If package.json exists but npm run build produces nothing useful, check whether the theme loads a compiled asset from public/ — in which case your Tailwind changes require either the build pipeline or a rebuild of the shipped bundle. Confirm this in the first hour; it changes your whole iteration speed.

Upgrade runbook (write this on day one).

1. Branch, pin the new tag, composer update in isolation.
2. composer audit and capture the transitive set (Laravel, Filament, Livewire, Tailwind).
3. Diff the vendor tree between old and new tag to see what actually moved.
4. Re-run the demo seed, walk every page you've overridden from your divergence list.
5. Only then merge to the demo lane.

Extension points worth knowing. Child-theme view overrides, Blade components and layout slots, view composers for injecting data into CMS-driven views, and the CMS's own content models. These cover nearly all day-to-day needs; anything requiring core changes is an upstream conversation, not a local hack.

Keep demos disposable. No live customer data, no production credentials, admin routes behind network restriction or SSO, and a documented fallback: if the CMS goes stale or a demo is promoted to customer-facing, rebuild it on first-party Blade/Tailwind. Write that exit before you write the first template — it's the thing that keeps an opaque, single-vendor, zero-community dependency off your critical path.

Debugging posture. Zero stars means zero Stack Overflow answers and no third party has hit your bug. docs.laracms.nl plus tree diffs plus Laravel's standard toolkit (log tailing, dd() in Blade, tinker against the CMS models) is your entire support surface. Budget for reading source, not for searching for solutions.