Sharethis Widget Laravel Package

Technical Evaluation

Architecture fit — poor. Despite the "Laravel/PHP package" framing, friendsofvictoire/sharethis-widget is not a Laravel package at all. It is a Symfony bundle (WidgetShareThisBundle) built specifically for Victoire DCMS, a Symfony-based CMS. Its structure follows Symfony conventions that Laravel has no analogue for:

• DependencyInjection/ extension + Configuration classes for XML/YAML service wiring
• Resources/config/ service definitions
• Widget/ classes extending Victoire's BaseWidget contract, coupled to Victoire's WidgetType form abstraction and Twig rendering pipeline
• Service tags that only Victoire's widget registry understands

None of this resolves through Laravel's container. There is no service provider, no facade, no config publish path, no Blade views. Installing it via Composer would autoload classes that cannot be instantiated outside a Victoire kernel.

Integration feasibility — trivial to reimplement, non-trivial to adopt. The functional payload is a ShareThis embed: a <script> tag referencing platform-api.sharethis.com/js/sharethis.js with a property ID, plus inline share-button markup (.sharethis-inline-share-buttons) and optionally a small config block for display options. That is roughly 30–60 lines of markup and configuration. A Laravel equivalent is a Blade component plus a config/sharethis.php entry — on the order of half a day to one day including tests, styling hooks, and consent gating. There is no server-side logic, no data model, no queueing, no API client to port.

Technical risk — high, concentrated in abandonment and compliance.

Key questions for the business and engineering leads:

1. Is ShareThis still the strategic sharing vendor, or is this requirement legacy carry-over? If the latter, evaluate native share sheets (navigator.share) plus a lightweight first-party set of links before committing to any vendor SDK.
2. Do we need server-side share counts or analytics, or is render-only acceptable? ShareThis exposes counts, but only via their API — we would build that client ourselves; the bundle provides none of it.
3. What is the consent posture? If we operate in GDPR jurisdictions, the component must be behind our CMP with deferred script injection. Confirm whether that is a hard requirement before scoping.
4. Is there any Victoire-based property in our estate that would actually consume this bundle? If not, the package is entirely irrelevant to our stack and the evaluation ends here.

Verdict: Do not adopt. The package's only reusable asset is design intent. Treat this as a build-vs-buy decision where "build" costs under a day and "buy" imports nine years of unmaintained Symfony-specific code into a Laravel codebase.

Integration Approach

Stack fit — no direct fit; port the concept, not the code. Target implementation in Laravel:

• app/View/Components/ShareThis.php — a class-based Blade component accepting propertyId, layout, networks, and enabled props
• resources/views/components/share-this.blade.php — renders the container <div class="sharethis-inline-share-buttons"> and the deferred script tag
• config/services/sharethis.php — property ID and per-environment enablement, sourced from env vars, never hardcoded
• Optional ShareThisConsent gate: a @once-guarded script loader that renders only when the consent cookie/state permits

If the consumer is a Filament or custom admin CMS, wrap the component as a reusable block/field type rather than porting Victoire's Widget/WidgetType pair — Filament's block and form builder abstractions occupy that role.

Migration path — greenfield, since there is nothing to migrate from. If a Victoire site is being re-platformed to Laravel, extract only:

1. The ShareThis property ID and any custom display options from the Victoire widget instance configuration
2. Any network ordering or styling overrides
3. The set of page templates where the widget is placed

Discard the PHP entirely. Map widget placements to Blade @include/component calls at the corresponding layout positions.

Compatibility — assume incompatible until proven otherwise. Before any code is written, run a five-minute check: composer require friendsofvictoire/sharethis-widget --dry-run against the target PHP version. Expect constraint failures. Even on a hypothetical compatible PHP, Symfony\Component\HttpKernel\Bundle\Bundle and Victoire's widget interfaces will not resolve without victoire/widget-bundle and a Symfony kernel. There is no Laravel bridge, no illuminate/support dependency, and no reason to expect one.

Sequencing:

1. Day 0 — kill check. Confirm vendor strategy and consent requirements. If ShareThis is not confirmed strategic, exit here and evaluate native sharing.
2. Day 1 — spike. Build the Blade component and config. Verify the property ID renders correctly across desktop and mobile against the current ShareThis JS API.
3. Day 2 — consent. Wire the component behind the CMP. Test the no-consent path renders zero third-party requests in DevTools' network panel and in a CSP report.
4. Day 3 — hardening. Content Security Policy entries for platform-api.sharethis.com and platform-cdn.sharethis.com; defer/async attributes; SRI if the vendor publishes hashes.
5. Day 4 — observability. Add a lightweight client-side event or beacon to detect script load failure, since the vendor provides no server-side signal.
6. Rollout behind a feature flag, one template family at a time.

Operational Impact

Maintenance — near zero code maintenance, ongoing vendor vigilance. The in-house component is small enough that it will not rot, but it inherits a permanent third-party dependency. Assign explicit ownership for monitoring ShareThis platform changes and for the annual consent/vendor review. Do not create a fork of the original bundle under any circumstances — a fork of a 2016 Symfony bundle is a maintenance liability with no upside.

Support — none from the package. No maintainer activity since 2016, no issue triage, no security advisories, no changelog, no upgrade guide. Any defect we encounter is ours to fix. This is acceptable only because we are not shipping their code.

Scaling — effectively free. Rendering is a handful of HTML nodes and one deferred script. There is no server-side work, no database, no cache dependency, no queue. Page weight and TTFB impact are bounded by the vendor's CDN; measure with and without the script on a mid-tier mobile profile, as ShareThis's JS bundle is not small and competes with LCP.

Failure modes:

The critical design decision: the fallback links are non-negotiable. Because both the abandoned package and the vendor offer no failure signal, a progressive-enhancement layer is the only thing standing between a vendor hiccup and a silent product regression.

Ramp-up — negligible for engineers, non-trivial for compliance. A Laravel developer unfamiliar with ShareThis can read the component and understand it in under fifteen minutes; there is no domain knowledge to acquire because the original package contains none worth transferring. The real onboarding cost sits with legal/privacy: vendor classification, DPA status, data-transfer mechanism, and consent-category assignment. Budget more time for that review than for the build.

Bottom line: the package is a non-starter for a Laravel stack and unnecessary even for its native Symfony/Victoire context. Reimplement as a small, consent-aware Blade component with server-side fallback links; treat ShareThis itself, not this bundle, as the dependency requiring governance.