- Does gloomy/pager-bundle work with Laravel?
- No. gloomy/pager-bundle is a Symfony bundle: it expects Symfony bundle registration, the Symfony DI container, symfony/http-foundation Request objects, and Twig for rendering. There is no service provider, container binding, Blade helper, or Illuminate\Http\Request shim, so it will not drop into a Laravel application as-is. Treat it as a design reference rather than a dependency.
- How do I install gloomy/pager-bundle?
- It is installed with Composer, but as a Symfony bundle it also has to be registered in your Symfony kernel or bundles.php and configured through the Symfony container. Laravel package auto-discovery will not wire it up, and no Laravel service provider is shipped. Before installing, confirm the package's PHP and Symfony version constraints match your runtime.
- Can I use gloomy/pager-bundle with Eloquent or Laravel's query builder?
- Not directly. The package ships adapters for plain PHP arrays and for Doctrine entities and QueryBuilder instances; there is no Illuminate\Database\Eloquent\Builder or Collection adapter. You would have to write that adapter yourself, mapping the package's paginate, sort, and filter contract onto Eloquent. Most teams find reimplementing the contract against Eloquent cheaper than maintaining a bridge.
- What data sources does gloomy/pager-bundle support?
- Two: a plain PHP array and a Doctrine Entity/QueryBuilder. That duality is the package's most transferable idea, because the same criteria drive in-memory fixtures in tests and live database queries in production. In Laravel the analogues are Illuminate\Support\Collection and Eloquent Builder, and that second mapping does not exist in the package.
- Is gloomy/pager-bundle safe to use in production?
- Be cautious. It has roughly ten stars, zero dependents, and no observable production footprint, so there is no downstream user base surfacing bugs and no release cadence to rely on. There is also no stated disclosure process for a component whose job is turning user input into query criteria. Confirm the last commit date, version support, and test coverage before depending on it.
- Does gloomy/pager-bundle validate user input used in queries?
- The documentation does not describe a validation or allowlist policy, so you must read the filter-criteria code yourself. The key question is whether filter names map to columns through a strict allowlist or whether raw request input reaches the query builder. If it is the latter, do not expose it to untrusted input.
- What are the best alternatives to gloomy/pager-bundle in Laravel?
- For most Laravel list screens, spatie/laravel-query-builder plus Laravel's native pagination (LengthAwarePaginator, paginate(), and Blade or JSON links) covers the same ground on a maintained stack. That combination handles filtering, sorting, and pagination straight from request query strings without a Symfony dependency. Check it against your requirement before scoping any extraction work.
- Which PHP and Symfony versions does gloomy/pager-bundle support?
- Compatibility is unverified in the available material, and a Symfony bundle of this vintage may not support current LTS lines. Check the PHP constraint and the Symfony/Doctrine constraints in composer.json for the latest release, along with the date of the last commit. Do this before scoping a fork, because it can invalidate the extraction entirely.
- How do I render pagination links with gloomy/pager-bundle?
- The bundle provides template helpers aimed at Twig, which do not transfer to Laravel. In a Laravel application you would re-express the pager output in Blade, Livewire, or preferably as JSON state that a frontend renders. Keep the pager object purely as backend state and discard its view layer.
- Should I fork gloomy/pager-bundle or reimplement its pagination logic?
- Reimplementing the contract against Eloquent is the lowest long-term risk and leaves you with code your team wrote and understands. Forking preserves the design intent but inherits unfamiliar Symfony-idiom code you will read once and maintain indefinitely. Fork only if the array-source adapter is the specific blocker, such as federated search, cached result sets, or third-party API aggregation.