Sulu Event Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for calendar/event functionality. The package supplies Sulu entities, admin UIs, calendar views, and a smart content provider out of the box. The decision it de-risks is: "do we spend 3–6 engineering weeks building event and location CRUD, admin screens, and a content-embedding mechanism, or do we install and theme?" For a Sulu-based property, this is a credible buy-side shortcut — and v3.5.0 widens the delta in the buy column by absorbing two items that would otherwise land in a bespoke build: scheduled publish/unpublish (via optional sulu/automation-bundle integration) and direct template routes for events.
• Roadmap sequencing for content-led sites. Typical fits: venue and arts organizations, municipalities, associations, retail/healthcare chains with branch locators, conference and training sites. If "events" or "find a location" sits on the roadmap as a differentiator-light, table-stakes feature, this package lets you ship it without consuming a sprint of core-team capacity. The v3.5.0 publish-state indicator and category/tag-aware smart content also shorten the editorial polish tail that usually follows an "MVP" event listing.
• Editorial autonomy (a product decision, not a technical one). Smart content integration remains the strategic piece, and v3.5.0 strengthens it: smart content now evaluates website categories and tags, so editors can drive event/location listings by taxonomy rather than by manually curating selection lists per campaign. That translates to fewer engineering tickets per campaign and faster time-to-publish — worth quantifying against your current editorial backlog, and worth comparing against your existing taxonomy governance before you commit to reusing site categories as the targeting mechanism.
• AI-assisted content operations (new decision this release forces). The addition of MCP tools for events and locations — with field-level partial updates on the event update tool — makes this package a candidate substrate for agentic or automated content workflows, not just manual editorial entry. That is a genuine product question now: do we want LLM/agent tooling able to touch published event records? If yes, this is a cheap on-ramp. If no, treat the MCP surface as something to scope, gate behind permissions, and audit before enabling — it is not a neutral capability.
• Data model and platform-fit decisions. Choosing this bundle is an implicit commitment to Sulu's entity, localization, permission, and workflow conventions rather than a bespoke model. That is usually the right call for consistency, but it forecloses easy migration to a commerce or ticketing system later — decide deliberately.
• Scoping boundary decisions. It manages and displays events and locations. It still does not, on the evidence available, cover registrations, ticketing, payments, seat maps, or outbound calendar sync. Those remain explicit non-goals you must scope and staff separately — a useful line to draw early with stakeholders who hear "events" and assume "sell tickets." Note the release's expanded surface (MCP, automation, taxonomy-driven smart content) makes the package look more like a platform than a calendar widget; hold the line that it is still not a ticketing or booking system.
• Opportunity signal. This remains a narrow-niche project with limited community momentum (low opportunity score as previously measured; verify current star/dependent counts, which this review could not re-confirm). The v3.1.7–v3.5.0 span shows real feature throughput, which is a positive maintenance signal, but it is throughput from a single-maintainer project — treat it as a tactical accelerator, not a strategic platform bet, and do not build a multi-year roadmap on top of it.

When to Consider This Package

Adopt (or, more accurately, pilot) when:

• You are already running Sulu CMS. This is the hard prerequisite. The package is a Symfony bundle for Sulu, not a Laravel package — if your stack is Laravel, the true adoption cost is standing up an entire second CMS, which almost certainly fails the business case.
• You need events and locations as editor-managed content, with a calendar presentation, and no ticketing.
• Scheduled publishing matters to your editorial calendar. v3.5.0's automation-bundle integration covers scheduled publish/unpublish, which previously was custom work. It is optional and guarded via interface_exists(), so it degrades cleanly if you do not run that bundle.
• You want SEO-clean event URLs. Direct routes for event templates reduce the custom routing work that a listing-only implementation otherwise requires.
• You want taxonomy-driven listings. Category/tag-aware smart content lets editors build listings without per-campaign engineering.
• Your team is thin and the alternative is a multi-week bespoke build of Sulu entities, admin controllers, and a custom smart content provider.
• MIT licensing and Composer installability satisfy procurement; you are willing to pin a version and accept that you may need to fork.
• You have run a 1–2 day spike on v3.5.0 or later confirming it installs cleanly against your Sulu version, the admin UI meets your editors' expectations, and the calendar view is adequate without heavy theming.

