Poll Widget Laravel Package

Technical Evaluation

Architecture fit. Poor as a direct dependency. Despite being catalogued under a Laravel/PHP search, friendsofvictoire/poll-widget is a Symfony bundle (WidgetPollBundle), not a Laravel package. It is a Victoire CMS extension: it registers a widget type against Victoire's WidgetBundle, depends on Symfony's DI container, Twig rendering, Doctrine ORM entities, and Victoire's widget/annotation discovery conventions. None of those primitives map onto Laravel's service container, Blade, or Eloquent. There is no ServiceProvider, no config/poll.php, no publishable assets, and no Laravel-facing API surface.

Integration feasibility. Effectively zero without either (a) running a Symfony kernel inside the Laravel process (FrankenPHP-style dual-framework bootstrapping, high cost, high risk), or (b) treating the repository as reference source code rather than a dependency. The only realistic use is as a spec: a Poll entity, option/choice records, a vote action, and a results view — roughly 200–400 lines of domain logic to reimplement natively.

Technical risk. High and largely unpriced by the ecosystem. Last release 2016-10-07 places it in the Symfony 2.8/3.0 era (PHP 5.5–7.0 assumptions), predating Symfony 4's bundle simplification, the Flex recipe system, Doctrine annotation deprecation, and PHP 8 typed-property/Stringable changes. It has 1 star, 0 dependents, and no dependents in the graph, meaning no downstream project is exercising it, no compatibility reports exist, and no CVE watchers are tracking it. A 0.165 score is consistent with "archived in all but name." MIT licensing is the one favourable signal — forking and vendoring are legally clean.

Key questions.

• Is Victoire CMS actually part of the target stack, or was this surfaced by a generic PHP package search? (If the former, the whole Laravel framing is wrong; if the latter, the package is a false positive.)
• Does the product requirement need a poll widget or this poll widget's specific behaviour (multi-choice? anonymous voting? results gating?) — the latter determines whether a port is a day or a week.
• Who owns the forked code if we proceed, and what is the deprecation path when PHP 8.x/9.x breaks it further?
• Is there a maintained alternative (Laravel-native poll/voting packages, or a straightforward in-house build) that clears the same requirement at lower total cost?

Integration Approach

Stack fit. Mismatched on every layer: Symfony DI vs. Laravel container, Twig vs. Blade, Doctrine annotations vs. Eloquent attributes, Victoire's widget registry vs. Laravel's view composers/Livewire components. Assuming a modern Laravel baseline (PHP 8.1+, Laravel 10/11), the bundle's Composer constraints will almost certainly conflict before autoloading is even attempted.

Migration path. Do not attempt composer require. Instead:

1. Clone and read the bundle to extract the domain model — schema for polls, options, and votes; uniqueness rules (one vote per user/session/IP); result aggregation logic.
2. Reproduce as Laravel migrations + Eloquent models (Poll, PollOption, PollVote), with a unique composite index on (poll_id, voter_key) to enforce deduplication at the database layer.
3. Implement vote submission as a form request + controller action (or a Livewire component if the widget is interactive), with rate limiting via Laravel's RateLimiter.
4. Render results in Blade; cache tallies in the cache store and invalidate on write to avoid COUNT(*) on every page view.

Compatibility. Treat the original as incompatible by default. Verify PHP version guards, Symfony API usage, and Twig syntax against the target runtime only if a dual-framework spike is genuinely on the table — and scope that spike to a strict timebox, because the expected outcome is "port it."

Sequencing. (1) Confirm whether Victoire is in scope at all — this gates everything. (2) If not, timebox a half-day source read to capture behavioural requirements. (3) Build native, behind a feature flag, with the poll widget as an isolated module. (4) Ship with tests covering duplicate-vote rejection and concurrent-write behaviour, which the original almost certainly does not have.

Operational Impact

Maintenance. The package is unmaintained with no release in roughly nine years. Choosing it means inheriting ownership of the code permanently — there is no upstream to pull fixes from, and any fork we create becomes our own long-tailed liability with no external contributors. Contrast with a native implementation: a few hundred lines we wrote, in a framework our team already operates.

Support. No vendor, no SLA, no issue triage. Documentation is limited to whatever Victoire's own docs cover; the bundle itself is a thin extension with minimal standalone guidance. Bus factor is effectively one historical author plus zero active users.

Scaling. Poll widgets are write-heavy and read-heavy at the same time: votes are small frequent writes, results are frequently-read aggregates. Any production use needs a deduplication constraint, rate limiting, and a cached tally layer — none of which a 2016 CMS widget provides. Unbounded vote tables without a uniqueness index are a straightforward ballot-stuffing vector.

Failure modes. Expect: Composer resolution failure against modern Symfony/PHP constraints; fatal errors from removed Doctrine annotation reader APIs on PHP 8; Twig syntax incompatibility; silent autoload failures because no Laravel discovery hook exists; and — most dangerous — a partial install that appears to work in a dev environment before failing under the Symfony kernel assumptions the widget makes at render time.

Ramp-up. Low if the decision is "read and reimplement" — a mid-level Laravel engineer ports this in one to three days including tests. Very high if the decision is "make the bundle run under Laravel," which requires Symfony kernel expertise and yields a fragile, unmaintainable hybrid. The asymmetry strongly favours the port, and the 0.165 score, single star, zero dependents, and 2016 release date all point the same direction: use as reference, not as dependency.