Filament Slider Laravel Package

Getting Started

rupadana/filament-slider is a Filament plugin that gives you a database-backed slider (a Slider with ordered slider items) that content editors manage inside the panel, plus a Blade-level way to render those items on the frontend. The point is to stop hardcoding hero carousels in templates.

1. Install and publish

composer require rupadana/filament-slider

php artisan vendor:publish --tag="filament-slider-migrations"
php artisan vendor:publish --tag="filament-slider-config"

php artisan migrate

2. Satisfy the media dependency

The package leans on spatie/laravel-medialibrary for the slide images. If it isn't already installed, install it, publish its migration, and set FILESYSTEM_DISK / the medialibrary disk config to something real (usually public locally, S3 in production). A slider that "saves" but shows broken images is almost always a disk/storage:link problem, not a package bug.

3. Register the plugin

In your panel provider's panel() method, add the plugin to the plugins([...]) array, then confirm the SliderResource (and its items) appears in navigation. Check config/filament-slider.php at this point — it's the first place to look for model overrides, navigation grouping, and upload settings.

4. First use case

Have an editor create a slider with a code/identifier (e.g. home-hero), add 3 ordered items with images, titles, and links. Then render it in your homepage Blade view by looking the slider up by that code and looping its items — the code is the stable contract between CMS and template, so the marketing team can swap images without a deploy.

On 1.0.2 specifically: this release is maintenance only — a Dependabot bump of the Pint CI action and a composer.json update adding Laravel 12 support. There are no API changes, no schema changes, and no deprecations, so it's a drop-in upgrade from 1.0.1. The practical takeaway is that you can now include this package in a Laravel 12 / Filament 3 project without a composer.json conflict workaround.

Implementation Patterns

Code-keyed rendering. Treat the slider code like a named slot in your design system. One Blade partial, called from wherever the slot appears:

@php($slider = \Rupadana\FilamentSlider\Models\Slider::where('code', 'home-hero')->first())

@if ($slider)
    <div class="swiper">
        <div class="swiper-wrapper">
            @foreach ($slider->items as $item)
                <div class="swiper-slide">
                    <img src="{{ $item->getFirstMediaUrl('image') }}" alt="{{ $item->title }}">
                    @if ($item->link)
                        <a href="{{ $item->link }}">{{ $item->title }}</a>
                    @endif
                </div>
            @endforeach
        </div>
    </div>
@endif

Always null-check the slider — editors will delete one, and a 500 on the homepage is a bad day.

Wrap it in a view component or a small service class. Rather than scattering model queries through views, expose a SliderPresenter or a <x-hero-slider code="home-hero" /> component that handles lookup, caching, and eager loading in one place. That's also where you'll add ->with('media') to kill the N+1 on images.

Cache aggressively, invalidate on save. Sliders are read on every page view and written maybe weekly. Cache the resolved items array for an hour (or forever) keyed by code, and flush it from a model observer on the Slider/slider-item saved and deleted events. Do not cache the HTML with user-specific markup inside it.

Seed for local and CI. Because the frontend silently renders nothing when a slider is missing, add a seeder that creates your known codes with placeholder images. Otherwise every fresh clone and every CI screenshot test has an empty homepage and no one notices the regression.

Multiple placements, one resource. Point several codes at different parts of the site (home-hero, product-banner, checkout-promo) rather than duplicating resources. Editors learn one screen; your templates stay declarative. If you need locale-specific sliders, prefer suffixed codes (home-hero.de) over schema changes.

Pair with a JS carousel you already run. The package owns the data, not the presentation. Swiper, Splide, or a hand-rolled Alpine component all work; initialize after DOM ready and destroy/re-init on Livewire navigation (livewire:navigated) if you use SPA mode.

Testing. Use RefreshDatabase, create a slider and items in a factory, and assert on the rendered output for a given code. For media, use medialibrary's fake/storage fakes so tests don't touch a real disk.

Gotchas and Tips

• Ordering must be applied at read time. Drag-and-drop ordering in the admin only helps if your frontend query sorts by the order column. Verify this explicitly with items created out of sequence — this is the single most common "the plugin is broken" report.
• Eager load media. getFirstMediaUrl() on a collection without eager loading fires a query per item. ->with('media') on the items relation is a one-line fix for a measurable TTFB difference.
• Image conversions need regenerating. If you change dimensions or conversion names after editors have uploaded, run php artisan media-library:regenerate. Old conversions linger and silently keep serving the wrong size.
• Orphaned media on delete. Deleting a slider or item may leave files and media rows behind depending on your model configuration. Schedule php artisan media-library:clean and verify the deletion path once in staging rather than assuming cleanup happens.
• Publish, don't edit vendor. Views, migrations, and config are all publishable. Override the published copies; a composer update will otherwise wipe your edits.
• Config-driven model swapping is the extension point. If you need extra fields on a slide, the sanctioned route is a subclass wired up via the package config (plus your own migration), not a fork. Confirm the config keys after publishing — the file is short and worth reading end to end once.
• Don't publish migrations twice. A re-publish can drop a duplicate migration into database/migrations and produce a confusing "table already exists" failure on fresh installs.
• 1.0.x is young. Minor releases have historically carried compatibility fixes (1.0.2 is exactly that). Pin to ^1.0 but read the changelog before composer update on production, and run your slider rendering tests — a green suite is your real upgrade check.
• Laravel 12 users: 1.0.2 removes the constraint friction, but verify your medialibrary and Filament majors also support Laravel 12 before upgrading the framework — that's where the real incompatibility will surface, not in this package.
• Debugging empty output: check in this order — is the slider record present with the exact code, are items attached and ordered, is storage:link in place, is the disk public-readable, does getFirstMediaUrl() return a non-empty string in tinker. That sequence resolves nearly every report.