Socialpage Widget Laravel Package

Product Decisions This Supports

• Build vs. buy (and the answer is usually “build”): This package scopes to a single CMS page-builder widget for rendering social page links. That is a template fragment, not a product capability. The decision it most usefully informs is whether a social-links block is worth any third-party dependency at all — for most teams it is a few hours of in-house Twig/HTML, so “buy” carries more risk than it removes.
• CMS editability for marketing-owned content: If you are already on Victoire DCMS, it supports a low-effort roadmap item — letting non-engineers drop a social-presence block into pages without a deploy. That is a quick win, not a differentiator.
• Opportunity sizing: Treat this as a non-investment. There is no analytics, no platform API integration, no oEmbed, no share-count or consent handling — just link rendering. It should not appear on a roadmap as a feature bet.
• Reference architecture, not a runtime dependency: Its most defensible PM use is as a worked example of how Victoire widgets are packaged (bundle structure, widget registration, DI wiring) if your team is authoring its own widgets.
• Risk register input: 1 star, 0 dependents, last release 2016-08-22 places this firmly in the abandoned-dependency category. That is a decision to avoid, and the assessment should be recorded as such so it does not resurface in future build-vs-buy debates.

When to Consider This Package

Consider it only when all of the following hold:

• You are already running Victoire DCMS on Symfony, and the widget is being added to an existing site rather than a new build.
• Your Symfony/PHP versions are compatible with 2016-era code — in practice this means an older Symfony 2.x/3.x runtime. Modern Symfony and PHP 8 will almost certainly break it.
• The requirement is strictly “render a configurable set of social links in a page,” with no dynamic behavior.
• You are prepared to vendor or fork it, own the code internally, and accept that there will be no upstream fixes or security patches.

Look elsewhere (or build in-house) when:

• You are on any stack other than Victoire — there is no portability here.
• You need anything beyond static links: current X/Twitter and Facebook Graph API behavior, oEmbed, share counts, click analytics, GDPR/consent-aware embeds, or accessibility guarantees.
• You require active maintenance, a security response path, or community support. One star and zero dependents means no community to lean on.
• You are starting a new product. A dependency that has been stale for roughly nine years is a liability with a near-zero payoff.

Default recommendation: do not adopt. Reimplement the widget in-house (hours, not days) or use a maintained, framework-agnostic social-links component.

How to Pitch It (Stakeholders)

To executives: This is a small, tactical UI component for one niche CMS, not a strategic capability. It has had no releases since 2016 and no downstream users, which means adopting it adds maintenance and security risk while saving only a few hours of work. The right call is to treat it as a reference, not a purchase or dependency.

To engineering: A single Symfony bundle that registers a Victoire widget for social page links. It is effectively unmaintained, pinned to an older Symfony generation, and has no test or security posture we can rely on. Recommendation: reimplement the widget internally as a small Twig partial with a config-driven link list — cheaper to own, easier to extend for consent, accessibility, and analytics, and it removes an abandoned dependency from our surface area. If we are forced to use it inside an existing Victoire install, fork and vendor it with a named internal owner.