- Can I use friendsofvictoire/picturecomparator-widget in a Laravel application?
- No. This is a Symfony bundle built for the Victoire CMS, not a Laravel or framework-agnostic PHP package. It integrates through Symfony-specific extension points such as a bundle class registered in AppKernel, DI service definitions, a Widget model extending Victoire's AbstractWidget, Twig template overrides, and Doctrine-persisted widget instances bound to a WidgetMap. None of those map onto Laravel's service container, package discovery, Blade pipeline, or Eloquent layer, so architecture fit is effectively zero without a rewrite.
- Does this package support Laravel 10 or Laravel 11?
- No. The bundle has no Laravel service provider, no facade, no Blade views, and no Eloquent integration, so there is nothing for Laravel's package discovery to register. Its last release was in 2018 and its Composer constraints target the Symfony 2.8/3.x era. There is no supported path to running it inside a modern Laravel 10 or 11 application.
- How do I install friendsofvictoire/picturecomparator-widget with Composer?
- You would run composer require friendsofvictoire/picturecomparator-widget, then register the bundle in a Symfony AppKernel and configure its DI services. On a modern PHP runtime the install will almost certainly fail platform checks, forcing --ignore-platform-reqs or a PHP downgrade, neither of which is advisable. There is no Laravel installation path because the package is not a Laravel package.
- Is friendsofvictoire/picturecomparator-widget still maintained?
- No. The last release was 2018-05-24, with single-digit stars and zero dependents. There is no active maintainer, no issue triage, and no security response path. FriendsOfVictoire is a community successor org to a dormant CMS, so there is no vendor relationship to lean on for fixes.
- What is the best Laravel alternative for a before/after image comparison slider?
- Reimplement the feature rather than port it. Add before_image_id and after_image_id media fields to the relevant Eloquent model, then build a Blade component wrapping an actively maintained JavaScript comparator library such as img-comparison-slider or beerslider, or write a small Alpine component. Expose it as an admin-editable block through whatever block system you already use, such as Filament, Nova, Statamic, or a custom registry. Estimated effort is roughly 2 to 4 developer days including styling, responsive behaviour, and accessibility.
- Is this package safe to use in a production Laravel application?
- It carries high, asymmetric technical risk. A 2018 Symfony-era bundle pulls Symfony 2.8/3.x constraints, old Twig, old Doctrine, and possibly Assetic, a transitive surface that reached end-of-life between 2018 and 2021 and carries unpatched advisories. With no maintainer and no security response path, adopting it would leave you owning the audit and remediation of an unmaintained dependency. It is not recommended for production.
- Does the widget work with PHP 8.2 or PHP 8.3?
- Composer constraints from that era typically cap at PHP 7.x, which conflicts directly with PHP 8.2 and 8.3 targets. Installing it would almost certainly require --ignore-platform-reqs or a PHP downgrade, which is a non-starter on a modern runtime. Treat the package as incompatible with current PHP versions.
- How does the Victoire widget integrate with Symfony, and why doesn't that map to Laravel?
- It registers as a Symfony bundle with DI service definitions, a Widget model extending Victoire's AbstractWidget, Twig template overrides, and Doctrine-persisted widget instances bound to a WidgetMap. Each of those depends on Symfony kernel and compiler-pass behaviour that has no equivalent in Laravel's container, package discovery, Blade pipeline, or Eloquent layer. There is also no maintained Symfony-to-Laravel bridge that would make a Victoire widget bundle usable inside an Illuminate application, so treat it as incompatible rather than needing adaptation.
- Should I port the bundle to Laravel or reimplement the feature?
- Reimplement, do not port. What the package actually does is a small, well-understood front-end pattern needing two image references, a container element, and a JS handler, roughly 100 to 250 lines of Twig or Blade plus a comparator script. Porting would mean reimplementing Victoire's widget registration, persistence, and form-type plumbing for no functional gain, at an estimated 2 to 3 weeks plus indefinite maintenance of a fork with no upstream. If a Symfony service genuinely exists in your estate, isolate it behind an HTTP boundary rather than sharing code.
- Does the 2018 slider meet modern accessibility and mobile touch requirements?
- Probably not. A 2018-era implementation is unlikely to provide keyboard operability for the drag handle or adequate contrast on the divider, and mobile touch behaviour may be unreliable. If you reimplement with a maintained library or a small Alpine component, explicitly add keyboard support, visible focus states, divider contrast, and touch handling to your acceptance criteria. These requirements should be verified rather than assumed.