- Is symfony/ux-pagination a Laravel package?
- No. Despite the PHP framing, symfony/ux-pagination is a Symfony UX package that depends on Symfony components such as OptionsResolver, HttpFoundation, and Twig Bridge, and its rendering tier assumes Twig rather than Blade. Laravel already ships a native paginator with Blade views and Eloquent/query-builder integration, so adopting this package in a pure Laravel app means running two pagination paradigms for no product benefit. It is a strong fit for Symfony services and a poor fit for Laravel ones.
- How do I install symfony/ux-pagination?
- Run composer require symfony/ux-pagination, then register the bundle in config/bundles.php if your app does not use Symfony Flex auto-registration. You also need the Twig component and asset pipeline set up if you intend to use the rendered pagination controls. Check the README install instructions for the current asset/importmap wording, since that guidance has changed recently.
- Does symfony/ux-pagination support both cursor and numbered pagination?
- Yes. The package provides a Pager abstraction with adapters for Doctrine ORM, Doctrine DBAL, and Pagerfanta, and it supports both cursor-based and numbered page styles. Cursor pagination is the better choice for large or frequently changing result sets, while numbered pages suit classic search results and admin lists. The rendering tier exposes the same pager to Twig regardless of style.
- Can I use symfony/ux-pagination in Laravel with Blade?
- Practically no. You could use the PHP Pager classes headless and write your own Blade renderer, but that discards the package's main value, which is the Twig and Symfony UX rendering tier. You would still pull in Symfony dependencies and maintain a second pagination paradigm alongside Laravel's native paginator. For a Laravel app, use the built-in paginator and close the evaluation.
- Which Symfony and PHP versions does symfony/ux-pagination v3.6 require?
- The package tracks the supported Symfony release matrix, so verify your installed Symfony and PHP versions against composer.json before upgrading rather than assuming. The Symfony UX packages generally require a current PHP 8.x runtime and a maintained Symfony branch. Also confirm that the Twig component version and the JS/CSS assets in the assets directory are upgraded together, since asset and PHP version skew is the most common failure mode with UX packages.
- How do I render pagination controls in Twig with symfony/ux-pagination?
- Inject or build the Pager in your controller and pass it to the template, then render the Pagination Twig component, for example a twig:Pagination tag with the pager attribute. The component outputs markup friendly to Stimulus and Turbo, which is why the JS/CSS assets need to be installed alongside the PHP package. If you use importmap or Webpack Encore, confirm the controller was registered by your asset build.
- What changed in symfony/ux-pagination v3.6.0 that could break my app?
- Two changelog items need verification rather than acceptance. A cursor pagination fix for DATETIMETZ_MUTABLE columns (#3903) is a correctness fix, meaning current output on timezone-aware datetime columns is wrong today and different after upgrade, so page boundaries may shift. Removal of the deprecated defaultPriorityMethod from the adapter iterator (#4079) is labelled a bug fix but removes a method, so grep your codebase for subclasses or calls before upgrading.
- How do I test pagination page boundaries after the timezone datetime fix?
- Write a regression test that paginates over a DATETIMETZ_MUTABLE or DATETIMETZ_IMMUTABLE column with realistic data volumes and asserts stable ordering across page seams. Check for rows appearing twice or disappearing between the last item of one page and the first of the next. This kind of defect is silent and date-dependent, so it will not surface without a dedicated boundary test.
- Is upgrading from symfony/ux-pagination 3.5 to 3.6 a breaking change?
- No migration is required for existing 3.5.x users; you can move the constraint from ^3.5 to ^3.6 as a routine dependency bump. Treat the minor-version label as probably non-breaking rather than guaranteed, given the adapter iterator method removal. If the package is net-new to your project, the real work is replacing an existing paginator, which is a feature-sized effort and should be planned as such.
- What are the alternatives to symfony/ux-pagination?
- Within Symfony, standalone Pagerfanta and KnpPaginatorBundle are the common alternatives, and they can be used without the Twig component layer if you want full control over markup. For Laravel applications the correct alternative is the framework's native paginator, which already integrates with Eloquent and the query builder. Choose symfony/ux-pagination when you want the Symfony UX rendering tier and Doctrine adapters in a Symfony codebase.