Cms Laravel Laravel Package

Product Decisions This Supports

• Events & calendar feature build-vs-buy: The v32.0.0 Events Content module (events, sessions, speakers, venues, calendars, registration references, archives, structured data) turns a “build an events section” initiative into a configuration and content-modeling decision. This is the single biggest lever in the release: it can eliminate a multi-sprint custom build for marketing, community, conference, or training-site roadmaps.
• Roadmap sequencing: If an events/conference calendar sits anywhere in the next 2–4 quarters, this release moves it from “custom engineering project” to “adopt and theme.” It also unlocks adjacent roadmap items — speaker directories, session catalogs, past-event archives — without separate scoping.
• Channel and surface strategy: Because the feature ships with matching API, Filament, and Livewire packages, one content decision propagates to a headless API for web/mobile/partners, an admin UI for editors, and a server-rendered frontend. This supports decisions about whether to go headless, keep a monolith frontend, or both.
• SEO and discoverability investment: Structured-data support is included out of the box, which supports decisions to compete on event search visibility (rich results, event listings) rather than treating SEO as a separate engineering workstream.
• Editorial operations model: Registration-reference support implies the CMS holds references to external registration systems rather than processing payments itself. This supports a decision to keep ticketing/registration with a specialist vendor and use the CMS as the content and discovery layer.
• Platform consolidation: If the org currently stitches together a CMS, a separate events plugin, and bespoke speaker pages, this release is evidence for consolidating onto a single Laravel-native stack — one content model, one admin, one API.
• Use cases this enables: conference and summit sites, community meetups, training/webinar calendars, multi-track agendas, speaker and venue directories, historical event archives, and partner-facing event feeds via API.

When to Consider This Package

Consider adoption when:

• You are on a modern Laravel/PHP stack and are comfortable owning a Laravel application rather than a SaaS CMS.
• Events are a real, recurring content type — conferences, meetups, webinars, training — not a one-off page you could hand-build in a week.
• You need multiple output surfaces (public site, API for partners or apps, admin tooling) and want them driven by one content model.
• Editors, not engineers, need to manage events, sessions, speakers, and venues day to day — the Filament package is the relevant signal here.
• SEO matters: you want structured data and archives without commissioning custom work.
• You want registration handled externally and only need the CMS to reference it, not process payments.
• You value incremental, composable adoption: API, Filament, and Livewire packages can be taken selectively.

Look elsewhere when:

• You need native ticketing, payments, or attendee management — this is a content layer with registration references, not a ticketing platform.
• Your team is not Laravel-native; the operational and hiring cost of adopting a Laravel package ecosystem outweighs the feature savings.
• You require a hosted SaaS CMS with vendor support SLAs and no in-house maintenance.
• Your event needs are genuinely one-off — a single landing page does not justify a content module and its upgrade path.
• You need deep integration with a specific CRM, marketing automation, or ticketing vendor beyond reference-level linking; validate that the API surface covers your integration before committing.
• You are mid-migration or mid-freeze on your CMS; a major-version feature release is the wrong moment to replatform.

How to Pitch It (Stakeholders)

For executives: The CMS we build on shipped a major events capability in v32.0.0 — events, sessions, speakers, venues, calendars, archives, structured data, plus admin, API, and frontend packages. In practical terms, an events and conference-calendar roadmap item that would otherwise be a bespoke engineering project is now largely an adoption and design task. That compresses timeline, reduces delivery risk, and gives us SEO-ready event content and an API for partners without extra build. Registration and payments stay with our existing vendor; this is the content and discovery layer.

For engineering: This is a feature release, not a breaking one — adoption is additive and composable. The Events module arrives with matching API, Filament, and Livewire packages, so we can take the content model and API first and layer on admin and frontend surfaces as needed. Structured data and archive handling are already implemented, which removes two commonly underestimated workstreams. Key evaluation items before commitment: upgrade path and versioning cadence of the parent package, the shape and stability of the API contract, how registration references are modeled (we will be linking out, not processing), and the maintenance burden of owning a Laravel-native stack. Recommend a scoped spike: model one real event series end to end, confirm editorial workflow in Filament, and validate the API responses against a partner or mobile consumer.

For product: The decision this release forces is build-vs-adopt on events. Default recommendation is adopt, contingent on the spike above. If it holds, we should pull the events initiative forward and re-sequence the roadmap around it rather than continuing to spec a custom build.