Filament Fullcalendar Laravel Package

Product Decisions This Supports

• Build vs. buy for the calendar surface — now including interaction plumbing, still not scheduling. v5 collapses more of the "we'd have to build that ourselves" list: Filament-native styling and toolbars, first-class filters and tabs, Filament actions for create/view/edit/delete, PHP methods to navigate and control the calendar, and drag/resize that can persist start/end back to your model. What it still does not decide: recurrence, timezone correctness, capacity, conflict detection, notifications, or two-way sync.
• A new product decision it forces: does dragging an event write to the database? v5 lets you map start/end attributes and persist moves/resizes automatically, or require confirmation and route the user through the edit action to review dates first. That is a policy decision (immediate vs. reviewed reschedule, who may move what, what audit trail exists) — make it explicitly, per calendar, rather than inheriting the default.
• Per-entity cost is now near zero, which changes roadmap sequencing. Models can describe their own calendar appearance, one calendar can hold events backed by different models, and forms/infolists can be reused from Filament resources. A "calendar for X" is no longer a per-entity integration project. That makes "add schedule visibility for bookings, then shifts, then maintenance windows" a legitimate incremental roadmap rather than three separate builds — and makes a single unified operations calendar across heterogeneous entities feasible.
• Filters and tabs are first-class, so stop budgeting a bespoke filter UI. Filters built from Filament form fields (dropdown, modal, slide-over, above/below the calendar) and resource-style tabs with badges and query modification, with remembered state. Decide whether calendar filters become the standard admin filtering pattern or stay calendar-only.
• "Show a calendar alongside ours" is now a buy, not a build — narrowly. Read-only iCalendar feeds and Google Calendar can be displayed next to your events without importing them, with private iCal URLs fetched server-side. This covers holidays, a company-wide calendar, a partner schedule. It does not cover write-back, two-way sync, attendee invitations, or availability lookup.
• Upgrade cost is now a bounded task, not an open-ended risk. v5 ships a Rector-based script that mechanically rewrites v4 widgets and tests (handler signatures, record APIs, deprecated actions, getFormSchema(), test calls), with --dry-run and a manual-attention checklist. This materially de-risks the "adopt 5.x when it goes GA" option and the "stay on 4.x for now" option — both stay cheap.
• Explicitly not decided by this package: recurring-event logic (RRULE), multi-timezone correctness, resource capacity and double-booking prevention, invite/notification workflows, audit trails on schedule changes, and external calendar write-back. Budget these separately or descope consciously.

When to Consider This Package

Adopt when most of the following hold:

• Your admin surface is already Filament, and you have confirmed major-version alignment explicitly. The current line is 5.x and still in beta (5.0.0-beta4); the maintainer states no further breaking changes are planned and that stable should follow within roughly a week if no major issues surface — but beta3 shipped a regression that broke click/drag/resize on calendars without resource views, fixed only in beta4. Pinning the version is the mitigation, not a formality.
• The calendar is admin/back-office, not customer-facing. FullCalendar Scheduler (resource timelines) still requires a paid commercial license key; the new PHP resource API makes resources far easier to build but does not remove that vendor cost.
• Your event data is already modeled — and now, ideally, you're willing to let models carry their own calendar presentation rather than maintaining a parallel EventData mapping per entity.
• You want filters/tabs, headings, header actions and toolbar composition without custom JS, and you're prepared to standardize on the plugin's patterns for them.
• You can tolerate a single-maintainer, ~420-star, low-dependency-count package whose own release notes acknowledge a "less-than-ideal maintenance cycle." Treat it as a thin convenience wrapper you could fork or replace.
• Time-to-value matters more than long-term API stability, and you're willing to run a beta (or stay on the last stable 4.x-compatible release) until 5.0.0 goes GA.

Look elsewhere (or build in-house) when:

• You need production-grade recurrence, timezone handling, or conflict resolution — that logic belongs in your domain layer regardless; this package won't help.
• You need two-way external sync, availability lookup, or attendee invitation flows. Read-only ICS/Google display is in scope; everything bidirectional is not.
• The UI must be public/customer-facing with bespoke branding, accessibility guarantees, and mobile performance requirements. The v5 redesign narrows the visual gap to Filament, not the public-surface hardening gap.
• You're on a non-Filament stack (plain Laravel/Livewire/Inertia) — the value proposition is almost entirely the Filament integration; without it, use FullCalendar directly.
• You need the calendar to be a strictly read-only view and don't want to police write paths — the new drag-to-persist behavior has to be deliberately configured off or gated behind confirmation.
• Your org requires vendor SLAs, security review responses, or a funded maintainer — none of that is on offer here.
• Shipping on a beta is disqualifying for you — a UI layer that silently regresses event editing is a hard "no" in a regulated or revenue-critical admin tool.

How to Pitch It (Stakeholders)

For executives: "We can put a calendar that genuinely looks and behaves like the rest of our admin panel into production in days, not a month, using an MIT-licensed, widely-used open-source calendar with an existing Filament integration. The v5 release is a substantial step up, not just a compatibility bump: our models can describe how they appear on the calendar, one calendar can show bookings, shifts and maintenance windows side by side with the right permissions applied per record, we get Filament-style filters and tabs for free, and rescheduling by drag-and-drop can update the record — with an option to require confirmation first. We can also display read-only external calendars like public holidays or a company calendar without importing them. It is still a UI accelerator, not a scheduling platform: recurring events, timezone correctness, double-booking rules and notifications remain our work and should be estimated separately. Risk is bounded: the code is small and MIT, there's now an automated upgrade script, so if the maintainer stops shipping we take it in-house. Two caveats to flag: the current release line is a beta — the previous beta briefly broke event editing and was fixed only in the newest one — so we pin a version and avoid auto-updates; and resource/timeline views still require a paid FullCalendar Scheduler license. There is also a new decision we need to make deliberately: whether dragging an event writes to the database immediately or goes through a review step."

For engineering: "It's a Filament widget wrapping FullCalendar. Models can declare their own calendar presentation, multiple models can coexist in one calendar, and the plugin tracks the underlying record so policies, labels and actions resolve correctly; resource-backed forms and infolists can be reused instead of duplicated. CRUD is standard Filament actions — custom actions sit alongside, authorization goes through policies, and the calendar refreshes after a mutation. Filters are Filament form fields (dropdown/modal/slide-over/inline) and tabs behave like resource list tabs with badges and query modification; both can remember state. Drag/resize can persist to mapped start/end attributes, optionally gated behind a confirmation step that reopens the edit action; external items can be dragged in from outside the calendar, and resource calendars persist moves between resources. Resources now have a proper PHP API and can be refreshed independently of events. There are PHP methods for navigation and control (go-to-date, change view, scroll-to-time, change options, refresh events/resources) so we don't need Livewire workarounds. Read-only iCalendar and Google Calendar feeds can be mounted alongside our events; private iCal URLs are fetched server-side and never handed to the browser. On migration: v5 ships a Rector-based script (filament-fullcalendar-v5, supports --dry-run) that rewrites v4 widgets and tests; the documented install ordering requires --no-scripts on the Rector install because package discovery will otherwise try to boot v4 widgets. Three things to verify before we commit: Filament major-version compatibility, FullCalendar version alignment (v5 targets FullCalendar 7 theme modules), and whether we need Scheduler's paid license for resource timelines. Plan to pin the version, keep the beta out of anything customer-adjacent, and isolate our event-mapping and any persistence hooks so that swapping the adapter stays a contained change. Timezone, recurrence and conflict semantics remain ours — assume the widget performs no interpretation."