Filament Plausible Page Laravel Package

Product Decisions This Supports

• Roadmap alignment with Filament upgrades. This release adds Filament v4 and v5 support, which removes the plugin as a blocker if our admin panel roadmap includes a Filament major-version upgrade. That is the single most consequential line in the changelog — it converts a potential "replace or fork this plugin" workstream into a routine composer update.
• Build vs. buy. An embedded Plausible Analytics page in the admin panel is a small, well-bounded surface. This package lets us ship it as configuration rather than custom code, keeping engineering effort on differentiating features.
• Feature scope for internal analytics. Supports "give operators/editors a privacy-friendly traffic view without leaving the admin panel" — a common, low-cost retention and self-service win for content and marketing-adjacent teams.
• Vendor-risk posture. A maintained package tracking current Filament majors is a materially different dependency than one pinned to a single legacy version. This release improves the maintenance signal (active maintainer, Dependabot hygiene, recent compatibility work).
• Upgrade sequencing. Confirms the plugin no longer constrains the timing of a Filament v4/v5 migration; it can be scheduled on engineering's terms rather than the vendor's.

When to Consider This Package

Adopt when:

• We are on (or planning) Filament v4 or v5 and want Plausible stats surfaced in-panel without building a custom page.
• The need is genuinely a read-only embedded dashboard — not programmatic analytics, cohort analysis, or data warehousing.
• Plausible is already, or will be, our analytics vendor; the package is a thin view layer, not an abstraction over providers.
• Two-factor/self-hosted Plausible configuration is supported by the underlying API — validate against our instance before committing.

Look elsewhere (or build) when:

• We need Plausible data inside application logic (alerts, automated reporting, joins with product data) — call the Plausible Stats API directly; a UI plugin is the wrong layer.
• We are staying on Filament v3 long-term: confirm explicitly whether v3 remains supported in this release before upgrading, since added v4/v5 support does not guarantee v3 was retained.
• We require SSO-scoped, per-tenant analytics views or fine-grained row-level access — expect to build this ourselves.
• We are multi-vendor on analytics or expect to swap providers; a single-vendor plugin creates a small but real coupling.

Verification items before adoption: confirm v3 retention (if relevant), check the package's test matrix actually exercises v4/v5, and confirm the maintainer is responsive on security issues — the release notes show automation bumps but only one substantive PR.

How to Pitch It (Stakeholders)

To executives: A small, low-risk dependency that puts privacy-friendly traffic analytics directly inside our admin panel. The v2.3.0 release is primarily a compatibility release — it adds support for the current and next major versions of Filament, the framework our admin UI is built on. Net effect: we keep a useful operator-facing feature at near-zero maintenance cost, and it no longer stands in the way of a future admin-panel upgrade.

To engineering: v2.3.0 adds Filament v4 and v5 support (PR #12); the remaining changes are Dependabot bumps to CI tooling (Pint action, fetch-metadata) with no runtime impact. No deprecations or breaking changes are announced. Action: verify whether Filament v3 support is retained before bumping, confirm the CI matrix covers v4/v5, and treat this as an enabler for the Filament upgrade rather than a feature release. Recommend pinning to ^2.3 and re-evaluating if the plugin falls behind a future Filament major.