Filter Widget Laravel Package

Technical Evaluation

Architecture fit

The first finding is a category mismatch that should be resolved before any engineering time is spent. Despite being catalogued alongside Laravel/PHP packages, friendsofvictoire/filter-widget is a Symfony bundle (FriendsOfVictoire/WidgetFilterBundle) built for Victoire DCMS, a Symfony-based content management system. It integrates through Symfony's bundle registration and DI container, depends on Victoire's own widget abstraction layer (widget maps, slot/renderer conventions), Doctrine ORM for content querying, and Twig for presentation. None of these primitives map onto Laravel's service container, Eloquent, or Blade.

The practical consequence: the package is not consumable as a library inside a Laravel application. It is only usable by operating Victoire itself, which in turn pins the host application to the Symfony 2.8/3.x generation. Architecture fit for a Laravel stack is effectively zero.

What is potentially reusable is the concept, not the code: a widget that lets a non-technical editor configure a saved filter (taxonomy/attribute predicates) over a content listing, persisted as widget configuration and rendered server-side. That is a design worth borrowing; the implementation is not.

Integration feasibility

• Direct install: Not feasible outside a Victoire instance. The bundle assumes Victoire's kernel, widget registration, and template inheritance chain.
• Partial extraction: Also impractical. The value is concentrated in editor-facing configuration UI and query assembly, both of which are coupled to Victoire's Doctrine query layer and form/widget system. Porting would be a rewrite in Eloquent with borrowed semantics, not an integration.
• Effort if attempted anyway: A Symfony/Victoire compatibility shim would be larger than a greenfield Laravel implementation of the same feature.

Technical risk

High, and concentrated in the dependency tree rather than the package's own code:

• Abandonment. Last release 2016-12-22. No security patching, no PHP 8 compatibility, no maintenance. Victoire itself is effectively dormant.
• Transitive exposure. Adopting it drags in EOL Symfony 2.8/3.x and Doctrine components — these, not the widget, are the real CVE surface.
• No community validation. 3 stars, 0 dependents, low health score (0.335). There is no evidence of production use anywhere, so no field-tested failure modes to learn from.
• Documentation. Expect thin or absent docs; behaviour must be reverse-engineered from source.

Key questions

1. What is the actual requirement — an editor-configurable filtered content listing, or something narrower? This determines whether the concept is even relevant.
2. Is any part of the estate running Symfony or Victoire today? If not, this is a reference-only artifact and should be closed out.
3. If Victoire is in production, what is the exit timeline? That reframes the package as a migration liability rather than a candidate dependency.
4. Does a Laravel-native equivalent already exist in our stack (query scopes, saved-filter tables, Filament/Nova filters), making this redundant?

Integration Approach

Stack fit

None for a Laravel target. The package's host requirements (Symfony DI, Twig, Doctrine, Victoire widget contracts) are mutually exclusive with Laravel's runtime. The only stack on which it fits is a Victoire/Symfony 2.8–3.x installation, which we should not be standing up in 2024+.

Recommendation: do not integrate. Treat the repository as a design reference and reimplement the capability natively.

Migration path

• If no Victoire in the estate: no migration path exists or is needed. Capture the filter-configuration UX pattern in a short design note, then build the Laravel equivalent.
• If Victoire is in production: this widget is a component of the legacy surface that must be retired, not extended. Inventory where it is used, document the filter semantics configured by editors, and add those to the CMS migration backlog. Do not add new instances of it.
• Laravel-native equivalent (suggested shape): a saved_filters table (owner, target resource, JSON predicate set), a validation layer for allowed fields/operators (allowlist, not free-form), an Eloquent query-scope builder that applies predicates, and policy-gated CRUD. Roughly a one-to-two sprint feature, with no third-party dependency risk.

Compatibility

PHP 5.6/7.0-era constraints and Symfony 2.8/3.x APIs. Incompatible with PHP 8.x and current Symfony. Confirming this is a 15-minute check of composer.json — worth doing once to close the question definitively rather than revisiting it.

Sequencing

1. Confirm the business requirement independently of the package.
2. Confirm no Victoire dependency exists (or scope the retirement if it does).
3. Write a one-page spec of the filter semantics we actually need.
4. Build natively; skip evaluation spikes on the bundle entirely.
5. If legacy Victoire is present, schedule its removal with the widget's replacement.

Operational Impact

Maintenance

Effectively unmaintainable. There is no upstream to patch security issues, no release cadence since 2016, and no maintainer response path. Any use implies forking and owning the code in perpetuity — including the EOL Symfony and Doctrine dependencies it drags along. The total cost of ownership vastly exceeds the cost of writing the feature ourselves.

Support

No vendor, no active community, no dependents to consult. Internal ramp-up would land entirely on whoever reverse-engineers the source. This is a single-point-of-failure knowledge risk for a feature that is, by scope, not difficult to build.

Scaling

The widget's output is a filtered content query rendered server-side per request. Expect the usual failure profile for editor-configured queries: no bound on predicate complexity, potential for expensive joins or unindexed column filters, and N+1 patterns around related content. There is no evidence of query caching or result memoisation in a 2016-era bundle, so any high-traffic deployment would require adding caching that the package does not provide. A native implementation lets us enforce an operator/field allowlist and cache keyed on filter ID — a meaningfully better scaling story for less work.

Failure modes

• Bundle registration or container compilation failures on any Symfony version drift.
• Template inheritance breakage when Victoire's theme layer changes.
• Silent query degradation as content volume grows (editor-configured filters are rarely index-aware).
• Unpatched CVEs in abandoned transitive dependencies, with no upgrade path.
• Knowledge loss: no one on the team will have operated Victoire, making incident response slow.

Ramp-up

High cost, low return. Engineers would need Victoire-specific context that has no transferable value elsewhere in the stack. By contrast, the native Laravel reimplementation is standard work for any mid-level engineer on the team and produces code we own and understand.

Bottom line: the health score (0.335) is accurate. This is an abandoned component of an abandoned CMS, mis-catalogued as a Laravel package. Recommend closing it as a dependency candidate and, at most, mining it for the editor-facing filter UX pattern.