jeffersongoncalves/filament-cms
A Filament CMS for Laravel that adds content management resources to your admin panel, letting you create and organize pages, posts, and site content directly in Filament with an intuitive, ready-to-use interface.
This is the first tagged release (1.0.0) of jeffersongoncalves/filament-cms, so treat the release notes as an initial-stable marker rather than a feature guide — the changelog link is the only artifact, so read the repo (README, config/, src/, database/migrations/) before wiring it in.
Minimal path to a working install:
composer require jeffersongoncalves/filament-cms (pin to ^1.0 — see Gotchas).php artisan vendor:publish --provider="JeffersonGoncalves\FilamentCms\FilamentCmsServiceProvider" (check composer.json → extra.laravel.providers if the class name differs), then re-run with --tag=filament-cms-config / --tag=filament-cms-migrations if tags are defined.php artisan migrate — confirm the migration order relative to your existing users/media tables.PanelProvider::panel()->plugins([...]). If the package ships resources only, they are usually auto-discovered; if it ships a plugin class, it must be registered explicitly or nothing appears in the nav.php artisan filament:optimize-clear / php artisan optimize:clear, then log into /admin.First use case: create one Page record in the Filament admin, publish it, and confirm it renders on the frontend via the package's route/view layer (or verify only the admin side works and you own rendering — this distinction drives everything in the next section).
Where to look first, in order:
config/filament-cms.php — route prefix, middleware, disk, model bindings, editor choice.src/Filament/Resources/ — the actual content model exposed to editors; this is the API surface you'll extend.routes/ — whether the package registers a catch-all frontend route (affects your own route ordering).database/migrations/ — table names, foreign keys, and whether it expects spatie/laravel-media-library or spatie/laravel-sluggable (likely transitive deps at 1.0).Model extension over model replacement. Don't fork the package models. Subclass them, point the config's model mapping at your subclass, and add fields there. In a 1.0 package the models are the most likely thing to churn; a thin subclass keeps upgrades cheap. Same for Filament resources — extend the resource class and override form()/table() rather than editing vendor files.
Plugin-per-panel registration. If you run multiple panels (e.g. Admin + Editor), register the CMS plugin only where content editors live. Pair with the panel's ->authorize()/policy setup so a viewAny Page check actually gates the nav.
Content-to-frontend contract. Decide early whether the package owns frontend routing. If it registers a catch-all (/{slug}), it will shadow your own routes — either register your app routes before it or disable the package's route file in config and resolve pages yourself via the model. For a typical marketing site, a small custom controller that resolves by slug + published scope and renders a Blade view gives you far more control than the built-in renderer, and you can still override the package view with view()->prependNamespace(...).
Editor workflow pattern. Use the package's resources as-is for the CRUD shell, then add:
status / published_at pair with a Filament Toggle + DateTimePicker, and an observable that clears the cache on save;saveRelationshipsUsing or afterSave hook to bust a page-cache entry keyed by slug;Seeding and testing. Add factories of your own for the package models (subclassed) and seed a fixture page in TestCase::setUp for feature tests. If you're testing Filament resources, use livewire() assertions against the resource's List/Create pages rather than HTTP-level tests — the resource namespace is the stable part.
Multi-language. If the package exposes translations (JSON columns or a translations relationship), keep the locale resolution in your own middleware, not in the package config. Filament's ->locales() on the form is usually the cleanest integration point.
1.0.0 with a one-line changelog is not a promise of API stability. Pin ^1.0 and read the diff of each 1.x before bumping; expect the config keys and resource namespaces to be the first things to move. Keep vendor edits at zero so composer update stays safe.composer.json for filament/filament: ^3.0 vs ^4.0 before requiring this — Filament v4 changed resource/form APIs substantially and many CMS packages lag. If the constraint doesn't match your app, don't force it.vendor:publish then config:cache is fine, but if you edit the config afterwards without re-caching you'll debug phantom behaviour. Always php artisan optimize:clear between config changes.pages or posts table name that you already use, rename via the published migration before migrate — not after. Also check whether migrations are "loadMigrationsFrom" (can't be edited) or publishable./contact route 404s into the CMS. Run php artisan route:list immediately after install and look for a wildcard; reorder or disable.public; in production with S3 you must set the disk in config and ensure your Filament panel's ->defaultFilesystemDisk() matches, otherwise images save but render broken.saved/deleted) to forget slug-based keys — do this on day one, not after a stale-content bug report.prependNamespace → subclassed models/resources → Filament render hooks → vendor patching (never). If the package exposes no hooks for a change you need, open an issue rather than forking; at 1.0 the maintainer is likely responsive and a fork will cost you every future upgrade.src/ is the documentation. An hour in Resources/ and routes/ will save you a day of guessing.How can I help you explore Laravel packages today?