Faq Bundle Laravel Package

Technical Evaluation

Architecture fit — none, unchanged. genj/faq-bundle v2.0.0 is still a Symfony 3 bundle: a GenjFaqBundle registration class, a DependencyInjection/ extension, YAML routing and service definitions, Doctrine ORM entities/repositories, and Twig templates. Nothing in the release moves it toward a framework-agnostic package. The new capabilities (scheduling fields, search, popular-query reporting) are implemented inside the same Symfony container/Doctrine/Twig assumptions. Laravel still has no bundle loader, and the bundle still assumes Symfony's kernel, event dispatcher, and container semantics. Embedding it remains an act of hosting a second framework, not an integration.

Integration feasibility — still zero without a fork, and the fork just got bigger. The three blockers from the original assessment all persist, and the release adds scope on top of them:

1. Framework mismatch. Unchanged. No service provider, no Blade, no Eloquent. The search and reporting features are wired through Doctrine repositories and Symfony controllers, none of which transfer.
2. Dependency conflict. The release notes assert "compatible with sf3.2" — this is a compatibility narrowing, not an expansion. Symfony 3.2 reached end of maintenance in January 2018. Declaring continued Symfony 3.2 support signals the package's ceiling is PHP-5.5-era Symfony, which is in direct conflict with Laravel's symfony/* ^6/^7 transitive requirements. Composer resolution still fails or forces a whole-application downgrade.
3. Scope mismatch — expanded. The domain is no longer "plain FAQ CRUD." v2.0.0 adds publish/expiry scheduling, a MySQL text search path, and a popular-search-queries report. Each is small in isolation but each carries semantics you must specify before rebuilding: timezone handling for publishAt/expiresAt, whether expiry soft-hides or 404s, whether scheduled content is cache-visible, what "very, very, very, very simple MySQL search" means at the query level, and what the query-log retention policy is.

Technical risk — high and non-mitigable, with two new specific concerns.

• The search implementation is self-described as naive. "Very, very, very, very simple mysql search" almost certainly means LIKE '%term%' scans or an unindexed MATCH without relevance tuning. That does not scale past a small FAQ table and cannot be cached effectively because it is query-shaped by user input. If search matters to the product, this is a feature you would rebuild with a proper index (or Meilisearch/Scout) regardless of framework.
• Popular-search-query logging introduces a write path and a growing table. A per-keystroke or per-submit insert is a new hot path, a new unbounded-growth table, and a new PII surface (users' search terms). None of that is documented in the release notes, and there is no maintainer to ask.
• Major version bump with no migration notes. v2.0.0 introduces new columns. There is no changelog entry describing a migration, a schema diff, or backward compatibility for the isActive/publishAt/expiresAt semantics. For an archived package, "read the entity definitions and guess" is the migration guide.
• Archived status is unchanged. Still unmaintained, still 0 dependents, still no CVE response path. The release does not revive the project.

Key questions for the decision gate:

• Does our product need scheduling (publish/expiry) at launch, or is it a later-phase nice-to-have? This is the only release item that materially changes rebuild scope.
• Does our product need on-site search at all, and if so is "naive MySQL" acceptable or do we want a real index? Decide before copying the pattern.
• Do we need search-analytics reporting? If yes, note it is a logging + aggregation concern with retention and privacy implications, not a FAQ concern.
• Is there legacy FAQ data, now possibly including search-query history, that must be preserved? Data is portable; code is not.
• What is the revised cost delta? A Laravel-native FAQ with scheduling plus a proper search index and a simple query-stats table is roughly 3–6 engineer-days, up from 2–4. The bridge-and-fork path remains measured in weeks and now includes reimplementing and validating scheduling and search semantics with no upstream support.

Overall assessment: the release adds features to a package that remains structurally unadoptable in a Laravel codebase. The composite score and opportunity signal should be discounted — any recency or activity bump from a v2.0.0 tag reflects a release event, not a change in fitness. This package should still be treated as a reference design and a requirements checklist, not a dependency. The most useful thing v2.0.0 provides is a free enumeration of the feature set we should build: active flag, publish/expiry scheduling, basic search, popular-query reporting.

Integration Approach

Stack fit — incompatible by construction. Target stack is Laravel (PHP 8.x, Eloquent, Blade, Laravel's symfony/* ^6/^7 transitive dependencies). The bundle targets Symfony 3.2 / PHP 5.5.9+ / Doctrine ORM 2.x-era APIs, and the new release reaffirms rather than relaxes that pin. Composer will not install this alongside a current Laravel application without pinning the dependency graph backwards.

Migration path — extract the schema and the requirements, discard the code. Revised sequence:

1. Spike (1–1.5 days, up from 1). Read the bundle's entity definitions, controllers, and the new search/reporting code. Document the implicit schema: FAQ category, question, answer, ordering column, isActive, publishAt, expiresAt, slug/locale fields, plus whatever table backs the popular-search-query log. Document the semantics you cannot infer from column names: timezone basis for scheduling, visibility rules for expired vs. inactive vs. future-dated items, and the exact search predicate.
2. Decision gate. If the schema is still a plain category→question→answer tree with two date columns and a log table (likely), stop and rebuild. If the scheduling or search rules encode non-obvious behavior, write those rules into a spec before writing code — this is the only place the bundle can save you time.
3. Rebuild native. Laravel migration for the schema (including nullable publish_at/expires_at and a faq_search_queries log table), Eloquent models with scopes for active(), published(), ordered(), scheduled-visibility composition, a thin controller or Filament/Nova resource for admin CRUD, Blade/Inertia components for the public render, and a cached read path.
4. Search decision point. Implement either a LIKE-based query behind a dedicated endpoint (acceptable at small corpus size) or Laravel Scout with a real engine. Do not port the bundle's query; re-specify it. Index or constrain the input regardless of choice.
5. Data migration (conditional). Only if a production Symfony 3 instance exists: export via Doctrine, transform to the new schema, import via a one-off artisan command with idempotency and a rollback path. If search-query history exists and you want it, decide retention and anonymization before importing.

Compatibility — hard no at the dependency level. Do not add genj/faq-bundle to composer.json, not even as require-dev. The explicit Symfony 3.2 target makes resolver conflict more likely, not less. Vendor a read-only copy into docs/reference/ outside the autoload graph if the team wants to consult the entity definitions.

Sequencing. Spike → gate → schema freeze → parallel tracks: (a) admin CRUD with scheduling, (b) public render with visibility scopes. Search and query-analytics land after the schema is frozen and after the cache layer exists, because both touch the read path. Scheduling must be settled before caching is designed — a cache key that ignores publishAt/expiresAt will serve unpublished content.

Operational Impact

Maintenance — full ownership either way, with more surface now. Adopting the bundle means owning a Symfony 3 fork forever, including PHP 8/9 compatibility, security patches for abandoned transitive dependencies, and a framework bridge — plus whatever maintenance the new scheduling and search code requires, which no upstream will provide. Rebuilding means owning a small Laravel module that looks like the rest of the codebase. Both are "you own it"; only one is legible to the team.

Support — none available. No maintainer, no issue triage, no documentation beyond the README and a terse release note, 0 dependents. The v2.0.0 notes are four bullets; they do not specify timezone handling, migration steps, or search behavior. Any incident is first-principles debugging inside unfamiliar framework conventions.

Scaling — the read side is fine; the new write side is not. FAQ traffic remains read-heavy and cache-friendly, and a rebuilt module behind Laravel's response cache or Redis handles it trivially. Two new caveats specific to this release:

• Search does not cache well. A naive LIKE '%term%' scan over the FAQ table is a full scan per unique query, and the query space is unbounded. At small scale this is invisible; at moderate scale it is the slowest endpoint in the app. Mitigate with a real index or a short-TTL result cache keyed by normalized term.
• Search logging grows without bound. A popular-queries report implies an append-only table. Plan retention (e.g. 90 days), pre-aggregate into a daily rollup, and treat raw terms as potentially sensitive.

Failure modes to plan for:

• Dependency resolution failure at install or on the next composer update, blocking unrelated work.
• PHP/runtime drift — the code stops parsing or behaving correctly on newer PHP with no upstream fix.
• Security exposure from unpatched transitive Symfony 3 components if the bundle is ever executed in production.
• Scheduling correctness bugs if the rebuilt visibility logic ignores timezones or cache TTLs — content appears early, stays live past expiry, or disappears on a cache warm.
• Unbounded log growth / query-term PII if search analytics are implemented without retention and redaction rules.
• Knowledge concentration — one engineer understands the bridge, and they leave.

Ramp-up. A Laravel engineer needs hours to rebuild the base FAQ and roughly a day more for scheduling plus a search endpoint; days-to-weeks to become productive inside a Symfony 3 bundle plus bridge. The ramp-up curve remains inverted relative to the delivered value, and v2.0.0 widens the gap.

Recommendation: do not adopt; update the rebuild scope. Use the v2.0.0 feature list as the acceptance criteria for a native build — active flag, publish/expiry scheduling, search, and popular-query reporting — and budget 3–6 engineer-days instead of 2–4. Keep the dependency graph clean. The only scenario that changes this is a hard requirement to run the existing Symfony 3 code as-is, in which case the correct move is to contain it as a separate service behind an HTTP boundary, not to integrate it into Laravel.