Slider Bundle Laravel Package

Getting Started

This is not a Laravel package, and that is the first thing to internalise. enhavo/slider-bundle is a Symfony bundle and a read-only subtree split of the Enhavo CMS monorepo. There is no Laravel service provider, no facade, no config/slider.php. Composer-installing it into a Laravel app gives you a Symfony Bundle class that expects the Enhavo kernel, the Enhavo resource bundle, Doctrine mappings, Sylius components, and the Enhavo admin stack. If you are not already on Enhavo, stop here.

If you are on Enhavo, the onboarding path is:

1. Read the main repository, not this one. The README here is a stub that says "subtree split" and points at github.com/enhavo/enhavo. Issues, docs, changelog, and versioning all live there.
2. In the monorepo, look at the EnhavoSliderBundle directory: the bundle class, DependencyInjection/Configuration.php, Resources/config/*, the Slider and Slide entities, form types, Twig views, and the slider block class. That code is the documentation.
3. Install via the meta package (enhavo/enhavo) rather than this split, register the bundle in config/bundles.php, let Doctrine pick up the mappings, and update the schema.
4. First use case: an editorial hero carousel on a landing page. Create a Slider in the admin UI, add Slides with media, link, and text, then drop the slider block into a page's content area and let Enhavo's block renderer output it.

For a Laravel project, the honest answer is: don't bridge this. Model a Slider/Slide pair in Eloquent and render a Blade partial, or use a front-end carousel library. This bundle buys you nothing outside Enhavo.

Implementation Patterns

Treat it as a content resource, not a JavaScript slider. Enhavo sliders store headline, slides, media references, and links; rendering is server-side Twig. Autoplay, arrows, gesture handling, and responsive behaviour belong to your theme's JS/CSS. Keep the CMS data layer and the presentation layer separate — that is the whole point of the abstraction.

Admin-first, reuse over duplication. Create sliders as standalone resources and attach them to pages by reference, so marketing can swap a hero without a deploy or a template change. Prefer one reusable slider over per-page inline slide data; the latter rots fast.

Override by config and template inheritance. Enhavo's extension model is class parameters plus Twig overrides, not events. Point the configurable slider/slide class parameters at your own subclasses and override templates under templates/bundles/EnhavoSliderBundle/.... Keep each layout variant as its own block template rather than piling conditionals into one file.

Don't leak entities into your API. If another surface consumes slider data, map Slider/Slide into your own DTO/response shape. Doctrine entities tied to a CMS are a poor public contract and make a future migration painful.

Seed deliberately. Use Enhavo's fixture system or Doctrine fixtures, and import media before slides — slides referencing not-yet-created media resources are a classic silent failure.

Gotchas and Tips

• This repository is not the source of truth. It is a split; PRs and issues belong upstream. Zero stars, zero dependents, no real README, no independent community. Pin against the main Enhavo package, not this one, and expect no support surface here.
• Symfony-vs-Laravel mismatch is fatal, not friction. No service provider, no container conventions you'd recognise from Laravel. The integration cost is "adopt a second framework", which is almost never worth a carousel.
• Version lockstep. Split packages are tagged in sync with the monorepo. Mixing split versions across Enhavo bundles produces confusing class-not-found or signature errors. Install the meta package and let Composer resolve the set together.
• Silent misconfiguration. A missing bundle registration or mapping typically yields an empty admin screen or "class not found" rather than a clear error. Check config/bundles.php, Doctrine mapping, and the bundle's Configuration.php defaults in that order.
• Debugging tools: debug:container to confirm slider services and form types are registered; debug:twig to find the exact override path. Clear the cache after every template or config change — Enhavo will happily serve the stale one.
• Media is the usual breakage point. Missing images, broken references after imports, or filesystem/adapter misconfiguration render blank slides without throwing. Validate media references whenever content moves between environments.
• Extending entities means migrations plus form types. Subclass Slide, update the class parameter, write the migration — and remember the form types are configured per class, so an unregistered subclass gives you an editor that silently drops your new field.
• Know when to walk away. If the requirement is "show a carousel", use Swiper or Splide. Reach for EnhavoSliderBundle only when you need editor-authored, CMS-managed slider content inside an existing Enhavo installation.