Lara Pro Cms Laravel Package

Getting Started

Before you install anything, read the docs — not the README. The README is essentially a landing page; the real Developer Guide lives at https://docs.laracms.nl/. Treat that site as the source of truth for install steps, config keys, and extension points. The GitHub repo only tells you it's a Laravel CMS built by Firmaq Media and that it tracks Laravel 13 / Filament 5 / Livewire 4.

Minimum viable install path:

1. Pin your stack first. This package explicitly targets Laravel 13, Filament 5, Livewire 4, Tailwind. If your project is on Laravel 11/12, or you already have a Filament 4 admin panel, you will fight the package before writing a single line of business logic. Decide the stack version before composer require. Note that the current line is now 10.7.x (latest: v10.7.7) — read composer.json at that tag to confirm the framework/Filament/Livewire constraints haven't shifted since 10.6.
2. Install into a fresh app, not your production codebase. With 0 stars and 0 dependents, you are the integration test. Spin up laravel new cms-pilot, then follow the install guide at docs.laracms.nl (typically a Composer require + a publish/config + migrate + admin user seed). Verify the admin panel boots at whatever /admin path Filament serves.
3. Run migrations and seed on a throwaway database. Inspect the migration files that get published before running them against anything real — you want to see table names, prefixes, and whether it touches the users table (see Gotchas).
4. Log into the Filament panel and create one page. That's your smoke test. If the admin UI loads, Livewire reactivity works, and content saves, the core is intact.

Where to look first in the codebase:

• composer.json → exact version constraints on filament/filament, livewire/livewire, laravel/framework. This is the clearest signal of what will break on upgrade. Re-check this file at the 10.7.7 tag — a minor bump is exactly where a constraint like ^5.0 → ^5.1 quietly appears.
• The package's service provider(s) → what it registers (routes, views, config, Filament panels, Livewire components). This is where route prefix conflicts and panel registration live.
• config/ files published by the install → panel path, middleware stack, auth guard, storage disk for media.
• database/migrations → the content data model (pages, blocks, media, taxonomies).
• Any Filament Resource classes → these are your primary extension surface day-to-day.

First real use case: a content-marketing site or client landing-page portal with a handful of page types and a blog. Don't start with a complex multi-role editorial workflow — validate the CRUD + admin UX loop first, then layer on custom fields and permissions once you know the schema.

Implementation Patterns

Content modeling via Filament Resources. The day-to-day work in this CMS is almost certainly extending or creating Filament Resources for your content types (pages, posts, case studies, team members). Pattern:

• Keep the CMS's built-in resources untouched; add your own resources in app/Filament/Resources.
• For reusable content blocks, look for a block/field abstraction in the package before inventing one — if the CMS ships a "blocks" or "flexible content" concept, extend that rather than bolting on a parallel JSON field system.
• Register new resources on the same Filament panel the CMS registers, so admins get one unified UI instead of two logins.

Headless delivery for React/Vue frontends. The package is advertised as API-first/decoupled-capable, so a common pattern is:

// app/Http/Controllers/Api/PageController.php
Route::get('/api/pages/{slug}', fn (string $slug) =>
    PageResource::make(Page::where('slug', $slug)->published()->firstOrFail())
);

Keep API resources thin, version your routes (/api/v1/...), and cache aggressively — Livewire/Filament admin traffic and public API traffic should not share cache tags carelessly. If the package already registers public content routes, namespace your API routes under an explicit prefix to avoid collisions.

Blade + Livewire for hybrid rendering. For marketing pages that need SEO plus a bit of interactivity, use standard Blade views fed by the CMS's content models, and drop in Livewire components only for the interactive islands (contact form, filters, search). Avoid making whole page templates Livewire components — it hurts TTFB and complicates caching.

Per-client / per-tenant isolation (manual). There is no documented multi-tenancy. The pragmatic pattern is a site_id (or tenant_id) column added to your own content tables, a global Eloquent scope driven by the request's resolved site, and a Filament panel ->tenant() configuration if you go the Filament multi-tenancy route. Treat this as custom work on top of the CMS, not a supported feature — budget it explicitly.

Role/permission layering. Filament's authorization integrates with Laravel policies and spatie/laravel-permission style setups. Pattern: define roles at the panel level (editor, author, admin), gate resource actions with policies, and keep editorial workflow states (draft → review → published) as an enum column on the content model with Filament form actions driving transitions.

Integration tips:

• Register the CMS service provider conditionally in AppServiceProvider or a dedicated guard so it doesn't pollute API-only contexts.
• If the CMS ships its own middleware (locale, redirects, maintenance), explicitly order it in the panel middleware stack rather than relying on defaults — ordering issues with auth/session middleware are a common source of "logged out after saving" bugs.
• Keep CMS updates on a pinned minor version (10.7.*) and upgrade deliberately; the release notes won't help you diff behavior.
• If you must take the 10.6 → 10.7 jump, do it as a dedicated PR against a staging branch with your custom Filament resources listed as the regression surface — don't bundle it with feature work.

