Report Bundle Laravel Package

Getting Started

• Reality check first: this is a Symfony2 bundle, not a Laravel package. There is no service provider, no config/report.php, no facade. In a Laravel app you will either (a) run it inside a legacy Symfony2 service beside your app, or (b) port the query-building/export logic. Confirm which before investing.
• Install: composer require velvel/report-bundle. Read the require block in its composer.json immediately — expect symfony/symfony ~2.x and Doctrine 2.x constraints. On Laravel 10/11 (PHP 8.1+) it will not resolve; you'll be pinning or forking.
• Wire it up (Symfony2 host): register the bundle in app/AppKernel.php, import its routing in app/config/routing.yml behind a prefix, and add bundle config in app/config/config.yml.
• Schema: the bundle persists report definitions, so run php app/console doctrine:schema:update --dump-sql and review before applying. Run the reporting connection as a read-only DB user.
• First use case: point it at a single read-only reporting view, define a report with two or three columns and one filter, open the route, export CSV. That end-to-end loop is your go/no-go test.
• Where to look first: DependencyInjection/Configuration.php (every real config option lives there), Resources/config/services.xml (what you can override), and the controllers under Controller/.

Implementation Patterns

• Model it as a pipeline: definition (table, columns, filters, sort) → query builder → grid → exporter. Everything you customize hangs off one of those four stages.
• Keep definitions in the database if non-developers should self-serve; keep them in config if you want them code-reviewed and version-controlled. Don't mix the two.
• Point the bundle at dedicated reporting views (report_orders_v) rather than base tables. You then control joins, column names, and data exposure in SQL instead of fighting the bundle's introspection.
• Gate the bundle's routes in your app's firewall/middleware. A package this size has no per-report ACL — authorization is yours to add at the route and role level.
• For a Laravel codebase, the pragmatic split is: generate reports in a console command (Symfony or a port), write CSV to storage, and have Laravel serve a signed download. Do not embed the Symfony kernel inside a Laravel request.
• Extension points that actually work: override the exporter service in the container, and override Resources/views via app/Resources/VelvelReportBundle/views.
• Enforce a row limit server-side. Generated queries are unbounded unless you cap them, and a "report generator" is exactly where someone requests a 40-million-row export on a Friday.

Gotchas and Tips

• Symfony2-era code: PHP 5.x/7.0 idioms, array-based DI config, older Doctrine APIs (getEntityManager, no attributes). Assume patching is required to run it anywhere modern.
• Abandonware risk: 17 stars, 0 dependents, no recent activity. Treat it as sample code you now own a fork of, not a dependency. Budget maintenance time accordingly.
• LGPL-3.0: fine to use as a library. If you fork and modify the bundle and distribute it, your changes to the bundle must stay LGPL — keep your application code in your own namespace to remain on the "use" side.
• The real risk is data exposure, not bugs. An "online report generator" that lets users pick tables and columns is an identifier-injection surface. Whitelist tables and columns, quote identifiers through DBAL, never concatenate user input into SQL, and back it with a read-only DB user.
• Config quirks: unknown keys fail silently in old Symfony DI. After any config change run app/console cache:clear — the container is compiled and stale config is the usual suspect.
• Debugging: log the generated SQL, watch var/logs/dev.log, and check the profiler. Most "empty report" reports are a wrong entity manager/connection or a filter defaulting to no matches.
• Best extension point to lean on: the exporter and the grid templates. If the bundle fights you, lift the query-building logic and drop its UI — that fragment is usually the only part worth keeping.
• Decision rule: if install + schema + first routed report isn't working in an afternoon, stop. A small query-builder plus a CSV endpoint is a few hundred lines and you'll understand all of it.