Lavacharts: PHP charting built on the Google Charts API

What it wraps, and what the freeze means

Lavacharts is a graphing and charting library for PHP 5.4 and later that wraps the JavaScript chart API from Google.

So the shape of the thing is clear from the first line. This is not a drawing library. It is a PHP front end that produces data structures and options and then hands them to a JavaScript charting library that runs in the reader's browser. The PHP side is a typed, comfortable way to describe a chart; the rendering is somebody else's.

That has one large advantage and one large cost, and the release history makes the cost concrete. The three most recent releases are labelled with what they were about: a version freeze of the upstream chart library at version forty seven, a date library version update, and a move to the second version of the dependency manager. The freeze is the one to notice, because it tells you that the set of chart types and options this library can offer is now fixed at whatever the upstream library had at that moment.

The readme's own list of supported chart types is the evidence. There are twenty two of them, and the names read like a catalogue of the charting library's gallery: annotation, area, bar, bubble, calendar, candlestick, column, combo, Gantt, gauge, geo, histogram, line, organisation, pie, Sankey, scatter, stepped area, table, timeline, tree map, and word tree.

The development and stable branches have separate badge rows for the build and the coverage, and the stable branch is the one on the version 3.1 line, which is the branch the readme is written against. The site is lavacharts.com, the licence is MIT, and the last push was in August 2026.

The release history has a long tail, with the newest release in late 2020 and one from 2019 before it, and the developer note at the top of the readme explains that. It says not to be discouraged by the gap, and to read it as the library having settled into a stable state that requires less tinkering, and that new features would be welcome but the maintainer's responsibilities leave little room for his projects. The note closes by saying that issues, questions, and debugging are still welcome, and that the project is not vapourware.

Two steps, and the data table

The usage section describes the design in one sentence, and it is the sentence that explains the whole library: the creation of charts is separated into two parts.

In the first part, inside a route or a controller, you define the chart, the data table, and the customisation of the output. In the second part, inside a view, you use one line, and the library outputs all the necessary JavaScript for you.

The split is the point, and it is the thing a charting library has to get right. A chart has two audiences: the code that decides what the chart is, and the page that shows it. Putting both in one place means the view has to know about the data, and putting them apart means the controller decides and the view just renders. That is the arrangement a framework with a separation of concerns wants, and it is why the library works with a templating engine at all.

The data table is the abstraction in the middle, and it is built out of a chain of column declarations.

$data = $lava->DataTable();

$data->addDateColumn('Day of Month')
     ->addNumberColumn('Projected')
     ->addNumberColumn('Official');

// Random Data For Example
for ($a = 1; $a < 30; $a++) {
    $rowData = [
      "2017-4-$a", rand(800,1000), rand(800,1000)
    ];

    $data->addRow($rowData);
}

Each column is declared with a name and a type, and the type is a role that the library understands, so a date column is formatted as a date and a number column is formatted as a number. The rows are then added as plain arrays, positionally matching the columns.

And the readme notes that arrays work for data tables as well, which is the other way you can build one, and which is the route to take when the data comes from somewhere else and the column roles are not worth declaring individually.

So the model is: columns with names and roles, rows as arrays, and a chart type. The JavaScript is generated from that.

The framework integrations, four Laravel procedures deep

The integration section is long, and the reason is that the library has been around through several generations of the leading PHP framework. The readme documents Laravel from version four through the current auto-discovery era, and Symfony, and it also notes that the library works with any project that uses the dependency manager, including two micro-frameworks, as long as you load the autoloader and create an instance.

The current path is the shortest. Since the framework added package auto-discovery, the readme says you are ready to go with no registration required, and the service provider is included in the package.

Then the older procedures, and they are worth reading because they show what changed. For the previous major version you add the provider and the facade to the two arrays in the configuration file, and the facade is what gives you the short name in your views. And for the oldest supported version the same thing is done with the older array syntax and a different path in the configuration, and the publishing command for the configuration file is spelled differently too.

That is four procedures for the same integration, and the readme keeps all of them. It is a documentation choice that most projects would not make, and it is defensible here, because the audience is a developer integrating a library into an application that already exists, and the version of the framework in the application is not something the library can assume.

