Trovcms Laravel Package

Getting Started

TrovCMS is a starter kit, not a library — you don't composer require it into an existing app and call its APIs. You scaffold a new project from it and then own the code:

composer create-project trovcms/trovcms my-site
# or: git clone https://github.com/trovcms/trovcms my-site && composer install
cd my-site
cp .env.example .env
php artisan key:generate
# configure DB in .env, then:
php artisan migrate --seed
php artisan storage:link
php artisan serve

The admin panel is Filament-based and is almost always mounted at /admin. The seeder typically creates an initial admin user — check database/seeders/ for the credentials or the user-creation command before logging in.

Where to look first, in this order:

1. config/ — any trovcms.php/filament.php config defines panel paths, disk names, and feature toggles.
2. app/Filament/Resources/ — every content type (pages, posts, etc.) is a Filament resource here; this is your map of the data model.
3. app/Models/ — especially Page/Post and any block/field models.
4. routes/web.php — the frontend catch-all route that resolves a URL slug to a rendered page.
5. resources/views/ — the Blade layout and block partials that constitute the actual website.

First use case: log into /admin, create a Page, add content blocks, publish it, then hit the root URL and confirm the frontend renders it. That single loop — admin form → model → Blade view — is the core of everything TrovCMS does, and verifying it end-to-end tells you whether the install is healthy.

Implementation Patterns

Treat it as a fork, not a dependency. The correct mental model is "I generated a Laravel + Filament app with a content model already wired up." Commit the generated code to your own repo on day one and make all changes there. You are not tracking upstream.

Content modeling happens in Filament resources. To add a new content type (e.g. Article):

• php artisan make:model Article -m, add fields to the migration, migrate.
• php artisan make:filament-resource Article and configure the form/table schema.
• Mirror the routing pattern used by the existing Page resource so the frontend can resolve /articles/{slug}.

Because the frontend route is usually a slug-resolving catch-all, adding a content type is really two edits: a Filament resource (admin) and a route/controller branch plus Blade view (frontend). Keep those in sync.

Block-based content is the main extension point. Page bodies are typically composed of repeatable blocks rendered as Blade partials. The day-to-day pattern is:

// app/Models/Page.php (shape varies by install)
public function renderBlocks(): string
{
    return collect($this->blocks)->map(function ($block) {
        $view = 'blocks.' . $block['type'];
        return view()->exists($view) ? view($view, $block)->render() : '';
    })->implode('');
}

Adding a block type = new Filament repeater entry + new partial in resources/views/blocks/. Keep the block type string as the contract between the two.

Frontend integration. Themes are Blade layouts. Override resources/views/layouts/app.blade.php (or equivalent) to swap in your CSS framework; the CMS content flows into @yield/{{ $slot }} areas. If you need Livewire on the public site, remember Filament already ships Livewire, so @livewireStyles/@livewireScripts are available — but keep the admin panel and frontend layouts separate to avoid pulling admin assets into public pages.

Environment-driven config. Keep things like FILAMENT_PATH, filesystem disk, and any locale defaults in .env and reference them from config so staging/production differ without code changes. This matters more than usual because starter kits tend to hardcode assumptions in the panel provider.

Deployment workflow. Standard Laravel deploy plus: run migrate --force, ensure storage:link exists, and cache config/routes/views (config:cache, route:cache, view:cache). Filament resources are class-based and cache-safe; Blade block partials benefit heavily from view:cache since there can be many of them.

Gotchas and Tips

It is effectively unmaintained. Last release was September 2022. That implies Laravel 9 and Filament v2 — both now behind current versions (Filament v3/v4, Laravel 10/11/12). Do not attempt to composer update blindly; you will pull a Filament major version whose API is incompatible with the resources in this kit. Pin versions in composer.json and upgrade deliberately, or budget for a migration. For a new build, seriously consider starting from a current Filament starter kit instead and porting the content model.

Stars are low (18) and the surface is small. There is no community to lean on for answers — no Stack Overflow corpus, no Discord. Debugging means reading the code, which is fine because you own it, but don't expect to find the answer to "why does my block not render" online. Read the partial and the model accessor.

Filament debugging. When an admin form silently fails to save, the cause is usually a field missing from getFormSchema() or a mismatch between the field name and a $fillable/cast on the model. php artisan filament:optimize-clear and clearing bootstrap/cache resolve most stale-schema weirdness after edits. Check storage/logs/laravel.log — Filament validation and save errors surface there.

Seeder assumptions. Starter kits often seed a demo admin with a known password and sample pages. Run the seeder in development, but never run it in production — write your own minimal seeder or create the first user via php artisan make:filament-user if that command is available.

Uploads and storage. Media fields generally point at the public disk. If images 404 in production, it's almost always a missing storage:link symlink or a disk misconfiguration in config/filesystems.php — not a CMS bug.

Catch-all route ordering. The frontend slug resolver is usually a Route::get('/{slug}')->where(...) near the bottom of routes/web.php. Register your own explicit routes (contact, search, sitemap, auth) above it, or the catch-all will swallow them.

Extension points to prefer. Add functionality via new Filament resources, custom Filament pages/widgets, and new block partials. Avoid editing vendor code (there is little) and avoid modifying config/filament.php directly when an .env variable exists — you'll lose it on the next config publish.

Escaping and CMS content. Block content is user-authored; render text with {{ }} and only use {!! !!} where you have deliberately allowed sanitized HTML (e.g. a rich-editor block). Filament's rich editor output is not automatically safe to raw-print in every configuration.

No upgrade path. Because this is a scaffold, "updating TrovCMS" is not a thing. Record the versions you scaffolded with (composer.lock in your repo) and treat Laravel/Filament upgrades as your own migration project.