Events Calendar Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for event calendar capabilities: This bundle is a buy signal for core event publishing, management, and discovery: event listing, filtering by category/keyword/time period, iCal export/subscription endpoints (/api/ical/search/{query}), GraphQL event teasers, and external calendar integration. It can remove weeks of bespoke calendar work from the roadmap. As of 1.18.1, date handling was corrected to differentiate between expand and search by date — i.e., the two date-driven behaviors no longer share ambiguous logic. That is a correctness fix in the exact capability Phase 1 depends on, and it reinforces setting a minimum adoptable version of 1.18.1 rather than an arbitrary "latest."
• Roadmap sequencing:
  • Phase 1 — Event discovery MVP: Adopt event listing, category/keyword/date filtering, and iCal endpoints for user-facing calendars and subscriptions. Pin to ≥1.18.1 so the date expand/search distinction is the version you validate against.
  • Phase 2 — Content surface integration: Use GraphQL event teasers to embed upcoming events in landing pages, campaign pages, and CMS-driven surfaces. Note that 1.18.1 also bumps the atoolo-graphQl dependency, so re-verify teaser rendering during the PoC rather than assuming parity with earlier builds.
  • Phase 3 — Search and index quality: Leverage RCE indexer hooks for inactive-event filtering, blacklisted dates, venue/category mapping, and topic anchors to improve search relevance.
• Use-case fit: Community events, conferences, webinars, venue-based schedules, multi-instance event programs, and multilingual iCal feeds. The bundle's scheduling model (begin/end date and time, gmdate handling, null-end-date semantics, Scheduling DTOs/services) supports common single- and multi-day events without building a custom date engine.
• Scope discipline: The package handles scheduling and publication, not complex recurrence rules, ticketing, payments, seat maps, or attendee CRM. PM should explicitly keep those out of the initial scope to preserve time-to-market.
• Data governance and compliance: Inactive/blacklisted event filtering during indexing and venue/category mapping support content-accuracy and taxonomy decisions. Product should define category, venue, topic, and keyword schemas early because indexing behavior depends on them.
• Risk-adjusted roadmap: With 0 stars and 0 dependents, this is a vendor-led component, not a community standard. Treat adoption as an integration bet: pin versions, wrap in an anti-corruption layer, and keep a fork/maintenance path in the risk register. MIT licensing preserves exit options. The 1.18.1 cycle is a useful signal in both directions: the vendor is actively fixing behavior-level bugs, but a patch release that changes date semantics is precisely the kind of change that argues for pinned versions and regression tests on our side.

When to Consider This Package

Consider adoption when:

• You are building on Symfony or can run a Symfony bundle alongside your PHP service. This is a Symfony bundle, not a native Laravel package; do not assume drop-in Laravel/Eloquent/Blade compatibility.
• You are already in or willing to adopt the atoolo/Sitepark ecosystem (resource bundle, GraphQL search bundle, RCE indexer). Much of the value comes from these integrations; outside that ecosystem, integration cost rises significantly.
• You need event publishing plus filtering plus iCal plus GraphQL teasers out of the box, and your event model aligns with scheduling dates, venues, categories, topics, and keywords.
• You need multiple event instances and multilingual iCal endpoints — both are supported by recent releases.
• You value the quality signals: MIT license, active release cadence, PHP 8.2–8.4 support, PHPStan level 9 (with the toolchain now being trialed against PHPStan 2.3), and e2e test integration — while accepting that PHP 8.1 is no longer automatically checked.
• You can tolerate low external adoption and vendor-led governance, and you have a plan to own integration risk — including regression testing of date filtering behavior across patch upgrades.

Look elsewhere when:

• You need first-class Laravel integration: native models, migrations, Nova/Filament admin, queue integration, and Blade components. Expect adapter work or a different package.
• You need complex recurrence rules (RRULE), ticketing, payments, seat maps, or attendee CRM. These are out of scope.
• You need a widely adopted community package with a large plugin ecosystem, third-party extensions, or vendor-neutral long-term support guarantees.
• You are not in the Sitepark/atoolo ecosystem and cannot absorb coupling to its resource, GraphQL, and indexing bundles.
• You require independent OSS governance, external contributor depth, or a broad production reference base before adoption.

How to Pitch It (Stakeholders)

For executives: This is a prebuilt event calendar for our PHP stack covering publishing, filtering, iCal subscription, and GraphQL event teasers. It can shorten time-to-market for event discovery. The caveat is adoption risk: it is a Symfony bundle from the Sitepark/atoolo ecosystem with near-zero external adoption. It is MIT licensed and forkable, but we should treat it as a vendor component and own the integration risk. The latest patch (1.18.1) is a maintenance release — a date-handling bug fix plus dependency and tooling upkeep — which shows active stewardship without adding scope. Recommendation: approve a time-boxed proof of concept on 1.18.1 before committing roadmap dates.

For engineering: This is an MIT Symfony bundle supporting PHP 8.2–8.4, PHPStan level 9, e2e tests, and regular releases. It provides scheduling DTOs and services, an iCal API (/api/ical/search/{query}, occurrence parameter, filename sanitization), GraphQL event teasers, and RCE indexer hooks for inactive/blacklisted filtering and venue/category mapping. 1.18.1 fixes date handling by differentiating between expand and search by date, bumps the atoolo-graphQl dependency, adjusts phars.xml, and trials PHPStan 2.3 — no breaking changes or deprecations. Read the date fix as behavioral, not cosmetic: if you already run an earlier 1.18.x, re-run date-filter and iCal-range tests after upgrading. It is not a Laravel package — budget adapter work if we are on Laravel. Dependency footprint includes atoolo resource and GraphQL search bundles. Mitigate risk with version pinning (floor at 1.18.1), an anti-corruption layer, and a fork option.

For product: Use it to ship Phase 1 event listing/filtering and iCal subscriptions quickly, then Phase 2 GraphQL teasers for content surfaces, then Phase 3 indexing improvements. Do not scope complex recurrence or ticketing onto it. Define taxonomy — categories, keywords, venues, topics — early because indexing and filtering depend on those choices. The 1.18.1 fix to date expand-vs-search behavior is a reminder that filtering semantics can shift in patch releases, so write acceptance criteria for date-range and recurring-instance behavior explicitly and require them in the PoC. The low community score is a signal to validate fit with a proof of concept, not an automatic blocker.