- Is samson/data-grid-bundle compatible with Laravel?
- No. samson/data-grid-bundle is a Symfony2 bundle (SamsonIT\DataGridBundle) that integrates through Symfony's Bundle class, DI container, and Twig templating, none of which Laravel's service-provider model consumes. There is no Laravel ServiceProvider, no config file to publish, and no Blade or Vite integration. Treat it as a source of ideas to port, not a package to install.
- Can I install samson/data-grid-bundle with Composer in a Laravel project?
- Composer installation is technically possible but pulls Symfony 2.x-era constraints for framework-bundle, twig-bundle, and http-kernel that conflict with modern laravel/framework. The dependency solver will almost certainly fail. Forcing it with --ignore-platform-reqs or version aliasing produces an unmaintainable install with no upgrade path. Do not add it to composer.json for a Laravel app.
- What does samson/data-grid-bundle actually do?
- It builds configurable data grids with sorting, filtering, pagination, and custom columns for admin panels, dashboards, and reports. Server-side it is a thin data provider that queries and serializes results to JSON; the client-side grid is rendered with AngularJS 1.x. It was designed for Symfony2 applications presenting Doctrine entities and similar data sources.
- Why is the AngularJS frontend a problem for a Laravel app?
- AngularJS 1.x reached end of life on December 31, 2021, so it receives no security patches, and it carries documented XSS and CSP-bypass issues. A Laravel frontend built on Blade, Vite, and Livewire or Inertia has no natural seam for it. Introducing AngularJS in 2025 adds an unsupported dependency that a security review will flag.
- Does samson/data-grid-bundle support PHP 8 and current Laravel versions?
- No. The last release was 2015-03-03, roughly a decade stale, with no PHP 8.x compatibility work and no PSR-4 or autoload modernization guarantees. Its Symfony 2.x constraints already conflict with any modern laravel/framework. There are no security patches and no active maintainer.
- Is samson/data-grid-bundle maintained or safe for production?
- It is effectively abandoned: 5 GitHub stars, 0 dependents, and no releases since 2015. That means no reference implementations, no Stack Overflow corpus, and nobody to ask when it breaks. Combined with the EOL AngularJS dependency, it fails most Composer audit and SCA policies. Adopting it in production carries high technical risk.
- What are the best Laravel alternatives to samson/data-grid-bundle?
- For server-driven tables, use Filament Table or a Livewire table component; both give sorting, filtering, pagination, and custom columns with minimal JavaScript. For an SPA-style frontend, use Inertia with a current Vue or React table library. A maintained DataTables adapter is also an option if you need a mature client-side grid.
- How do I migrate from samson/data-grid-bundle to Laravel?
- Start with a one-to-two-day spike: clone the repo, read the grid configuration and JSON serialization logic, and document the data contract plus any non-obvious query features such as per-column filters, joins, or aggregates. Then port the contract into a Laravel controller or API Resource with a typed column definition class instead of installing the bundle. Rebuild the view with Livewire or Filament, and verify parity with feature tests before deleting the old endpoint.
- Can I reuse the JSON contract or query-building logic from the bundle in Laravel?
- Yes, but only by extracting it. The portable parts are the JSON response shape and the query-building conventions; the Symfony delivery mechanism, Twig templates, and AngularJS client are not portable. Reimplement the endpoint as a Laravel Resource or controller and the grid as a Blade or Livewire component. This is a rewrite, not an integration.
- Does samson/data-grid-bundle work with Doctrine entities, and can Eloquent replace it?
- Yes, it was built to present Doctrine entities and other data sources in Symfony2 admin panels. In Laravel you would replace Doctrine with Eloquent query builder calls and API Resources, keeping the same column configuration idea. The behavior is reproducible in a modern stack in days.