Filament Testimonial Laravel Package

Getting Started

This release (1.1.0) is an i18n-only change — 17 new locales for the Filament admin UI. No API, schema, or config changes. If you're already on 1.0.0, a composer update jeffersongoncalves/filament-testimonial is the whole upgrade.

First steps for a new install:

1. composer require jeffersongoncalves/filament-testimonial
2. Publish and run the migrations: php artisan vendor:publish --tag="filament-testimonial-migrations" then php artisan migrate
3. Publish the config if you need to change table names, guard, or navigation: php artisan vendor:publish --tag="filament-testimonial-config"
4. Register the plugin on your panel in app/Providers/Filament/AdminPanelProvider.php:

->plugin(TestimonialPlugin::make())

5. php artisan filament:optimize-clear (or just hard-refresh) and open the panel — a "Testimonials" nav group should appear.

Start by looking at the published config/filament-testimonial.php and the migration stub; they tell you the model's shape (author, content/quote, rating, published/approved flag, optional image) faster than reading the resource classes. Then check resources/lang/ in the vendor directory to see which translation keys exist before you start overriding labels.

First real use case: a marketing site where an editor curates customer quotes in the panel and your front end renders the approved ones. Wire the resource up, add a couple of records by hand, then move to the front-end query — that loop surfaces most config issues in ten minutes.

Implementation Patterns

Front-end rendering. The plugin gives you the admin side; the public side is yours. Keep it in a small dedicated class rather than scattering queries through Blade:

// app/Support/Testimonials.php
public static function latest(int $limit = 6): Collection
{
    return Testimonial::query()
        ->where('is_published', true)
        ->latest()
        ->limit($limit)
        ->get();
}

Then a single Blade component you can drop on any page. Cache it with a short TTL and bust the cache from the model's saved/deleted events — testimonials are read-heavy and written rarely, which is the ideal caching shape.

Embedding inside other resources. If testimonials belong to a product or a landing page, add a RelationManager on the owning resource that reuses the plugin's form schema, so editors never leave the page they're working on. This is usually the difference between the plugin being adopted and being ignored.

Approval workflow. Most teams don't let editors publish straight to the site. Add a status enum (draft/pending/approved/rejected) and gate the front-end query on approved. You get a submission form for customers, a moderation queue in the panel, and an audit trail — all on top of the plugin's resource with a couple of scopes.

Localization. With 1.1.0 the admin UI ships in 17 locales, so you can set ->locale('de') per user or use Filament's per-panel locale switching without maintaining your own translations. If you've already published translations from 1.0.0, they'll shadow the new vendor files — re-publish or delete the published directory to pick up the additions.

Panel/tenant scoping. In a multi-tenant app, register the plugin on each tenant panel and add tenant_id to the migration. The plugin's resource follows Filament's standard tenancy scoping, so you generally don't need custom query logic — but do verify getEloquentQuery() respects the owner relationship if you've added soft deletes or a global scope.

Seeding and factories. For local development, seed 20–30 records with a factory so list-view pagination, filters, and sorting get exercised. Empty tables hide ordering bugs.

Gotchas and Tips

• zh_CN is the odd one out. The new locale list mixes bare codes (de, fr) with a region-qualified one (zh_CN). Filament resolves locale directories by exact string, so app()->setLocale('zh_CN') works but zh-CN will not fall back gracefully — it just shows English. Same caution applies if you're mapping browser Accept-Language headers to Filament locales; normalize the separator before setting it.
• Published translations win. Once you've run vendor:publish --tag="filament-testimonial-translations", your copies take precedence forever. After upgrading to 1.1.0 you'll see English on screen for a locale that supposedly exists. Delete the published lang/vendor/filament-testimonial directory (or diff and re-publish) before filing a bug.
• Translation cache. php artisan optimize:clear after any lang change; a stale bootstrap/cache will make you doubt the upgrade entirely.
• Publish tag names drift. Tag naming isn't consistent across this author's plugins (-migrations, -config, -translations, sometimes -views). If a publish command silently does nothing, run php artisan vendor:publish interactively and pick the provider from the list rather than guessing the tag.
• Filament major version. These plugins track Filament closely and 1.x branches are pinned per major. Check composer.json's filament/filament constraint before upgrading Filament itself — a Filament 4 bump will strand you on this plugin until a matching branch lands.
• Config caching in CI. If your deploy runs php artisan config:cache, any env-driven config values must be read through config() at runtime, not captured in a service provider's register().
• Extension points, in rough order of safety: publish the config (table/navigation/labels) → publish views and override the Blade → extend the resource class and re-register it on the panel → only then fork. The plugin is small enough that forking is tempting and usually a mistake; the resource's form/table schema is the most likely thing to change between minors.
• Debugging checklist when nothing renders: plugin registered on the correct panel provider (not just AppServiceProvider), php artisan filament:cache-components cleared, and the current user passes the resource's canViewAny() policy. The third one catches people most often in apps with a broad Gate::before.
• Watch the changelog shape, not just the version. This release is CI/dependency housekeeping plus translations; the "What's New" section is the only part that touches runtime behaviour. For this author's packages, read that section first and skim the PR list — it'll save you reading diffs of Dependabot bumps.