Gotchas and Tips

Release notes are non-informative. "Several improvements" is the entire content of v10.7.7 — and of v10.6.2, v10.6.1, v10.5.9, etc. You cannot read a changelog to know if a release breaks your custom Filament resources. Mitigation: lock to an exact version in composer.json, run the full upgrade test suite (or manual smoke test) before bumping, and use composer diff / the GitHub compare view between tags (v10.6.x...v10.7.7) rather than the release body. With ~7+ patch releases and an unannounced minor bump in that range, the compare view is the only way to see what actually moved.

A minor bump with no changelog is the riskiest kind of release. 10.6 → 10.7 could be pure fixes or could carry new migrations, renamed config keys, or a Filament constraint bump. Treat v10.7.7 as an unknown until you've diffed it. Concretely, before upgrading check: composer.json constraints, new/edited database/migrations, published config keys, and any changed Filament panel provider. If the diff touches the users table, the media disk, or the panel middleware stack, plan a migration path rather than a composer update.

Filament 5 + Livewire 4 is a hard coupling. The package moved to Filament 5 and Livewire 4 in v10.5.0 and to Laravel 13 in v10.6.0. If you already have a Filament admin app on an earlier major, you either upgrade the whole app or don't use this package. Similarly, a future Filament 6 will likely force a refactor — factor that into your maintenance estimate.

Zero community = you are the maintainer of last resort. No stars, no dependents, no Stack Overflow trail. When something breaks, your debugging path is: read the package source → read the docs site → open an issue and wait. Budget for this. For production, consider forking and maintaining your own patch branch — pinning to a known-good tag like v10.6.x until you've validated 10.7.7 is a legitimate strategy, not a cop-out.

Undocumented data model. The README gives you nothing about the schema. Before you write queries, inspect the published migrations. Pay particular attention to whether the package:

• touches the users table or its own auth admin table (affects your existing auth),
• hardcodes a table prefix (affects multiple installs in one DB),
• assumes a specific storage disk for media (S3 vs local misconfigs cause silent upload failures),
• stores rich content as HTML, JSON blocks, or Markdown (determines whether you need a sanitizer on output).

Route and service-provider collisions. A CMS of this type typically registers its own front-end routes and a Filament panel. If your app already defines /{slug} catch-alls or a panel at the same path, you'll get silent 404s or the CMS swallowing your routes. Tip: put your app-specific routes above the CMS's catch-all route, or configure the CMS's route prefix in its published config. Similarly, audit providers in composer.json for anything that bootstraps globals (view composers, Blade directives, Livewire component registration).

Tailwind/Bootstrap history suggests styling churn. v10.3.0 switched from Bootstrap to Tailwind; v10.1.5 switched icon sets (Heroicons → Bootstrap Icons). If you're extending the admin UI, prefer the package's own Blade/Vue components and Tailwind classes over custom CSS, and pin the version — a minor bump can shift class names.

Sanitize rendered content. Any CMS field that outputs raw HTML (rich text, custom blocks) must be sanitized on render — {!! !!} without mews/purifier or an equivalent is an XSS hole waiting for an editor role. Assume the package does not sanitize for you unless the docs say so.

Extension points to look for (and document for your team):

• Filament panel provider — add resources, widgets, navigation groups here.
• Published config — panel path, auth guard, middleware, media disk.
• Blade view publishing (vendor:publish --tag=...) — only if you need to restyle built-in pages; otherwise leave them alone to keep upgrades cheap.
• Events / model observers on content models — the safest place to hook in cache invalidation, search indexing (Scout), or webhook dispatch on publish.

Debugging checklist when something breaks:

1. php artisan about to confirm Laravel/Filament/Livewire versions match what the package expects — especially after a 10.6 → 10.7 bump.
2. php artisan route:list | grep <cms-prefix> to verify routes actually registered (a minor bump can add or move them).
3. php artisan filament:cache-components --clear (or the Filament 5 equivalent) after adding/moving resources — stale component caches are a classic "my resource doesn't appear" cause, and are the first thing to clear after any upgrade.
4. Check storage/logs/laravel.log for Livewire payload errors on save; they rarely surface in the UI.
5. If admin styles break, verify Tailwind is compiled including the Filament preset and that vite is building the panel's CSS entry.

When to walk away: if you need true multi-tenancy, out-of-the-box i18n for content, or enterprise-grade media/DAM, this package won't give it to you. Use it for Laravel-native, single-tenant, content-heavy sites where Filament's admin UX is a good fit — and keep a fallback plan, because at 0 dependents you're betting on a small agency's release cadence.