Comment Bundle Laravel Package

Getting Started

This package is the Sonata admin glue for FOSCommentBundle — it does not implement commenting itself. Before writing a line of code, confirm it will even install: it targets the Symfony 2.8/3.x + SonataAdmin 3.x generation and expects friendsofsymfony/comment-bundle (FOS\CommentBundle), FOSRestBundle, and JMSSerializerBundle alongside it. On Symfony 4+ composer require will fail on constraints; on 5/6 it will fail on the AppKernel/bundle-registration model entirely. The repository is archived, so treat any installation as a maintenance task on an existing app, not a greenfield choice.

Minimal steps on a compatible (legacy) app:

1. composer require rmzamora/comment-bundle — verify the namespace it registers (Sonata\CommentBundle) and that a tagged release/dev-master alias resolves; with 0 stars and a personal fork you may need a VCS repository entry plus an explicit constraint.
2. Register the bundles in AppKernel: new FOS\CommentBundle\FOSCommentBundle(), new FOS\RestBundle\FOSRestBundle(), new JMS\SerializerBundle\JMSSerializerBundle(), new Sonata\CommentBundle\SonataCommentBundle(). Order matters — Sonata bundles last.
3. Import routing: fos_comment_api (the REST endpoints backing the JS UI) and sonata_comment admin routes.
4. Configure fos_comment with db_driver: orm, plus fos_rest and jms_serializer; enable the FOSComment API if you want the stock front-end.
5. doctrine:schema:update --force or generate a migration for comment_thread / comment.
6. First use case: open /admin/sonata/comment/thread/list and moderate — list threads, drill into comments, edit or delete. That admin panel is the whole reason to install this bundle rather than FOSComment alone.

Where to look first: vendor/rmzamora/comment-bundle/Admin/ for the admin classes and Resources/config/admin.xml for the service IDs you'll be overriding. That file is your source of truth, not the docs (there won't be any).

Implementation Patterns

Extending the bundled admins rather than replacing them. The bundle ships CommentThreadAdmin / CommentAdmin (or the equivalent sonata.admin.comment.* services). Subclass them, then redefine the service with the same ID in your own services.yml and re-tag with sonata.admin; that is the least invasive way to add columns, filters, or a configureFormFields for moderation state.

Moderation workflow. FOSComment's Comment carries a state (valid / invalid) and Thread carries isCommentable / isCommentingEnabled. The practical pattern is a Sonata BatchAction that flips comment state, plus a datagrid filter on state, so moderators never touch raw rows.

Swapping the model. Never edit vendor entities. Set fos_comment.comment.class (and thread.class) to your own classes extending the FOS mapped superclasses, add fields (author IP, spam score, tenant ID), and let the bundle's admin pick them up automatically because the admins are model-driven. If you integrate FOSUserBundle authors, wire resolve_target_entities for the user model or the author association stays untyped.

Front-end integration. The stock path is FOSComment's JS client hitting fos_comment_api via FOSRest + JMSSerializer. If you're already in a legacy app, this usually means dropping async.html.twig into a page and configuring fos_comment's service/acl options. If you don't want the API surface, render threads server-side with a small controller and skip fos_comment_api routing entirely — the Sonata admin side keeps working without it.

Dashboard visibility. Register a Sonata block or a KnpMenu entry so "Recent comments" shows on the admin dashboard; this is the highest-value day-to-day touchpoint for a moderator.

Gotchas and Tips

• Abandoned on both ends. This bundle is archived and its core dependency, FOSCommentBundle, stopped at Symfony 3-era. There is no security-update path. For anything new, use a custom comment entity with EasyAdmin/Sonata CRUD, or an external service. Choose this package only to keep an existing install alive.
• Dependency hell is the default failure mode. FOSCommentBundle pins FOSRestBundle/JMSSerializerBundle to Symfony-2/3-compatible majors. A single composer update elsewhere in the tree can unresolvable-conflict the whole thing; pin with composer.lock and don't float.
• Package name is misleading. The Composer package is rmzamora/comment-bundle but the PHP namespace and repo are SonataCommentBundle. Check autoload.psr-4 in the fork's composer.json before assuming Sonata\CommentBundle\...; a personal fork may have diverged from upstream in ways that break overrides.
• Service-ID overrides are brittle. You must redefine the exact ID from Resources/config/admin.xml after the bundle loads; if your bundle is registered before SonataCommentBundle, your definition is silently clobbered. Debug with bin/console debug:container | grep -i comment.
• Routing clashes. fos_comment_api and Sonata's admin routes both want /api-ish prefixes; if you see 404s on the JS comment widget, run debug:router | grep fos_comment first — the API routes are usually missing, not broken.
• Templates are the only stable extension point. Override via Twig bundle inheritance (app/Resources/SonataCommentBundle/... old-style, or templates/bundles/SonataCommentBundle/ if backported). Don't patch vendor files; vendor gets reinstalled and your moderation UI disappears.
• Schema drift. The FOSComment mapped superclasses expect indexes on thread and state; if you generated schema with schema:update rather than a reviewed migration, you'll discover the missing indexes only under comment volume. Add them by hand in a migration.
• No upstream support. Zero stars, zero dependents, archived: there is no issue tracker that will answer you. The debugging loop is debug:container → debug:router → read Resources/config/*.xml → read the FOSCommentBundle source. Budget for that, and plan an exit to a maintained CRUD-backed comment model rather than deep investment here.