friendsofvictoire/slider-widget
A slider widget for the Victoire CMS, providing a configurable image carousel component for your Symfony/PHP pages.
Add the bundle with Composer:
composer require friendsofvictoire/slider-widget
This package is a Victoire DCMS widget bundle, not a standalone slider library. It is meaningless without the Victoire core (victoire/dcms and friends), so the first thing to confirm before anything else is that your project is actually a Victoire application (typically Symfony 2.8/3.x era). If you are starting a new Symfony 5+/6+ project, this bundle will not install or run — Victoire itself stopped tracking Symfony releases around 2018.
Register it where Victoire bundles are registered. In classic Victoire projects that is app/AppKernel.php:
new Victoire\Widget\SliderBundle\WidgetSliderBundle(),
Then look first at these files once the package is in vendor/:
WidgetSliderBundle.php — confirms the bundle name and any compiler passes.Entity/Widget/… (or Widget/…) — the concrete widget class; this tells you which fields the slider exposes and how it extends Victoire's Widget model.Form/… — the Symfony form type used inside Victoire’s edit mode; this is the actual “admin UI” of the widget.Resources/views/Widget/… — the Twig template rendered on the front end; this is where markup, CSS classes, and slider JS hooks live.Resources/config/services.yml — shows the victoire_widget tag wiring that makes Victoire’s widget registry discover it.First use case: boot a Victoire app, open a page in the Victoire editor, click Add widget, and confirm “Slider” appears in the widget picker. Dropping it onto a slot and filling in its form is the intended day-one workflow. If the widget does not appear in the picker, the problem is almost always bundle registration or a missing victoire_widget tag, not the slider code itself.
Editor-driven configuration. In Victoire, widgets are configured by content editors, not developers. Your day-to-day work with this bundle is usually adjusting the widget’s form type (Form/Widget/…Type.php) to expose fields editors need (title, autoplay, per-slide image, caption, link) and updating the Twig template so those fields render correctly. Treat the form type as the schema.
Slide modeling. Two patterns exist in Victoire widget bundles and this one uses one of them:
BusinessEntity collection, so slides can be reused across pages. You extend the widget entity, add a OneToMany/ManyToMany association, and handle it in the form with CollectionType or Victoire’s business-entity picker.CollectionType + allow_add/allow_delete/by_reference: false.Check Entity/ to see which was chosen; it dictates whether editors can reuse a slide elsewhere or must duplicate it.
Template integration. The front-end template under Resources/views/Widget/ is the integration point for your slider JavaScript library (Slick, Swiper, Owl, etc.). Victoire does not ship a slider implementation — the bundle just outputs markup and the configuration data. You wire the JS in the template (or in a page-level asset) and initialize on a class you add there. Override the template in app/Resources/VictoireWidgetSliderBundle/views/... (classic Symfony override path) rather than editing vendor/.
Rendering from code. If you need to render a slider outside Victoire’s normal page flow (a landing page controller, an email, a partial), use Victoire’s widget rendering service/helper — typically the victoire_cms.widget_renderer or the widget’s own render() path through the widget manager. Do not try to instantiate the widget entity directly with new; Vitctoire widgets expect to be hydrated by the manager and tied to a widget slot.
Extending rather than forking. If you need an extra field, the cleaner pattern in Victoire is to create a small custom widget bundle that extends this widget’s entity/form/template, or override the Twig template and form theme. Forking is tempting given how small the package is, but the widget tag in services.yml and the concrete widget class name are what Victoire keys on — a fork means re-registering under the same tag and risking conflicts.
victoire/dcms and Symfony version pins to block installation on anything modern. If Composer resolves, verify PHP version and the victoire package versions explicitly before assuming success.victoire_widget tag present in services.yml, cache cleared (bin/console cache:clear), Victoire widget cache rebuilt. A missing tag is the classic cause.CollectionType, guard against empty submissions: allow_add without a prototype in the template, or by_reference: false without a setter, causes silent no-ops. Add validation constraints on the widget entity — the bundle probably ships few or none.app/Resources/<BundleName>/views/… on Symfony 2.x/3.0–3.3; templates/bundles/<BundleName>/… on 3.4+. Pick the one matching your app or your override is silently ignored.Form/, Entity/, and Resources/views/ directories as the documentation. Read the widget class first; everything else follows from it.bin/console debug:container | grep -i slider and debug:twig to confirm the widget service and template are actually registered. Victoire caches widget metadata aggressively, so clear cache after any config change.composer.json, vendor the JS and CSS, and keep a fork ready if you ship to production.How can I help you explore Laravel packages today?