Filament Giphy Laravel Package

Product Decisions This Supports

• Build vs. buy for in-editor media: v1.0.1 confirms this package is a thin, low-maintenance wrapper rather than a media platform. That makes it a defensible "buy/borrow" decision when the requirement is "let authors drop a GIF into content" and not "run a media library." The scope is now stable enough to treat as a dependency rather than a project.
• Rich-content roadmap: the shipped-styles change (giphy.css, no dependency on the host's Tailwind build) removes a recurring integration tax. It lowers the cost of adopting the picker in a second panel, a second brand, or a customer-facing surface — a real input to whether GIF support ships broadly or stays admin-only.
• Brand and UX consistency: modal_icon / modal_icon_color plus the masonry preview grid turn the picker from "a third-party modal" into a themed surface. This supports decisions about white-labelling, multi-tenant panels, and whether third-party UI is acceptable in front of customers.
• Perceived quality of the authoring experience: the sharper default rendition (fixed_width) and fixed-body/scrolling-results layout are quality-of-life changes that measurably affect author satisfaction and support tickets. Useful ammunition for prioritising polish work that has no new capability attached.
• Attribution and content-policy posture: creator captions are no longer rendered, but creator attributes persist as data-giphy-*. That is a deliberate separation of display from provenance — it keeps the door open for later attribution UI, export, or audit without re-plumbing storage. Worth recording as an explicit product stance rather than an accident.
• Upgrade sequencing and release risk: this release changes a default, adds required config keys for anyone who published the config, and removes a visible element from the UI. That is enough to require a deliberate upgrade ticket and a changelog/announcement to authors — a roadmap input, not a routine composer update.

When to Consider This Package

Adopt when:

• You are on Filament and the need is specifically in-editor GIF insertion — not general asset management.
• You want no build-pipeline coupling. The move to shipped giphy.css means the picker no longer competes with your Tailwind config or constrains your design-system upgrades; this is the single biggest reason to prefer it over hand-rolling.
• You are comfortable with a third-party API as a runtime dependency (GIPHY key, rate limits, availability) and accept that GIF search results are externally governed content.
• Your team is small and the alternative is a bespoke picker that someone has to maintain across Filament upgrades.
• You need light theming, not deep customisation — an icon, a colour, a rendition size. Config keys and fluent setters cover this; anything beyond it does not.

Look elsewhere when:

• You need asset ownership and lifecycle — storage, CDN, deduplication, retention, rights metadata. This package stores a reference, not an asset.
• You need moderation, allow-lists, or content governance over what gets embedded. There is no evidence of filtering controls here.
• You are not on Filament, or your editor is not the Filament surface — the value proposition collapses.
• You require caption/text attribution rendered with the media as a compliance requirement. v1.0.1 explicitly removes the caption from both editor and rendered figure; attributes are stored but not displayed. If your policy needs visible attribution, this is now a gap you must close yourself.
• You need guaranteed API-level stability and cannot absorb small breaking changes. This is a v1 package still settling its config surface.

How to Pitch It (Stakeholders)

For executives: a small, contained capability — let people put GIFs into content they're already writing — delivered by a dependency we don't maintain. This release makes it cheaper to run (styling no longer entangled with our design system) and more presentable (themed modal, sharper previews), which means we can extend it to other panels or customer-facing surfaces without a design-system project. Cost is a third-party API key and a small upgrade task; risk is bounded to one UI surface.

For engineering: treat this as a low-risk, low-ceremony dependency with two things to action. First, upgrade deliberately: grid_rendition now defaults to fixed_width, and published configs need the modal_icon / modal_icon_color keys added — a stale published config will not pick up the sharper default. Second, note the behaviour change: creator captions are gone from the editor and the rendered figure, with attributes retained as data-giphy-*; if any test or snapshot asserts on caption output, it will fail. The upside is real: styles now ship in giphy.css and no longer depend on the host's Tailwind build, which removes a class of integration bugs and unblocks Tailwind upgrades. The picker layout is also fixed-body with scrolling results and aspect-ratio-preserving masonry, so it behaves predictably at any modal size.