G Chart Bundle Laravel Package

Getting Started

Reality check first: this is a Symfony 2 bundle, not a Laravel package. There is no service provider, no facade, no config/gchart.php. If you are evaluating it from a Laravel codebase you are looking at it for the idea and possibly for the chart-config PHP classes, not for a drop-in install. Plan on either (a) porting the small chart-builder classes into app/Support/Charts, or (b) skipping it entirely and calling Google Charts from a Blade partial — which is what most people end up doing anyway.

In a Symfony 2/3 app:

1. composer require saad-tazi/g-chart-bundle (expect version constraints that predate PHP 7.4; you will likely need --ignore-platform-reqs or a fork).
2. Register new SaadTazi\GChartBundle\SaadTaziGChartBundle() in AppKernel.php.
3. Read Resources/views/ and the Twig extension class first — that is where the actual API surface lives. The bundle is thin; the chart-building classes and the Twig helper are the whole product.
4. First use case: a server-rendered page that returns a JSON data table plus a google.visualization.LineChart draw call. Build the data in a controller/service, hand it to the template, render the container div.

In a Laravel app: read the classes, copy the data-table array shape (['cols' => [...], 'rows' => [...]]), and render it yourself in Blade with a <script> block that loads https://www.gstatic.com/charts/loader.js. That is ~40 lines and removes the dependency entirely.

Implementation Patterns

• Data-table array as the contract. The durable idea worth stealing is server-side construction of the Google Charts DataTable literal: column descriptors (type, label, optional role) and row arrays of {v: ..., f: ...} cells. Build this in a dedicated class or a ChartData value object rather than inline in a controller — you will reuse it across line/pie/bar/geo variants.
• Builder-per-chart-type. Keep one small class per visualization (Line, Pie, Bar, Geo, Table) that accepts the data table plus an options array and returns {data, options}. The bundle's own structure follows this; mirror it and you keep the option surface discoverable.
• Controller → template handoff. Pattern: controller builds the chart payload, JSON-encodes it with JSON_HEX_TAG|JSON_HEX_APOS|JSON_HEX_QUOT|JSON_HEX_AMP (important if any label is user-supplied), passes it to the view, view does new google.visualization.LineChart(el).draw(new google.visualization.DataTable(payload.data), payload.options).
• Wrap the draw in a small JS helper. One Blade/Twig partial that takes (elementId, chartType, payload) and centralizes google.charts.load('current', {packages: [...]}), the callback, resize handling, and error display. Do not let every view call google.charts.load — the loader is idempotent-ish but the callback coordination gets messy fast.
• Cache the payload, not the HTML. Chart data is usually the expensive part (aggregate queries). Cache the serialized data table with a short TTL keyed on filters; render fresh each request so the JS version/options stay current.
• Escape hatch for interactivity. Anything past static rendering (drill-down, filter widgets, dashboard binding) should move to ChartWrapper/Dashboard/ControlWrapper rather than hand-rolled event listeners. The bundle predates most of this; you will be writing it yourself.

Gotchas and Tips

• Google Chart Image API is dead. Google retired the Image Charts endpoint permanently. Any part of this bundle touching chart.googleapis.com/chart (and the Infographics API, likewise deprecated) is non-functional, not merely deprecated. Do not budget time trying to make it work — use the JS charts or a server-side renderer like QuickChart.
• Symfony 2 vintage. Expect unmaintained PHP 5-era code: loose typing, array() syntax, no strict_types, possibly Symfony\Component\HttpKernel APIs that no longer exist. If you adopt it into a modern Symfony app, vendor a fork rather than fighting Composer's platform checks.
• Zero dependents, 20 stars, last activity long past. Treat it as a reference implementation, not a dependency. The realistic risk is not a CVE — it is that the one behavior you rely on (option key naming, data-table cell shaping) silently diverges from current Google Charts docs and you spend an afternoon diffing against developers.google.com/chart.
• Options arrays are passed straight through to Google. Typo'd keys (vAxis.gridlines vs vAxes.0.gridlines) fail silently — the chart renders with defaults and you assume the bundle dropped your config. Debug by logging the final JSON.stringify payload and testing it in a standalone HTML file with no framework in the way.
• loader.js vs the old jsapi script. Only https://www.gstatic.com/charts/loader.js with google.charts.load('current', ...) is current. If the bundle emits a <script src="https://www.google.com/jsapi"> tag, that path has been deprecated for years — replace it.
• Numbers as strings. MySQL/PDO returns aggregate results as strings; Google Charts will happily treat "42" as a category and give you a bar chart of equally tall bars or a broken axis. Cast to int/float (or use {v: 42, f: "42 units"} deliberately) before serializing.
• Date columns need new Date(...), not strings. The JSON data-table format only understands Date objects for date/datetime types, so plain json_encode of a data table with dates produces strings that render as empty series. Serialize dates as Date(2024,0,15) fragments or use google.visualization.arrayToDataTable with a JS-side conversion.
• XSS surface. Labels, tooltips, and formatted values are injected into the DOM by the renderer. If any of them come from user data, they need escaping before they reach the payload — JSON_HEX_* flags plus a whitelist on which fields you accept.
• Extension points are thin. Since the bundle is small, the cheapest customization is not extending its classes — copy the chart-builder into your own namespace and add the option merging/role-column helpers you actually need. You will spend less time than tracing an unmaintained inheritance chain.