Richlist Widget Laravel Package

Technical Evaluation

Architecture fit — poor, and mislabeled. Despite being presented as a Laravel/PHP package, friendsofvictoire/richlist-widget is a Symfony bundle for Victoire DCMS, a Symfony 2.x/3.x-era CMS that has been effectively dormant since roughly 2017. The widget follows Victoire's bundle conventions: a Doctrine-mapped widget entity registered into Victoire's widget registry, a Symfony Form type for the editor UI, and a Twig template rendered into a page slot. None of those concepts have a Laravel analogue. The nearest Laravel equivalents are a Blade component plus a Livewire/Filament block, or a JSON-backed block type in a custom page builder — all of which are reimplementations, not integrations.

Integration feasibility — effectively zero. composer require will resolve into victoire/* core, symfony/form, symfony/framework-bundle, and doctrine/orm under Symfony 2.7/3.x constraints. Laravel 9–11 pins Symfony 6/7 components (console, http-foundation, finder, process, mailer, etc.), so dependency resolution will either fail outright or force downgrades that break the framework. The package also ships no ServiceProvider, no publishable config, no Blade views, no Eloquent models, and targets PHP 5.5-era syntax that will throw deprecations or fatals on PHP 8.2+. There is no supported path to load this into a Laravel application.

Technical risk — the risk is the transitive graph, not the code. The widget itself is small and low-complexity: a handful of fields, a form, a template. The dangerous part is what it drags in: an unmaintained CMS core with no security response process, one release (2016-08-22), zero dependents, and zero stars. The low score (0.03) is a fair signal — this has no adoption, no maintenance signal, and no community. Vendoring the source read-only as a specification is low risk; adding it to the dependency graph is not.

Key questions

• What is the actual business need — a configurable "rich list" block in a page builder? If so, that is a days-scale native build, not a package decision.
• Is there an existing Victoire/Symfony footprint we are migrating off, or is this greenfield? This changes the work from "build a block" to "build a block + ETL existing widget rows."
• If Victoire data exists, what is the persisted shape (widget rows keyed by page/slot, Doctrine-mapped fields)? That, not the widget code, is the real migration unknown.
• What is the target UI stack — Blade, Livewire, Inertia+Vue, Filament? It determines the reimplementation shape.
• Is feature parity required, or is a simplified block acceptable?

Integration Approach

Stack fit — conceptual mapping only. The port is mechanical once mapped: widget entity → Eloquent model or a JSON column on a page_blocks record; Symfony Form type → FormRequest + Blade/Livewire form; Twig show template → Blade component; Victoire slot rendering → @include/<livewire:> inside the host page builder; widget registry config → a block-type registry array or Filament block class. Roughly a few hundred lines of translation.

Migration path — reference, not dependency. (1) Do not add the package to composer.json at any stage. (2) Snapshot the repo read-only as a spec artifact and record the commit. (3) Extract the field list, validation rules, and template markup as the acceptance criteria. (4) Implement natively as a first-class block. (5) If Victoire data exists, build an ETL from Victoire's widget tables into the new block schema before decommissioning the old CMS.

Compatibility — no overlap. Different PHP floor, different Symfony component majors, Doctrine vs. Eloquent, Twig vs. Blade, bundle/compiler-pass vs. service-provider lifecycle. Treat compatibility as "none" and plan accordingly rather than attempting shims.

Sequencing. Discovery and spec extraction → replace-vs-port decision (recommend replace) → block schema design → implementation → data migration if applicable → parity QA against the reference template → archive the reference copy with a note. The decision gate is early: keep the package out of the dependency graph entirely so no downstream work is contaminated by a doomed install attempt.

Operational Impact

Maintenance — zero upstream. No maintainer, no CVE intake, no PHP 8 or framework-version bumps, no issue triage. If forked, we own it permanently — for a component that is cheaper to rewrite than to steward.

Support — none. 0 stars, 0 dependents, single release. There is no community to escalate to and no internal precedent to lean on. Institutional knowledge will live entirely with whoever reads the source during the port.

Scaling — not a factor. This is a presentation widget; it has no meaningful performance or throughput profile. The only scaling consideration is the render path of whatever page builder replaces it, which is our design choice.

Failure modes. Composer resolution conflict or forced framework downgrade; runtime fatals on PHP 8 from 2016-era syntax; missing Symfony/Doctrine boot context inside Laravel; silent divergence if the Twig template is treated as a living spec; supply-chain exposure from an abandoned transitive graph; data loss or mangled markup if Victoire rows are dropped without an ETL.

Ramp-up — low for the build, moderate for the data. The widget surface is small enough that a developer fluent in both Symfony Forms/Doctrine and Laravel can fully internalize it in about a day. The real ramp cost is understanding Victoire's persistence model if a migration is in scope — budget there, not on the widget code.

Bottom line: this is not a Laravel package and should not be adopted as one. Its only defensible use is as a read-only reference specification for a native reimplementation; the integration effort is better spent building the block than fighting the dependency graph.