Cms Faq Bundle Laravel Package

Getting Started

This is a Symfony 2.x bundle (not Laravel). If you are a Laravel developer, treat it as a legacy integration you'd only touch when inheriting a PrestaCMS site — there is no Laravel service provider, facade, or config file here.

Minimal steps to bring it up in a PrestaCMS project:

composer require presta/cms-faq-bundle

Register the bundle in app/AppKernel.php:

public function registerBundles()
{
    $bundles = array(
        // ...
        new Presta\CMSFAQBundle\PrestaCMSFAQBundle(),
    );
}

Import routing (for the front controller and Sonata admin routes):

# app/config/routing.yml
presta_cms_faq:
    resource: "@PrestaCMSFAQBundle/Resources/config/routing.yml"
    prefix: /

Run the schema update so the FAQ and category tables exist:

php app/console doctrine:schema:update --force

Then a Sonata admin user with ROLE_ADMIN can create FAQ categories and entries at /admin/presta/cms/faq.

Where to look first, in order:

1. README.md — installation, config, and the Twig block usage.
2. Entity/ — Faq, FaqCategory and their repository classes. This is where the real domain lives.
3. Admin/ — Sonata admin definitions; these tell you which fields exist and how they are grouped in the UI.
4. Resources/views/ — the default templates you'll either use or override.

First use case: create two or three categories via Sonata admin, add FAQs to each, then render the front list in a PrestaCMS template block. Once that renders you have a working baseline and can start customizing templates.

Implementation Patterns

Category → FAQ grouping. The bundle models FAQs as children of categories (FaqCategory has a oneToMany to Faq). Every rendering pattern funnels through a repository query scoped to a category, so always work with the category repository rather than querying FAQs directly — otherwise you lose the ordering and grouping the admin exposes.

Front rendering via the controller. The simplest integration is to let the bundle's controller handle listing:

{{ render(controller('PrestaCMSFAQBundle:Faq:list', { 'categorySlug': 'billing' })) }}

Use this when you want the default markup and you are fine with the bundle's CSS/HTML.

Rendering inside a PrestaCMS page block. The bundle's intended usage is as a CMS block on a page. Create a page in PrestaCMS, add the FAQ block, point it at a category, and the front controller resolves the category by slug and renders. This is the pattern the bundle was built for.

Repository-driven queries for custom views. When you need your own markup, inject the repository and render your own Twig:

$category = $em->getRepository('PrestaCMSFAQBundle:FaqCategory')
    ->findOneBySlug($slug);

return $this->render('AcmeBundle:Faq:index.html.twig', array(
    'category' => $category,
    'faqs'     => $category->getFaqs(),
));

Extending the entities. The clean way to add a field (e.g. isFeatured, order) is to subclass the entity via Doctrine's ResolveTargetEntityListener — configure presta_cms_faq.model.faq.class and presta_cms_faq.model.faq_category.class in config.yml to point at your own classes that extend the bundle ones. Do not edit the vendor files; you'll lose changes on the next composer update and there won't be a next release to reconcile against anyway.

Overriding templates. Symfony's standard bundle override path works:

{# app/Resources/PrestaCMSFAQBundle/views/Faq/list.html.twig #}

Start by copying the bundle's template verbatim, then edit. This keeps the override diff small and readable.

Admin customization. Extend the bundle's Sonata admin classes in your own Admin/ directory when you need extra list filters, exports, or form groups. Register your subclass in your services.yml over the bundle's service id.

Gotchas and Tips

This is archived and dead. Last release was February 2014. There is no maintainer, no security patches, and it targets Symfony 2.x and PHP 5.x. Do not adopt it for new work. The only sane reason to read this bundle is that you inherited a PrestaCMS site that depends on it.

Laravel developers — this is not your package. There is no composer.json service provider, no facade, no config/faq.php, no Artisan command. The idioms (AppKernel::registerBundles, routing.yml, Sonata admin, Doctrine annotations) are all Symfony 2. If you are prototyping in Laravel, model FaqCategory -> hasMany -> Faq with Eloquent and write the admin form yourself; you'll spend less time than porting this bundle ever could.

Composer resolution is the first wall. The composer.json pins Symfony ~2.x and Sonata Admin versions that no longer resolve against modern stacks. Expect to need --ignore-platform-reqs, explicit version pins in your root composer.json, or a full legacy environment (PHP 5.6 / 7.0). If Composer fails on transitive constraints, check the sonata-project/admin-bundle constraint first.

Doctrine annotations, not attributes. The entity mappings use @ORM\... annotations. On any modern PHP/Doctrine combination these will fail to load until you either register the annotation reader (legacy setup) or rewrite mappings as attributes or XML.

Schema drift. doctrine:schema:update --force is convenient but will happily drop or alter unrelated tables if the mappings are inconsistent. On an existing database run doctrine:schema:update --dump-sql first and read the output before applying.

Category slug collisions. The front controller resolves a category by slug; two categories with the same slug will make rendering non-deterministic. Add a unique constraint on FaqCategory.slug if it isn't there.

Sonata roles. The admin entries are hidden behind Sonata's security. If you cannot see FAQ in /admin, check that your user has ROLE_SONATA_ADMIN and that the admin service is registered — the bundle does not grant access implicitly.

Ordering and caching. Sonata admin lets editors reorder FAQs, but the default repository call has no guaranteed order. If you care about presentation order, sort explicitly in the repository or template rather than trusting the database.

Extension point for new work. If you must keep the site running, freeze this bundle and layer your own AcmeFaqBundle on top: your entities extend the bundle's, your admin extends the bundle's, your templates override the bundle's. That gives you a migration seam — when you eventually replace the bundle, you delete the vendor dependency and your classes keep working.

Upgrade path. The realistic move for a Laravel developer inheriting this is to export FAQ data (SELECT * FROM faq_category JOIN faq ON ...), stand up a Laravel model/migration pair, and rebuild the admin with Filament or Nova. The entity schema is small enough that the migration is a day's work rather than a rewrite.