Laravel Pagination Bulma Laravel Package

Getting Started

1. Install the package (pin the new 1.0.0 line)

   composer require revolution/laravel-pagination-bulma:^1.0
   

   1.0.0 is the first properly tagged Composer release — the release note ("Made as composer package") describes a distribution change, not a template change. Expect the same Bulma classes as the untagged/vendored copies people were previously copying by hand, but treat 1.0.0 as the diff baseline from now on. On Laravel 5.5+ the service provider is auto-discovered and registers the Blade view namespace plus sets Paginator::defaultView() to the Bulma template. On older Laravel, add the provider to config/app.php.

2. Confirm Bulma is loaded. The template only emits Bulma classes (pagination, pagination-previous, pagination-next, pagination-list, pagination-link, is-current). It ships no CSS. Pull Bulma in via CDN, npm i bulma, or your SASS build before you evaluate the output.

3. First use case — render a paginated query with the package template:

   $users = User::paginate(15);
   

   {{ $users->links() }}
   

   Because the provider swaps the default view, ->links() should already render the Bulma markup. If it does not, the view namespace wasn't registered — publish the views and reference them explicitly (see below).

4. Where to look first

   • vendor/revolution/laravel-pagination-bulma/resources/views/ — the actual Blade template(s). Diff this against whatever you had before the upgrade; the 1.0.0 notes don't enumerate changes.
   • vendor/revolution/laravel-pagination-bulma/composer.json — the release note says nothing about Laravel support, so this file is your only source of truth for illuminate/* constraints. Read it before you assume 1.0.0 works on Laravel 10/11.
   • The service provider's boot() method — that's where Paginator::defaultView()/defaultSimpleView() are wired.
   • The repo's tags/CHANGELOG (if any) — 1.0.0 is the only reference point you have for "before" vs "after".

Implementation Patterns

Global default (recommended for a single-app stack) Publish the view and point Laravel at your copy so you own future tweaks:

php artisan vendor:publish --tag=views   # adjust tag to the package's published tag

Then in AppServiceProvider::boot():

use Illuminate\Pagination\Paginator;

public function boot(): void
{
    Paginator::defaultView('vendor.pagination.bulma');
    Paginator::defaultSimpleView('vendor.pagination.bulma-simple');
}

This is safer than depending on the package's service provider because you control the view path and can evolve it after the package is abandoned. It also makes the 1.0.0 upgrade a no-op for markup: your published view still wins over the package's.

Upgrading an existing install to 1.0.0 Because publishing shadows the package view, an upgrade will not change your rendered output. If you want whatever markup fixes 1.0.0 carries (if any), diff explicitly:

diff -ru vendor/revolution/laravel-pagination-bulma/resources/views \
        resources/views/vendor/pagination

Then port changes by hand. Don't re-publish over a customized file.

Per-call override (preferred when mixing UI kits) If only one section of the app uses Bulma, don't hijack the global default:

{{ $posts->links('vendor.pagination.bulma') }}

Wrap it in a Blade component to keep call sites clean:

{{-- resources/views/components/bulma-links.blade.php --}}
@props(['paginator'])
{!! $paginator->links('vendor.pagination.bulma') !!}

Simple paginators simplePaginate() uses Paginator::defaultSimpleView(), not defaultView(). If the package only ships one template, publish/extend it and register the simple variant yourself, otherwise simplePaginate() will fall back to Laravel's stock template and look inconsistent.

Multiple paginators on one page Give each collection a distinct page name so the ?page= query string doesn't collide:

$posts    = Post::paginate(10, ['*'], 'posts_page');
$comments = Comment::paginate(10, ['*'], 'comments_page');

{{ $posts->links('vendor.pagination.bulma') }}
{{ $comments->links('vendor.pagination.bulma') }}

Appending query state Bulma links are just anchors; preserve filters explicitly:

$results = Product::filtered($request)->paginate(24)->appends($request->query());

Livewire / Inertia integration

• Livewire 2.x/3.x uses its own pagination view registry (Livewire::usePaginationView()), so Paginator::defaultView() will not affect $this->links(). Set the view explicitly on the component or globally via Livewire::usePaginationView('vendor.pagination.bulma-livewire') (you'll need a livewire-flavored copy that emits wire:click).
• Inertia: skip the package. Send the paginator's links() array as JSON and render Bulma <nav> markup in Vue/React; the Blade template is only useful server-rendered.

Theming / variants Bulma supports is-centered, is-right, is-rounded, is-small, is-large. Publish the view once and add a small variant view per size/alignment rather than mutating the shared template with conditionals.

Gotchas and Tips

• A "1.0.0 — made as composer package" release is a packaging event, not a feature release. Don't expect new options, config files, or view components. Verify what actually shipped by diffing vendor/.../resources/views and reading composer.json; the release note gives you nothing about behaviour.
• No stylesheet included. If the markup emits pagination-list and pagination-link but nothing is styled, Bulma CSS simply isn't loaded. This is the #1 "it doesn't work" report.
• Stale Laravel constraints are still the most likely blocker. 1.0.0 doesn't advertise a Laravel support matrix. The composer.json may still pin illuminate/support to ^5.5|^6|^7. On Laravel 8+ you may need composer require revolution/laravel-pagination-bulma -W or a fork. The Blade file itself is usually fine on 8–11 because pagination views are just templates — only the composer constraint is the blocker.
• Version pinning. Prefer ^1.0 over a floating dev-*/branch constraint. Now that a tag exists, the tag is the only reproducible coordinate you have; a branch can move under you silently.
• Provider ordering matters. If any later provider calls Paginator::useBootstrap() or Paginator::useTailwind() (Laravel 8/9+), it silently overwrites this package's default view. Set the default in your own AppServiceProvider::boot() after those calls, or use the per-call ->links('…') form to sidestep ordering entirely.
• Laravel 9+/11 defaults. Newer skeletons ship Tailwind pagination views by default and deprecate some helpers. Don't assume defaultView() in the package wins — verify with {{ $users->links() }} output.
• onEachSide() is newer. It was added in Laravel 8.4. On older Laravel the page window is fixed; you'll have to fork the template to change it.
• Disabled state on first/last page. Bulma expects the previous/next anchor to be swapped for a pagination-previous span or given disabled when onFirstPage()/onLastPage(). Check the published template if the buttons remain clickable on page 1 / last page.
• Accessibility. Bulma docs recommend role="navigation" and aria-label="pagination" on <nav>, plus aria-current="page" on the active link. Old templates may omit these — patch after publishing.
• Debugging empty/plain output. php artisan view:clear after publishing and after upgrading to 1.0.0 (the package view namespace may now resolve differently). If links() renders nothing, confirm the view path/namespace (e.g. revolution-pagination-bulma::bulma vs vendor.pagination.bulma) by testing $users->links('vendor.pagination.bulma') directly.
• Publishing vs consuming. Once you publish, the package's future updates never reach your app. Given the package is essentially unmaintained, treat publishing as a one-time fork: copy the Blade file, then drop the composer dependency and register the view directly. 1.0.0 is a sensible final tag to fork from.
• Bootstrap/Tailwind already wired? If you're migrating a project that already calls Paginator::useBootstrap(), keep both: leave Bootstrap global and only use the Bulma view for the specific Bulma-served sections via ->links('vendor.pagination.bulma').
• Extension points. The only real extension surface is the Blade template and the two defaults (defaultView, defaultSimpleView). There is no config file worth maintaining — don't invent one; just own the view. 1.0.0 adds nothing here.