- Does chumper/datatable work with Laravel 5 or newer?
- No. chumper/datatable is a Laravel 4-era package whose Composer constraints conflict with Illuminate 5 and above, and it assumes the Laravel 4 container and request lifecycle. The repository is archived and Laravel 4 has been end-of-life since 2015, so no compatibility work for newer frameworks will ever land. For any greenfield or actively upgraded codebase, the realistic path is to use yajra/laravel-datatables or reimplement the server-side mapping in-house.
- How do I install chumper/datatable?
- You install it with Composer inside a Laravel 4.x project and then register the package's service provider and Datatable facade in app/config/app.php, which is the standard Laravel 4 package workflow. Installation only succeeds on a PHP 5.4–5.6 runtime with a Laravel 4 dependency set, because the package's own constraints block PHP 7 and Illuminate 5+. If Composer refuses to resolve, that is the expected signal that your application is outside the package's only supported stack.
- What Laravel and PHP versions does chumper/datatable support?
- It targets exactly one stack: Laravel 4.x on PHP 5.4 through 5.6, paired with DataTables 1.x on the client. The package's Composer constraints will hard-block any framework or runtime upgrade until it is removed, which makes it a gate on your entire Laravel upgrade roadmap. Treat it as a legacy dependency to contain, not a capability to build on.
- Is chumper/datatable still maintained?
- No. The repository is archived, there is no active maintainer, and there is no path to a security patch or CVE response. Bug reports and compatibility work for newer PHP or DataTables releases will not be addressed. Any application still depending on it should have a named owner funding an exit.
- What is the best alternative to chumper/datatable for modern Laravel?
- yajra/laravel-datatables is the recommended target: it is actively maintained, supports modern Laravel and DataTables 2.x, and covers the same server-side processing use case with a comparable fluent API. If your team does not want another third-party dependency, the package is small enough to reimplement internally as a controller trait that maps DataTables request parameters onto the query builder. Either route removes the abandonment risk and unblocks framework upgrades.
- How does server-side processing work in chumper/datatable?
- The package acts as a thin adapter between Laravel's query builder and the legacy DataTables 1.x AJAX protocol, reading parameters such as sEcho, iDisplayStart, iDisplayLength, sSearch and iSortCol_0. You build a response from an Eloquent or Query Builder object using the Datatable::query(...)->addColumn(...)->make() chain in a controller. The package translates those request parameters into ORDER BY, LIMIT/OFFSET and search predicates and returns the JSON shape DataTables expects.
- Why does my DataTables table render blank after upgrading the JavaScript library?
- DataTables 2.x changed the server-side parameter contract substantially, so the legacy endpoint built by chumper/datatable no longer returns a response the client understands. The failure is a blank table rather than an exception, which is the worst kind of failure to detect in testing. If a front-end DataTables upgrade is queued, the server endpoint must be replaced at the same time, which in practice means migrating off this package.
- Can I use chumper/datatable with DataTables 2.x on the client?
- No. The package speaks the DataTables 1.x AJAX protocol and will not satisfy the parameter and response contract introduced in 2.x. Because the mismatch usually produces an empty table instead of an error, it can slip through review. Pin the front end to DataTables 1.x only as a short-term containment measure while you plan the migration.
- Are custom filter closures in chumper/datatable a security risk?
- Custom search and filter closures are the documented extension point, and they are the most likely place for unvalidated request input to reach the database. The common path uses the query builder rather than raw SQL, but closures bypass that safety net when they interpolate user input directly. Audit every controller and route that uses this package for custom closures, and validate or bind parameters explicitly.
- How hard is it to migrate from chumper/datatable to a maintained solution?
- The migration is mechanical because the Datatable::query(...)->addColumn(...)->make() chain maps closely onto the modern equivalents in yajra/laravel-datatables, so controller changes are localized. First inventory how many controllers and routes depend on the package, then move them one at a time behind the new implementation. For a small footprint, an in-house controller trait covering the same parameter mapping is only a few hundred lines and eliminates the dependency entirely.