Faq Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a FAQ / knowledge-base surface — now with stronger evidence for "build." The v2.0.0 release adds isActive, publishAt, expiresAt (activation + scheduling), a rudimentary MySQL search, and a "most popular search queries" listing. These are exactly the capabilities a self-serve support surface needs, and the package's own approach — hand-rolled MySQL search described by the maintainer as "very, very, very, very simple" — is the level of sophistication we would implement in a thin in-house feature. The release is a spec, not a candidate.
• Roadmap scoping for self-serve support content. Updated effort estimate: a Faq model with question/answer/category, ordering, slug, soft activation (is_active), scheduled publish/expiry (publish_at, expires_at), plus basic full-text search and a search-query log table, is roughly 3–4 days in Laravel with our existing admin tooling — still cheaper than integrating, adapting, or maintaining a foreign bundle.
• Reference-only input to our own data model. The v2.0.0 additions are directly portable as schema concepts (status flags, scheduling columns, a faq_search_queries table for popularity analytics) even though none of the Symfony code ports to Laravel. Use the release notes as a checklist when we spec our tables.
• Search strategy signal. The package's "very, very, very, very simple mysql search" plus an analytics table is a useful baseline: start with LIKE/MySQL full-text and log queries; only escalate to a dedicated search engine (Meilisearch/Scout) if query-volume data justifies it. This de-risks the build decision.
• Negative decision on framework portability — unchanged by the release. v2.0.0 is explicitly "compatible with sf3.2." A new release targeting Symfony 3.2 in 2024+ confirms the maintainer is not tracking a modern runtime. No Laravel service provider, no publishable config/migrations, no facade — still not droppable into a Laravel app.
• Supply-chain hygiene precedent. Recording this as an explicit rejection (archived repo, minimal stars/dependents, Symfony 3 EOL since Jan 2021, and even its newest release pins to EOL Symfony) strengthens the rule that unmaintained dependencies don't enter the tree for non-differentiating features.

When to Consider This Package

Consider it only in one narrow case: we are maintaining an inherited Symfony 3 application that already depends on GenjFaqBundle, and even then the correct move is to fork and vendor the MIT-licensed code rather than rely on the upstream archive. If that inherited app needs scheduling or basic search, v2.0.0's feature set is the floor of what a fork would need to provide.

Look elsewhere — or build — in every other case, against these criteria:

• Framework fit. We are a Laravel shop. The package offers nothing that installs via Composer into a Laravel app: no auto-discovery, no service provider, no config or migration publishing.
• Runtime compatibility. v2.0.0 declares compatibility with Symfony 3.2, which is end-of-life and whose PHP constraints conflict with PHP 8.x. A Laravel app on a modern PHP runtime cannot host it. That the latest release still targets EOL Symfony is a stronger negative signal than before.
• Maintenance viability. Archived repository, no security response path, no issue triage. Any CVE or PHP-version break is ours to fix and fork.
• Adoption signal. Minimal stars and zero dependents mean no battle-testing and no community to lean on — the v2.0.0 features are effectively untested in the wild.
• Feature depth. The new search is intentionally minimal (simple MySQL LIKE-tier matching, no relevance ranking, no indexing beyond MySQL). It does not change the build-vs-buy math and is not a reason to adopt.
• Alternatives. In-house Eloquent model + Filament/Nova admin, optionally with Laravel Scout/Meilisearch for search; a headless CMS (Statamic, Strapi, Contentful) if marketing owns content; a helpdesk knowledge base (Zendesk, Intercom) if support owns it. On Symfony, use current Symfony 6/7 packages.

How to Pitch It (Stakeholders)

Bottom line: do not adopt — the v2.0.0 release does not change the recommendation. The new version adds useful ideas (activation flags, scheduled publish/expiry, basic search, popular-query analytics) but is explicitly built for Symfony 3.2, an end-of-life framework that cannot run on our modern PHP stack and whose bundle architecture does not translate to Laravel. The release confirms the package is still anchored to a dead runtime; the overall low composite score stands.

For engineering: the v2.0.0 features are cheap to reproduce. Treat them as a spec: is_active, publish_at, expires_at, a slug, category ordering, a LIKE/full-text search, and a faq_search_queries log for popularity. That is roughly 3–4 days behind our existing admin tooling, with tests and full ownership. The maintainer's own "very, very, very, very simple mysql search" is a signal we should not over-invest in search on day one — start simple, log queries, and escalate to Scout only if data demands it. There is no shared code to salvage across the framework gap.

For executives: adopting it would add an unmaintained dependency pinned to end-of-life Symfony to our supply chain, in exchange for saving a few days on a non-differentiating feature. The recommended path is unchanged: build the FAQ surface internally (the release even gives us a sensible feature shortlist and a low-risk search baseline) or hand content ownership to our CMS/helpdesk. Revisit only if we acquire or inherit a Symfony 3 codebase — in which case we fork and vendor the MIT code rather than track upstream.