The configuration itself is small, and the readme names what goes in it: the date formats used for the data tables, and the key for the maps service used by the geographical chart type. That last one is a good catch by the documentation, because a chart type that needs an external service needs a credential, and a credential that is not in the configuration is a runtime failure in production.

The Symfony path is a bundle, registered in the kernel, with the service definitions imported from a file in the bundle's resources directory. So each framework gets the idiomatic mechanism of that framework: a service provider and a facade in one, a bundle in the other.

The customisation escape hatch, and the client side module

The feature list has one entry that is really a design principle, and it is the second one: any option for customising charts that the underlying library supports, this one should as well, and you use the chart constructor to assign any customisation options you wish.

That is a promise of completeness, and it is the promise a wrapper should make if it is to be worth anything. A charting library that supports half the options of the one underneath is a charting library you will fight when you need the other half. The readme points at the upstream gallery as the reference for what the options are, which is the right way to document a wrapper: by pointing at the source of truth rather than by freezing a copy of it that will go stale.

The other entry with a lot behind it is the custom JavaScript module for interacting with charts on the client side, and the readme lists what it covers: reloading data over AJAX, fetching charts, and integrating events.

That last group matters for a specific and common requirement. A chart that is drawn once and never updated is a chart that is wrong after the first minute, and the fix is to re-fetch the data and redraw without reloading the page. Doing that means being able to address a chart from your own JavaScript, and to receive events from it. So the library ships a module for that, and the reason it is in the list rather than in the documentation is that it changes what kind of application you can build with the library.

The remaining features are smaller and mostly about the framework rather than the charts. There are column formatters and roles, which is the mechanism behind the typed columns in the data table. There are template extensions for the templating engine of the leading PHP framework and for the one the Symfony ecosystem uses, which is how the single line in the view works. And there is support for the date library, so that date, date and time columns are formatted consistently with the rest of an application that uses it.

The whole list is what you would expect from a library that is really two things: a chart description language for PHP, and the plumbing to get a chart onto a page in three different framework styles.

The repository and the two testing systems

The repository layout is small and tells you what kind of project this is.

There is a source directory, a tests directory, a separate directory for the JavaScript, a composer manifest and a lock file, a configuration file for the test runner, a change log, a contributors file, and a licence. And there are four files that describe the continuous integration, and they are the interesting part: a file for one service, a file for another, a file for a code quality service, and a directory for the project specific workflows.

Two continuous integration systems from the era when the project was last active, plus a code quality configuration, plus a directory of workflows. That combination is a snapshot: a project that was set up with the tools available at the time and has been left running, and the readme's own note about being in a stable state is consistent with it.

The separate JavaScript directory is the more interesting structural fact. This is a library whose output is JavaScript, and it ships a client side module of its own, so the JavaScript is not an afterthought that the charting library happens to emit. It is maintained in the same repository, with its own directory, and the readme lists what it does.

The composer manifest is where the dependency story lives, and the two most recent releases name the changes: one updated the date library and the other moved to the second version of the dependency manager. The second of those is the significant one, because the second version of that tool changed how some plugins are loaded, and a library that ships a service provider and a set of template extensions has to be built to load correctly under both.

The test configuration is in the root, and the tests directory is separate, so the project follows the conventional layout for a PHP package with a PHPUnit suite.

And the number in the title of the readme is worth noticing, because it does not match the newest release. The readme says version 3.1.12 while the release history goes to 3.1.14. That is the kind of small inconsistency that tells you the readme has not been touched since 2019, and it is a fair summary of the project's state: stable, well documented for what it does, and no longer in active development.

Editorial conclusion

Lavacharts fits a PHP application that wants a chart in a view without hand writing the JavaScript, and that needs the whole option set of the underlying chart library rather than a smaller drawing library's subset. It does not fit a project that needs to own its rendering, because the output is a hosted chart library rather than a picture, and it does not fit a team that needs the new chart types the upstream library added after the version this one wraps. Verify first which chart types and options your pages need against the version of the upstream library this one targets, that the framework integration matches your version, since the readme documents four different Laravel registration procedures, and that the configuration file, including the maps key and the date formats, is published rather than left at the defaults.

Frequently asked questions

Official sources

1. Issues
2. kevinkhill/lavacharts on GitHub
3. Project website
4. README
5. Releases