Socialbuttons Widget Laravel Package

Product Decisions This Supports

• Feature scoping: social sharing buttons. The package's entire value proposition is rendering social share/follow buttons in a template. Treat it as a UI convenience, not a capability — it does not supply analytics, attribution, share-count APIs, or consent management, which is where the actual product decisions (and costs) live.
• Build vs. buy: strongly favors build. Social share buttons are link construction (encoded URL + title) plus markup. In Laravel/Blade this is a partial and a small helper — roughly half a day including tests, styling, and UTM tagging. The package cannot be "bought" in any meaningful sense: it is unmaintained free code with no vendor, SLA, or support path.
• Framework fit is a gating decision, not a detail. Despite being catalogued as a Laravel/PHP package, this is a Symfony bundle (WidgetSocialButtonsBundle) with Twig templates and a Symfony service container wiring. In a Laravel app it would need to be ported or wrapped, which removes the only reason to consider it — saved effort.
• Roadmap impact: negligible. Sharing buttons are table-stakes chrome. Nothing here differentiates the product, so it should not consume roadmap capacity beyond a single small story. Prioritize share destination coverage (which networks your audience actually uses) and consent/privacy behavior over widget sourcing.
• Supply-chain / maintenance budgeting. With 1 star, 0 dependents, no release since April 2019, and a low composite score (0.195), adopting it creates a permanent "who owns this?" line item. A PM should either fund an in-house replacement or explicitly accept the maintenance burden — not inherit it silently.
• Use cases where it could be rationalized: a legacy Symfony application already inside the FriendsOfVictoire ecosystem (e.g., existing Victoire CMS installs), or a short-lived marketing microsite where the bundle is already present and nothing new is being built.

When to Consider This Package

Consider it only if all of the following hold:

• The application is Symfony, already uses Twig, and is inside or adjacent to the Victoire CMS ecosystem where this bundle is a natural fit.
• Social buttons are already a solved problem on the current stack — i.e., you are maintaining an existing integration, not starting one.
• The requirement is genuinely static share links with no analytics, no GDPR/consent gating, and no server-side share counts.
• You have accepted that you own the code: no upstream fixes, no security patching, no PHP/framework compatibility guarantees for anything released after 2019.

Look elsewhere (or build in-house) when:

• The stack is Laravel. There is no Laravel service provider, no Blade views, no published config. Framework mismatch alone disqualifies it against a same-day in-house implementation.
• You need maintained dependencies. A 2019 release predates modern PHP and Symfony major versions; compatibility testing will likely cost more than writing the component.
• Compliance matters. Share buttons are a classic third-party-request and tracking vector. A package this small and this stale will not give you the consent hooks, CSP friendliness, or self-hosted asset story you need.
• You need support or an SLA. There is no vendor, no maintainer commitment implied by activity, and effectively no community to escalate to (1 star, 0 dependents).
• You would prefer a vetted alternative. For Laravel, evaluate maintained sharing packages (e.g., actively released social-share or laravel-social-share-style libraries) or a first-party Blade partial; for either framework, a JS-based solution (Web Share API with a link fallback) is often a better product answer than server-rendered buttons.

How to Pitch It (Stakeholders)

Bottom line: do not adopt. Build the widget in-house.

The candidate is a Symfony Twig bundle for rendering social share buttons. It has 1 GitHub star, 0 dependent projects, a low quality score (0.195), and no release since April 2019 — over six years of inactivity. It is also the wrong framework for our Laravel codebase, so "using" it would mean porting it, which erases the only benefit it offers.

For executives: the feature is small and undifferentiated — sharing buttons are standard chrome, not a competitive lever. The real cost of this package is not the license (free) but the ownership: an unmaintained third-party component in the UI layer that we would have to patch, audit, and eventually remove. Committing roughly half a day of engineering to a first-party Blade partial is cheaper than the lifetime cost of carrying dead code, and it keeps our dependency surface clean.

For engineering: the package provides template markup and container wiring for share links — nothing we can't reproduce in a partial plus a URL-encoding helper. Building it gives us control over which networks we support, UTM/campaign tagging, consent gating, CSP-safe assets, and test coverage. It also avoids introducing a Symfony bundle into a Laravel app, which would otherwise require either a port or an awkward compatibility layer.

Recommended decision: close the evaluation, log a small story for an in-house sharing component, and revisit only if a maintained, framework-appropriate library emerges with real adoption and recent releases.