Filament Sticky Header Laravel Package

Product Decisions This Supports

• Feature triage / polish backlog. This is a UX-polish ticket, not an initiative. It answers "do we improve scan-and-act on long admin pages?" — a real but small question. Size it in hours, not sprints: composer require, a CSS import in your theme, one plugin registration line.
• Build vs. buy. Buy. The functional surface is a small amount of CSS plus a JS intersection observer; replicating it in-house is possible but pointless. MIT license, single-line enablement, removable in one commit — effectively zero lock-in.
• Where to apply it (scoping decision). The package's own options define the product decision surface: stick everywhere by default, then carve out exceptions with stickOnListPages(false) for dense tables and disabledOn([...]) for custom pages where the header isn't an action bar. Decide per surface, not globally.
• Whether to expose a user preference. floating() and colored() accept closures, which makes per-user theming technically trivial — but you then own the preference column, the settings UI, and its support load. Recommendation: ship a single house style now; treat per-user toggles as a separate, demand-driven request. Don't let a cosmetic plugin expand your settings surface.
• Sequencing against theme work. Adoption is coupled to already having a custom Filament theme. If you don't, this ticket silently drags in a front-end build step (Vite/Tailwind, CI assets) — a much larger decision than the plugin itself. Gate the ticket on that prerequisite being true.
• Roadmap durability. The release history is almost entirely CSS regression fixes (notification overlays, filter icon z-index, nav toggle, page-render flash). Plan for a recurring small maintenance line item after each Filament upgrade rather than treating this as install-and-forget.

When to Consider This Package

Consider it when:

• You're on Filament 4.x or 5.x (4.x line) or 3.x (2.x line) and your admin has genuinely long pages — edit forms with many fieldsets, record-heavy list pages, custom reporting pages — where the primary action scrolls out of reach.
• You already maintain a custom theme and can add one @import to your CSS entrypoint.
• Your users are desktop-first and mostly doing repeated data entry or review; keeping "Save" and page actions pinned measurably reduces micro-scroll and mis-clicks.
• Your risk bar is low-stakes: MIT, no data access, no migrations, no service dependencies. Worst case is a visual bug and a composer remove.

Look elsewhere (or just skip it) when:

• You have no custom theme and don't want one — the install cost outweighs the benefit.
• Mobile is a primary surface. A sticky header permanently consumes viewport height on small screens, and the README documents no mobile behavior or opt-out. Verify before committing.
• Your header is already crowded (global search, notifications, tenant switcher) or you run other plugins that touch the header — the changelog is a catalogue of exactly these z-index/overlay conflicts.
• You need support guarantees, test coverage, or broad adoption signals. At 83 stars and 0 dependents this is a well-made snippet, not an ecosystem dependency. Only adopt if you're comfortable reading the CSS and patching or forking it yourself.
• You're already deep in custom panel CSS — position: sticky on the header may be a smaller diff than a new dependency.

How to Pitch It (Stakeholders)

To executives: A low-cost UX improvement for our admin panel. It pins page titles and action buttons to the top of the screen on long pages, so staff don't lose the Save button while scrolling. MIT-licensed, installs with one line, touches no data, no security surface, no vendor contract, and is reversible in a single commit. Don't fund it as a project — fold it into an existing polish pass. Success is soft (fewer "where's the save button" tickets, better task completion on long forms), so treat it as polish, not a bet.

To engineering: Add awcodes/filament-sticky-header via Composer, import vendor/awcodes/filament-sticky-header/resources/css/plugin.css into our theme, and register StickyHeaderPlugin::make() in the panel provider. Scope it deliberately: stickOnListPages(false) for dense tables, disabledOn([...]) for pages without an action bar. Test sticky behavior against notifications, table filters, and the mobile menu toggle before shipping — the upstream changelog shows these are the recurring break points. It tracks Filament majors (1.x→4.x), so pin the version and budget a small CSS regression check after each Filament upgrade.