Button Widget Laravel Package

Product Decisions This Supports

• Editorial tooling gap-filling (only if you run Victoire CMS). This is a single-purpose widget that lets content editors drop a call-to-action button into a page — label, link, target — through Victoire's widget picker and inline editing. The decision it supports is "can marketing build a landing page with CTAs without filing a ticket?" If the answer today is no, this closes a small but visible gap.
• Build vs. buy (and the answer leans "build"). A button widget is a Twig template plus a Symfony form type and a widget registration. The genuine value here is not the code volume — it is the convention adherence to Victoire's widget lifecycle (edit form, rendering, inline edit mode, style variants). That convention is worth copying; the package itself is arguably not worth depending on. Reasonable PM framing: 1–2 days of engineering to implement a house-owned widget with your design-system classes versus adopting an unmaintained third party.
• CMS/vendor selection as an input, not a decision. The existence of a per-widget bundle ecosystem (WidgetButtonBundle, text, image, etc.) tells you something about Victoire's architecture: composable, granular, and also fragmented. A PM evaluating Victoire should read this as a signal about ecosystem maintenance burden — you are assembling a CMS from many small, individually-published parts, most with single-digit or zero adoption.
• Roadmap: not a differentiator. Nothing here creates product advantage. If someone proposes it as a feature, the correct response is that buttons are commodity UI; the differentiator is the surrounding page-composition and publishing workflow.
• Use case fit: brochure/marketing sites on Symfony where editors need CTAs, hero links, and campaign buttons. Poor fit — near zero — for application UI, Laravel projects, or anything with a design system that mandates specific button semantics.

When to Consider This Package

• You are already running Victoire CMS on Symfony and want a CTA button type available to editors with the least possible integration work.
• You need a throwaway or internal build where a zero-star dependency is an acceptable risk because the blast radius is one widget.
• You want a reference implementation of Victoire's widget contract before writing your own — reading the source is more valuable than installing it.

Look elsewhere (or build in-house) when:

• You are on Laravel. This is a Symfony bundle, not a Laravel package. There is no adapter, no service provider, no Blade equivalent. This is a categorical mismatch, not a porting inconvenience.
• You need maintenance assurance. Zero stars, zero dependents, and an effectively dormant upstream means no security response, no Symfony major-version compatibility guarantees, and no community answers. Do not put this on a critical path.
• You need accessibility or design-system conformance — proper focus states, aria semantics, disabled/loading states, or your own token-based class names. You will end up overriding or rewriting the template anyway.
• You need analytics instrumentation, A/B variants, or CMS-managed targeting on CTAs. This widget will not carry that payload; a custom widget or a component in your front end will.
• You are evaluating CMSes from scratch. Weight the ecosystem's health as a whole, not this bundle in isolation — and note that a zero-adoption widget is a data point about the whole.

How to Pitch It (Stakeholders)

For executives (one line): A small, free plugin that lets content editors add call-to-action buttons in our CMS without engineering involvement — low cost, low risk, but also low strategic value, and it comes with no vendor support.

For engineering (the honest version): friendsofvictoire/button-widget is a Victoire CMS widget bundle providing a button type for the page editor. Zero stars, zero dependents, no active maintenance. It is not a Laravel package and offers nothing to a non-Victoire stack.

Recommendation: Treat it as a reference, not a dependency. If we are on Victoire, spend the day to implement a house-owned button widget modeled on this one — it gives us our design-system classes, accessibility semantics, and analytics hooks, and removes an unmaintained dependency from our tree. If we are not on Victoire, close the ticket: there is no decision here to make.