Look elsewhere when:

• You are not on Sulu. For Laravel, evaluate a first-party event/calendar package or a headless calendar service; do not import a CMS to get a calendar.
• Ticketing, registration, payments, or capacity management are in scope. Integrate a dedicated platform (and embed or API-sync it) rather than extending this bundle.
• You need enterprise support, an SLA, or a security-review trail. Single-maintainer community projects rarely clear that bar; limited dependents means no third-party validation of upgrade paths.
• Complex recurrence (RRULE semantics), timezone-heavy scheduling, iCal/Google/Outlook sync, or multi-tenant venue hierarchies are requirements. Verify before committing — these are the classic places lightweight event bundles break, and each is a substantial extension.
• You cannot absorb a data-migration step on upgrade. v3.5.0 changes how event image data is stored and ships sulu:events:clean-image-data to remediate rows written by earlier versions. If you already run this package, that is a required operational task, not an optional tidy-up.
• Maintenance risk is unacceptable. Small star count and few dependents means you are likely the first to hit any given bug. If your organization cannot absorb "we now own this code," stop.
• Verification note: confirm actual repository activity, open-issue responsiveness, and the tested Sulu/PHP version range in the composer constraints before treating release cadence as a health signal — the release cadence visible here is strong, but the range of supported Sulu versions should be read from composer, not inferred. Also disambiguate from Sulu's own official sulu/event-bundle, which is a domain-event/dispatcher component and unrelated to calendar events — a real source of confusion in architecture discussions.

If already adopted, budget this upgrade work:

• Run bin/console sulu:events:clean-image-data --dry-run first and review the diff, then run without the flag. Plan it as a deploy-window task with a backup, not a hotfix.
• Re-test image, PDF, speaker, and author fields on existing event templates. The fixes indicate earlier versions could clear those fields from template data and could persist bloated image payloads into templateData — so verify post-migration content rendering rather than assuming parity.
• Re-check any custom smart content label; the global sulu_admin.smart_content_label override was removed and may affect admin copy.
• Re-test workflow on live-stage event content, since the workflowPlace check on live-stage content was removed.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed extension that gives our Sulu site an events calendar and location directory — including the editor-facing screens — instead of us building them. It converts a multi-week engineering item into a days-long integration, and it hands publishing control to the content team, which reduces the ongoing drip of small template-change requests. The latest release adds scheduled publishing, cleaner event URLs, and taxonomy-driven listings, so more of the "nice to have" around an events section now comes standard instead of as change requests. The trade-off is support: it is a small community project with a single maintainer, so we should treat it as a time-saver we are prepared to own, budget a small maintenance reserve including one data-cleanup upgrade task, and keep it out of the critical path of revenue-generating features like ticketing.

To engineering: Symfony bundle for Sulu 2.x, Composer-installable, MIT so it is forkable. It brings entities, admin UI, calendar views, and a smart content provider — the last being the real value, since it plugs into Sulu's native content-type system rather than requiring custom templates. Since v3.1.6 it has added MCP tools for events and locations (event updates are field-partial), optional sulu/automation-bundle integration for scheduled publish/unpublish, direct event template routes, category/tag-aware smart content, and a sulu:events:clean-image-data command. It also lands a batch of data-integrity fixes around image/templateData handling, field preservation, date normalization, and locale-aware filtering — which means the upgrade is not drop-in: run the cleanup command dry-run first, then for real, with a backup, and re-verify media fields and live-stage workflow. Before we commit: run a spike against our exact Sulu and PHP versions, review the composer constraints, confirm the maintenance surface (stars, dependents, issue activity), decide our fork-and-patch policy up front, and explicitly decide whether the MCP surface is enabled, permissioned, or disabled. Pin the version, vendor the dependency, and document the extension points we would use if we need recurrence, iCal export, or a ticketing hand-off.

Recommendation: Approve a short, time-boxed spike, not a roadmap dependency. Go/no-go on the spike output, with a standing assumption that if we adopt, we own the code — and if we already run it, treat v3.5.0 as a planned upgrade with a data-cleanup step rather than a routine bump.