Text Widget Laravel Package

Product Decisions This Supports

• Stack-fit gatekeeping. Despite the "Laravel/PHP" catalog label, friendsofvictoire/text-widget resolves to WidgetTextBundle, a Symfony bundle for Victoire CMS. It is a decisive "no" for any Laravel roadmap item and a useful forcing function to validate framework compatibility before evaluating a package's features.
• Build vs. buy for page-builder content blocks. The package represents the "borrow" option for a single commodity primitive: an editable rich-text block. The PM call is whether a text widget warrants any external dependency. In most stacks it is a one-to-two-day native component (model, migration, Blade/Twig partial, admin field), which usually wins.
• Ecosystem lock-in assessment. Adoption couples you to Victoire's widget registration, templating, admin conventions, and Doctrine persistence. That is a platform-level commitment, not a feature decision, and belongs in CMS roadmap discussions rather than a single ticket.
• Maintenance-risk signal for the roadmap. Zero stars, zero dependents, and a low opportunity score (18.26) are a proxy for negligible community validation and no maintainer bandwidth. This supports a standing policy of "no new adoption" and, where already present, a replace-with-internal-component backlog item.
• Legitimate use cases it still serves. A Victoire-based site needing a configurable text block (title + body + formatting) inside the page editor, or a legacy FriendsOfVictoire Symfony application where consistency with existing widgets outweighs novelty. In those contexts it is a known, understood surface — not a new investment.

When to Consider This Package

Consider it only when all of the following hold:

• You run Symfony, specifically a Victoire CMS application, and need the canonical text widget to match existing widget behavior in the editor.
• You are maintaining or extending an existing Victoire installation where the bundle is already a transitive or explicit dependency. In that case, understand and isolate it — do not treat it as new investment.
• Your requirement is genuinely narrow: a static/rich-text content block, with no need for structured content modeling, versioning, collaboration, or headless delivery.
• You accept that upstream is dormant and you are prepared to own a permanent fork against EOL Symfony branches if anything breaks.

Look elsewhere — or build in-house — when:

• You are on Laravel or any non-Symfony framework. There is no integration path worth the effort: the mismatch spans container/DI, templating (Twig vs. Blade), and persistence (Doctrine vs. Eloquent), and solving one layer does not reduce the cost of the other two.
• You need a modern editing experience — block-based editing, embeds, media, collaboration. Compare against maintained editor libraries and headless CMS APIs instead.
• You require active maintenance, security patching, or vendor support. Zero adoption and a dormant upstream mean any transitive CVE is yours to carry.
• You need multilingual content, workflow/approval, or content API access — this package does not address those.
• You are greenfield. A text widget is small, well-understood, and cheaper to own than to inherit.

How to Pitch It (Stakeholders)

One-line summary: friendsofvictoire/text-widget is a small Symfony bundle providing a text widget for the Victoire CMS page builder; it is not a Laravel package and not a candidate for new adoption.

For executives: This is a low-risk, low-value component with no measurable traction — 0 stars, 0 dependents, low opportunity score (18.26) — and a dormant upstream that pins to end-of-life Symfony branches. It does not justify a platform bet. Recommendation: do not introduce it. Where it already exists, plan a low-effort replacement with an internally owned component to remove dependency and security-patching exposure.

For engineering: It is a Symfony/Victoire-coupled bundle, not framework-agnostic. It solves one narrow problem — rendering a configurable text block in a page builder — and brings Victoire's widget conventions, Doctrine entities, and Twig templates with it. Replicating the functionality natively (Eloquent model, migration, Blade component, admin field) is roughly one engineer-day, which eliminates the lock-in and maintenance risk entirely. The bundle's templates are the only genuinely reusable asset; treat them as a design reference, not a runtime dependency. No action required unless we are already inside the Victoire ecosystem, in which case scope it as legacy surface area isolated behind our own abstraction, with a one-time content export rather than a runtime bridge.

Decision requested: Confirm "no new adoption" as the standard, and — if applicable — approve a small backlog item to replace or wrap any existing usage.