awcodes/trov-faqs
A Laravel package by awcodes for adding FAQ management to Trov-powered sites, letting you create, organize, and display frequently asked questions with a simple, familiar Filament-style workflow.
Read the baseline before writing any code. The package is archived and last shipped on 2022-05-25 at v0.1.5, a release whose entire note is "Bump dependencies." Zero stars, no maintenance signal. Treat it as a reference implementation you are adopting ownership of, not a dependency you can lean on. If the FAQ feature is genuinely useful to you, plan to fork it into your own vendor/namespace within the first sprint.
Pin exactly, never with a caret.
"require": {
"awcodes/trov-faqs": "0.1.5"
}
^0.1 would let an unattended composer update pull an unreviewed pre-1.0 release into production. There will be no more releases, but the pin also documents intent for future maintainers.
Order of operations for the first hour:
composer.json on GitHub. Check require (php, illuminate/*, filament/filament, awcodes/trov), require-dev, and the PSR-4 root. You need the Filament major version — this is a 2022 package, so it almost certainly targets Filament v2.composer require awcodes/trov-faqs:0.1.5 against a feature branch, not main. Observe platform-requirement and conflict output.extra.laravel.providers); register manually in config/app.php if absent.php artisan vendor:publish --provider="Awcodes\TrovFaqs\TrovFaqsServiceProvider"
php artisan migrate
config/trov-faqs.php (resource/model binding, table names, sort column), src/Resources/ (the Filament resource), database/migrations/ (schema and column defaults), resources/views/ (Blade components), and the service provider (Blade namespace registration, component aliases).First real use case: seed 3–5 FAQs, toggle two of them to draft, render the published set on a /faq page via the package's Blade component, and confirm drafts do not appear for a guest. That single exercise validates installation, ordering, publishing, and rendering at once — an hour's work that surfaces most integration problems.
Wire the FAQ resource into Trov's panel. The package plugs into Trov's resource system rather than registering itself independently. Point the config at the Trov resource/collection you want FAQs to live under, then verify the entry appears in panel navigation next to your other content types. This is config, not code — which is good, but it means a stale config cache is a common cause of "the menu item vanished."
Own the read path. The package gives you CRUD and ordering; it will not give you caching, authorization, or output hardening. Write your own query service and let the Blade components be a fallback:
final class PublishedFaqs
{
public function all(): Collection
{
return Cache::rememberForever('faqs.published', fn () => Faq::query()
->where('is_published', true)
->orderBy('sort')
->orderBy('id')
->get(['id', 'question', 'answer', 'sort']));
}
}
Bust that key from model events (saved, deleted) or an observer — the publish toggle in the Filament resource will not do it for you.
Preview drafts for editors only. Guard the unpublished branch behind auth()->check() (ideally a panel-access check) so the same partial serves both the public page and an editor preview, without a second template.
Serve structured data from the same collection. An FAQ page's main SEO value is FAQPage JSON-LD. Since you already have the ordered published set, emit it from the same service class — one source of truth, no drift between visible copy and markup.
Headless/API consumers. If a JS front end renders the FAQ, add a two-line route returning PublishedFaqs::all() as JSON. The package is admin-side; the delivery side is yours either way.
Test the two behaviors that matter. A feature test asserting drafts are excluded for guests, and one asserting display order follows the sort column. Snapshot the rendered component output so a published-view override that breaks markup fails loudly.
When you need to change behavior, publish views and use model events first. Publish overrides into resources/views/vendor/trov-faqs/ before touching source. Fork the PHP only when config, events, and view overrides are all insufficient.
Filament major mismatch is the top install risk. A 2022 package targets Filament v2. If your estate is on Filament v3, Filament\Resources\Form → Schemas\Schema, getPages() signatures, and table-builder APIs all changed. Budget a rewrite of the resource class, and decide up front whether that's cheaper than writing the CRUD yourself (for two fields and a sort column, it often is).
Rich-text answers are an XSS surface. If answers are stored as HTML and rendered with {!! !!}, sanitize on write or on render with an allowlist (HTMLPurifier, or a narrow strip_tags allowlist). This is the highest-severity day-to-day issue in an FAQ feature — the content is user-editable and rendered on public pages.
Check the publish column default in the migration. A boolean('is_published')->default(true) means every new FAQ goes live on save, before the author has proofread it. Set the default to draft in your own migration if necessary, and always filter in your own query rather than trusting the Blade component to scope.
Don't trust the component's scoping either way. Read the view. If it renders Faq::all(), you have a data leak the moment you use it on a public page. Wrap it, or override the view.
Ordering is racy. Drag-and-drop writes a sort integer; simultaneous editors, bulk inserts, or seeded rows without explicit sort values produce duplicates and NULLs. Always add a deterministic tiebreaker (->orderBy('sort')->orderBy('id')) and seed with explicit sort values.
Migration ordering. If the published migration carries foreign keys into Trov's tables, Trov's migrations must run first. Confirm the timestamp ordering in a fresh migrate:fresh, not just in an already-migrated dev database.
Config caching bites on config-driven bindings. After changing the Trov resource binding or table names, run php artisan config:clear. A cached config pointing at the old resource produces confusing "nothing renders" symptoms with no error.
Blade component namespace. If <x-trov-faqs::...> doesn't resolve, the provider isn't registering a component namespace. Check the provider and fall back to @include('trov-faqs::...') — it's a five-minute fix but reads like a broken install.
Authorization on reorder. Verify the Filament resource has a policy or canReorder gate. A bare resource with no policy means any panel user can reorder (and, depending on setup, edit) FAQ content.
No security patching means composer audit in CI is your only signal on the transitive illuminate/* and filament/* graph behind an abandoned package. Add it if you don't have it, and assign one owner for the per-release review habit before it drifts between people.
Write the exit plan down now. Because content lives in plain tables, migrating off the package is: one Filament resource, one Blade partial, keep the tables. Document that path in the README next to the install steps — it's the single most valuable artifact you can leave for the next developer who inherits an archived dependency.
How can I help you explore Laravel packages today?