Shariff Bundle Laravel Package

Product Decisions This Supports

• Privacy-safe social sharing (GDPR/DSGVO posture). Shariff replaces the default share buttons (Facebook, Twitter/X, LinkedIn, etc.) with a two-click flow: the browser never contacts the social network until the user explicitly clicks, and share counts are fetched server-side by a proxy. This is a concrete, shippable privacy feature rather than a policy statement — useful if your marketing or legal team has committed to "no third-party trackers on first load."
• Build vs. buy for share buttons. The decision is not "which button library" but "do we proxy share counts ourselves, run a client-side-only solution, or drop counts entirely?" This package represents the proxy-server option; evaluating it forces a clear answer on whether share counts are a product requirement at all.
• Feature scoping for social distribution. If analytics show share buttons are a low-value surface, this is a cheap way to ship them without an ongoing privacy review, without a consent-banner dependency, and without negotiating a DPA with a social vendor.
• Roadmap input for a consent/CMP workstream. Shariff is a "privacy by architecture" pattern — it removes an entire category of cookies from your consent surface. That can simplify CMP configuration, reduce banner friction, and shrink the legal review scope for launch.
• Vendor and dependency risk triage. The package is archived (last release December 2021), has 4 stars and 0 dependents. As a PM this is a data point for your tech-radar and dependency-approval policy: it tells you the ecosystem around this integration point is thin, and the decision is really about adopting the pattern, not the artifact.

When to Consider This Package

Consider it only under narrow conditions:

• You run Symfony, not Laravel. This is a Symfony bundle (nucleos/shariff-bundle) wrapping the heise Shariff PHP library. It does not drop into Laravel. If your stack is Laravel, the honest answer is that this package is not a candidate — you would port the concept or use the underlying heise/shariff library behind a small custom endpoint.
• You need server-side share-count aggregation. The bundle's actual value is DI wiring, config, and a controller endpoint that proxies counts. If you only want privacy-friendly buttons with no counts, a few dozen lines of JS plus static SVGs gets you there with no dependency risk.
• You are willing to vendor or fork. Given the archive status, adopt it as a starting point with the assumption that you own maintenance. Pin the version, vendor the code, and budget for a security review of the transitive heise/shariff dependency.
• Privacy compliance is a hard, near-term requirement and you need something demonstrable for a launch or audit, not a perfect long-term platform.

Look elsewhere when:

• Anything in Laravel — no first-party equivalent exists; plan on a thin custom implementation.
• You need active maintenance, PHP 8.3+/Symfony 7 support, or a security-response commitment. Archived since 2021 means no patches, no compatibility guarantees, and no upstream to escalate to.
• Share counts are not a requirement. The proxy is the only part with real complexity; skip it and the whole evaluation collapses.
• You need rich per-network customization, analytics hooks, or A/B testable placement. The heise library is deliberately minimal and stylistically opinionated; heavy product requirements will fight it.

How to Pitch It (Stakeholders)

To executives: This is a small, well-understood pattern for adding social share buttons that do not hand user data to social networks on page load. It supports any public commitment we have made about trackers and cookie banners, and it removes a recurring legal review from the launch checklist. The specific package we evaluated is a Symfony bundle that has been archived since 2021 with negligible adoption, so I am not recommending we take it as a dependency. I am recommending we keep the pattern — server-side share-count proxy, two-click activation — as the reference design, and implement it in-house in roughly a week of engineering. That gives us the compliance benefit without inheriting an unmaintained third-party library.

To engineering: The bundle is a convenience wrapper around heise's Shariff PHP library — config, DI, and a count-fetching controller. It is Symfony-only and archived. For our Laravel services, don't try to adapt it; implement the same contract directly: a cached /shariff/counts endpoint that fans out to each network's count API with a short TTL and a hard timeout, plus front-end buttons that render an inert placeholder and only swap in the real network iframe/script after an explicit user click. That is the entire security-relevant behavior. Review the heise library's SSRF and caching behavior before copying its approach, and treat the count endpoint as untrusted-input-adjacent — it takes network identifiers from the client.

Bottom line for the decision log: Pattern approved, package rejected. Revisit if a maintained Symfony/Laravel integration appears; otherwise the in-house implementation is the lower-risk path.