widicorp/metronic-datatable-bundle
Laravel bundle that integrates Metronic admin theme DataTables into your apps, with server-side processing, AJAX loading, column configuration, filters, and responsive data grids for fast, clean admin tables.
This is a Symfony bundle, not a Laravel package, so the first thing to do is honestly assess whether you can adopt it at all. It targets Symfony's bundle system and almost certainly depends on sg/datatables-bundle (or a similar Symfony DataTables core) plus the proprietary Metronic theme assets. In a Laravel project you would be pulling in Symfony plumbing that has no place in a Laravel app — treat this as reference material rather than a drop-in dependency unless you are actually working in Symfony.
If you are on Symfony:
composer require widicorp/metronic-datatable-bundleconfig/bundles.php (Widicorp\MetronicDataTableBundle\MetronicDataTableBundle::class => ['all' => true]).config/routes.yaml (metronic_datatable: { resource: '@MetronicDataTableBundle/Resources/config/routing.yaml' }).config/packages/ (look for metronic_data_table.yaml) to point at your Metronic asset directory.First use case: an admin list view (users, orders, products) that renders as a Metronic-styled server-side DataTable. Open the bundle's DependencyInjection/Configuration.php first — with no stars and no docs, that file is the only reliable contract you have. Then look at Datatable/ and Resources/views/ to see the concrete classes and Twig blocks you are meant to extend.
Server-side controller pattern. The typical flow is a controller action that builds a DataTable definition (from the bundle's base class or a factory), returns the AJAX JSON for the table's data endpoint, and separately returns a Twig template that renders an empty <table> with the right data-* attributes. Keep the data endpoint and the render action as two distinct routes; do not try to hydrate rows on initial page load.
Datatable class per entity. Define one class per table (e.g. OrderDatatable extends BaseDatatable), declare columns (name, field, sortable, searchable, render callback), and let the bundle handle the query. This mirrors the Symfony sg/datatables-bundle convention, so any existing Symfony DataTables knowledge transfers directly.
Twig rendering. Use the bundle's Twig helper/block to render the table with Metronic classes (table table-striped table-row-bordered gy-5 etc.). Wrap the table in Metronic's card markup (card, card-header, card-body) so pagination, search, and toolbar controls sit in the correct theme slots.
Column formatting on the server. Compute display values (status badges, action buttons, formatted dates) in the datatable class rather than in JS. Metronic's badge classes (badge badge-light-success) and dropdown action menus are easiest to emit as raw HTML from the server and whitelist in the client-side render config.
Filters via query params. Wire Metronic's filter form to the DataTable by reading filter values from the request in your datatable class and applying them to the query builder. Use the AJAX data callback on the JS side to merge the form values into every draw.
Composition over inheritance. If the bundle's base class is thin, prefer small traits or services for common column sets (created/updated timestamps, actions column) instead of deep inheritance chains — you will outgrow the bundled base class quickly.
It is not a Laravel package. Installing it in Laravel means dragging in Symfony's DI container wiring, Twig, and likely sg/datatables-bundle. If you want the same result in Laravel, reproduce the ~20 lines of config that make DataTables work (route + JSON response + a blade partial with Metronic classes) rather than adapting this bundle. The Metronic classes are just CSS — they are the real value here, not the bundle.
Metronic assets are licensed and not in the repo. The bundle almost certainly assumes you already have the Metronic theme files. Without them you get an unstyled table and 404s on CSS/JS. Confirm asset paths in the published/Resources/public directory and check whether the bundle expects public/bundles/... (run assets:install).
No documentation and no stars. Read composer.json for the exact Symfony and sg/datatables-bundle versions it expects. A mismatch there will surface as a confusing container-compile error, not a normal exception. Run debug:container --tag=... and debug:router right after install to confirm the bundle actually wired anything.
AJAX debugging. DataTables failures are usually silent. Open devtools, inspect the Network tab for the data endpoint, and check the raw JSON — a 500 with an HTML trace is the most common "empty table" cause. Add server-side logging in your datatable class's query method to confirm filters are applied before the query is built.
Search and pagination are client/server split. Metronic's JS initializes the table; the bundle supplies the data endpoint. If search or pagination does nothing, the JS init is either missing (asset not loaded) or the server is ignoring start/length/search[value]. Check the bundle's JS init snippet first, then the query builder.
Column rendering XSS. Emitting raw HTML for badges/buttons is the Metronic-idiomatic thing to do, but whitelist fields and escape user-supplied text (escape on name, email) before concatenating.
Extension points. Look for DataTableInterface, abstract base classes, and Twig blocks before forking. If the bundle is abandoned (likely given the metrics), plan to copy its handful of useful files into src/ and drop the vendor dependency — you will spend less time that way.
How can I help you explore Laravel packages today?