Faq Admin Bundle Laravel Package

Getting Started

Reality check before anything else: genj/faq-admin-bundle is a Symfony bundle, not a Laravel package. Its composer.json declares "type": "symfony-bundle", it ships a DependencyInjection/*Extension.php, and its admin screens are built on the Symfony admin stack of that era (typically SonataAdminBundle). There is no service provider, no config/faq-admin.php, no publishable views, and no Blade templates. composer require genj/faq-admin-bundle in a Laravel app will either fail on Symfony version constraints or drag in a pile of framework code you cannot boot. With 0 stars, 0 dependents, last release 2017-06-10, and the repo archived, there is no support path if it breaks.

So the only realistic "getting started" is as a specification to read, not a dependency to install.

1. Clone the repo and read these files first, in this order:
   • composer.json — confirms the Symfony/Sonata/PHP version ceilings (expect PHP 5.x–7.x, Symfony 2.8/3.x).
   • src/Genj/FaqAdminBundle/Admin/*Admin.php — the actual value. This file lists the FAQ fields, the list view columns, the filters, and the form widgets. This is your data model.
   • Resources/config/doctrine/*.orm.yml (or entity annotations) — field names, nullability, lengths, relations to a category entity.
   • Resources/config/admin.yml — how the admin service is wired; tells you what "managed" means here (CRUD + list filters + ordering).
2. Extract the field list into a Laravel migration and model. A typical shape from this family of bundles:

Schema::create('faqs', function (Blueprint $table) {
    $table->id();
    $table->foreignId('faq_category_id')->nullable()->constrained()->nullOnDelete();
    $table->string('question');
    $table->text('answer');
    $table->string('slug')->unique();
    $table->unsignedInteger('position')->default(0);
    $table->boolean('is_published')->default(false);
    $table->timestamps();
});

3. First use case: stand up a Filament (or Nova/Backpack) resource over that table. You get in an afternoon what the bundle gave a Symfony 3 app in 2017 — and you get it on a supported framework.

If you are actually maintaining a legacy Symfony 3 project rather than a Laravel one, the bundle is still a poor bet: the PHP and Sonata version pins will fight any modern runtime, and "archived" means no patch will ever arrive.

Implementation Patterns

Pattern 1 — Port the admin UX, not the code. The bundle's *Admin.php class is effectively a config object. Read configureListFields, configureFormFields, configureDatagridFilters, and configureRoutes, then translate each one-for-one:

The recurring feature set in Genj admin bundles is: category filter, published toggle, drag/position ordering, and a rich-text answer field. Reproduce those four and you have parity.

Pattern 2 — Category + FAQ as a two-resource admin. The bundle almost certainly pairs with a category entity. Model it as FaqCategory hasMany Faq, expose category as a BelongsTo select in the FAQ form, and add a Reorderable table column for position. Use a scopePublished() on the model so the front end never has to remember the flag:

public function scopePublished(Builder $q): Builder
{
    return $q->where('is_published', true)->orderBy('position');
}

Pattern 3 — Translatable content, if the bundle used it. Older Genj bundles often leaned on a translation table or a2lix/translation-form-bundle. If the ORM mapping shows a faq_translation table, use spatie/laravel-translatable with a JSON question/answer column instead of a join table — simpler queries, same admin behavior.

Pattern 4 — Front-end consumption. The bundle only administers; rendering was your job then and is your job now. Cache the published list (Cache::remember('faqs.published', 3600, ...)) and bust it from the admin resource's afterSave/afterDelete hooks — an obvious win the 2017 bundle never offered.

Integration tips:

• Keep the copied code MIT-compliant: retain the original copyright notice in a NOTICE file if you lift any PHP verbatim.
• Don't try to bridge Symfony DI into Laravel's container. There is no clean seam; the bundle's services assume a kernel and an event dispatcher with Symfony semantics.
• If a stakeholder insists on "using the package," scope it explicitly as reference-only in writing, with the Laravel reimplementation as the deliverable.

Gotchas and Tips

• Framework mismatch is fatal, not cosmetic. A Symfony bundle's Extension class is invoked by Kernel::build(). Laravel never calls it. You will get an installed package with zero registered behavior — the worst possible failure mode, because composer require succeeds and nothing works.
• Archived + 2017 + 0 dependents = no escape hatch. No PHP 8 compatibility, no PSR-4 guarantees (older Genj bundles used PSR-0 paths like src/Genj/FaqAdminBundle/, which Composer 2 handles poorly), no security advisories, no Stack Overflow corpus. Any bug you hit is yours alone.
• Admin surface = attack surface. Running unmaintained CRUD code that writes to your database is a genuine liability. If you inherit a project already using it, isolate it behind auth and plan the removal before adding features to it.
• The Sonata coupling is the real trap. The "admin" is not the bundle's own UI — it is SonataAdmin configuration. Porting it means porting Sonata's conventions, which do not map cleanly to Filament or Nova. Budget time for rethinking the UX rather than translating it literally.
• Debugging (if you must, on Symfony): bin/console debug:container | grep faq and confirm the bundle is registered in AppKernel.php. A missing registration is the #1 cause of "installed but invisible." In Laravel, there is nothing to debug — stop and re-scope.
• Extension points are not worth using. There is no documented event system here, and with zero dependents nobody has validated one. Treat the repo purely as a field-list artifact.
• Cheaper alternatives for the actual goal: Filament v3 resource (built-in), backpack/faq-style CRUD packages, Nova, or ~150 lines of hand-rolled controller + Blade. Any of these beats resurrecting a 2017 Symfony bundle inside a Laravel app.
• Score 0.03 is the honest verdict. Not "low quality" — effectively abandoned and inapplicable. The correct day-to-day leverage is: read it once for the schema, then close the tab.