- Can I install frequence-web/calendr-bundle in a Laravel application?
- No. It is a Symfony bundle, not a Laravel package: its value comes from a Symfony Bundle class, a DependencyInjection extension for YAML configuration, and a Twig extension, none of which Laravel's container, config repository, or Blade compiler can consume. Do not add it to a Laravel app's composer.json. If you want the underlying functionality, depend on the framework-agnostic CalendR library directly.
- Is frequence-web/calendr-bundle a Laravel calendar package?
- No, it is Symfony2 integration for the CalendR PHP library. The only Laravel-compatible part is CalendR itself, which is framework-agnostic. Treat the bundle as a reference implementation and documentation rather than a dependency.
- How do I use CalendR in Laravel?
- Depend on CalendR core via Composer, then write a small service provider of roughly 150 lines, a config/calendar.php file, and one or two Blade components that wrap the renderer. Map the bundle's Twig helper output to Blade partials and wire an Eloquent-backed event source into CalendR's event-collection interface. The work is mostly presentation glue, not calendar logic.
- What can CalendR actually do?
- CalendR is a rendering and export helper: it builds month and week views from event objects, produces iCal output, and generates calendar links. It is not a calendaring system, so it has no persistence, recurrence engine, or attendee and invitation model. Anything beyond drawing a calendar with events and exporting it must be built or bought separately.
- Is frequence-web/calendr-bundle maintained and production ready?
- Evidence is thin: around 23 GitHub stars and zero dependents, with a Symfony 2-era structure that suggests a dormant project. Assume no upstream security patching, no PHP-version maintenance, and no issue responsiveness. It is not a safe production dependency for a new Laravel application.
- Does frequence-web/calendr-bundle support Laravel 10 or 11 and PHP 8.x?
- There is no Laravel support at all, and the bundle targets Symfony 2.x-era APIs such as PSR-0 autoloading, older DI patterns, and Twig 1.x. Expect friction if you install it against modern PHP even in a scratch project. Test CalendR core itself against your PHP 8.x target during a spike before committing.
- Can I reuse the bundle's Twig helpers in Blade?
- Not directly. Port the helper signatures and template markup once into Blade partials or components rather than shimming Twig into Laravel. Installing Symfony DI, HttpKernel, or Twig just to satisfy one rendering helper would drag a parallel framework into your app. A one-time port is smaller and cleaner.
- What if I only need .ics or iCal export, not HTML calendar rendering?
- Then the integration surface shrinks dramatically: you may not need CalendR's rendering layer at all. A maintained iCalendar library for export plus a JavaScript calendar such as FullCalendar for display is often the better fit. Confirm during your spike whether server-side HTML rendering is genuinely required.
- What are the alternatives to frequence-web/calendr-bundle for Laravel?
- Use CalendR core with a first-party Laravel adapter if you need server-side month and week rendering plus iCal export. If you mainly need export, evaluate a maintained iCalendar library; if you mainly need display, use a JavaScript calendar and keep the backend for data. Avoid pulling the Symfony bundle or its transitive Symfony and Twig requirements into Laravel.
- What production risks should I watch for with CalendR calendars?
- The real complexity is in the domain, not the package: timezones, DST transitions, multi-day and all-day event boundaries, locale-aware week starts, and iCal escaping and line folding. The bundle provides no coverage of these, so plan tests around them. Also verify the repository license before forking or copying the thin adapter internally.