Share Laravel Package

Getting Started

The package exposes a chainable builder for generating social-share URLs. It does not render share buttons for you by default—it gives you the URLs (and optionally a view you can style), so treat it as a URL generator, not a UI kit.

Install

composer require chencha/share

The latest release is 6.1.0, whose headline change is Laravel 9.x compatibility. If you're on Laravel 9, pin to that line explicitly so you don't resolve back to an older constraint:

composer require chencha/share:^6.1

Laravel 5.5+ auto-discovers Chencha\Share\ShareServiceProvider. On older versions, register the provider in config/app.php and add the Share alias from the package's facade.

Publish config (if the tag exists)

php artisan vendor:publish --tag=share

This typically lands a config/share.php describing enabled networks and any default parameters. Check config/share.php first—it is the single most useful file to read because it tells you which networks the package actually supports out of the box and how each one's URL template is built.

First use case — render share links on a blog post or product page:

use Chencha\Share\Share;

$links = Share::page(
        route('posts.show', $post),
        $post->title,
        ['description' => $post->excerpt]
    )
    ->facebook()
    ->twitter()
    ->linkedin()
    ->getRawLinks();

getRawLinks() returns an associative array keyed by network, which is easy to loop in Blade:

@foreach ($links as $network => $url)
    <a href="{{ $url }}" target="_blank" rel="noopener">{{ ucfirst($network) }}</a>
@endforeach

Where to look first:

1. config/share.php — supported networks and templates.
2. The Share facade's page() signature — it defines which parameters (URL, title, description, image, hashtags) are actually forwarded per network.
3. The src/ providers for each network — small classes that build the URL; this is where you go when a template is wrong or a network is missing.

Implementation Patterns

Controller-built links, Blade-rendered. Build the link set in the controller (or a view composer) and pass a plain array of ['network' => 'url'] to the view. This keeps Blade free of the facade and makes the output easy to cache or JSON-serialize for a SPA.

View composer / dedicated partial. If share links appear on every article, register a view composer so the $shareLinks variable is always present:

View::composer('partials.share', function ($view) {
    $view->with('shareLinks', Share::page(
        url()->current(),
        $view->getData()['metaTitle'] ?? config('app.name')
    )->facebook()->twitter()->whatsapp()->getRawLinks());
});

Conditional networks. Only call the networks you actually want. The builder is additive—->facebook() doesn't disable others—so a config-driven list works well:

$share = Share::page($url, $title);
foreach (config('app.share_networks') as $network) {
    $share->{$network}();
}
return $share->getRawLinks();

Validate config('app.share_networks') values against the supported set to avoid exceptions from unknown method calls.

Per-network parameters. Networks differ in what they consume. Twitter/X uses text + hashtags; Facebook uses u only; LinkedIn uses url and sometimes title/summary. Pass the superset of parameters to page() and let each connector pick what it needs—don't try to micromanage per call unless you have a real reason.

Tracking and UTM. Because each share URL is a plain string, you can append tracking parameters to the shared URL before passing it in:

$tracked = $url . '?' . http_build_query(['utm_source' => 'facebook']);

Beware: some networks re-encode the URL, so test that your query string survives (see Gotchas).

Custom network. If the package exposes a base class or a registry in config/share.php, add a network by creating a class that builds the share URL from the parameters. Otherwise, the pragmatic fallback is to generate it yourself and merge:

$links = Share::page($url, $title)->facebook()->twitter()->getRawLinks();
$links['mastodon'] = 'https://mastodon.social/share?text=' . urlencode($title . ' ' . $url);

Testing. There's no Share::fake(); test the real thing. Assert that the returned URL contains the encoded target and the expected host:

$url = Share::page('https://example.com/p/1', 'Hello')->facebook()->getRawLinks()['facebook'];
$this->assertStringContainsString('facebook.com/sharer', $url);
$this->assertStringContainsString(urlencode('https://example.com/p/1'), $url);

Gotchas and Tips

Version constraints by Laravel version. 6.1.0 brings Laravel 9.x support (the previous line was 6.0.1). That's the ceiling tested by the maintainers—do not assume Laravel 10/11/12 works. Check composer.json before installing; if the constraint blocks you on a newer framework, try composer require chencha/share:^6.1 -W, and if it still won't resolve, vendor the small amount of code you actually need. The package is small enough that copy-paste is a legitimate escape hatch.

Know which repo you're reading. The Composer package name is chencha/share and the namespace is Chencha\Share, but the GitHub project lives under prodeveloper/social-share. When you're chasing an issue, a PR, or the changelog, search the repo name, not the Packagist name—otherwise you'll land on the wrong project or an abandoned fork.

Low adoption, so read the source. With zero dependents and modest stars, there is little community knowledge to lean on. A release that only bumps framework compatibility is a signal the package is maintained reactively rather than actively—so when something is off (a stale URL template, a network that changed its share endpoint), open the connector class and patch it locally or submit a PR; don't assume the package is current with each platform's API.

Stale network templates. Social share endpoints change silently. If a link opens the wrong page or 404s, compare the generated URL against the network's current share documentation—this is the most common real-world failure with any share-link package, and compatibility-only releases won't fix it.

URL encoding. The builder should urlencode for you, but nested URLs (Facebook u=, LinkedIn url=) are double-encoded by some connectors. If the shared page misses its query string, that's the first thing to check. Don't pre-encode before passing to page().

Double-encoded titles. Unicode titles (apostrophes, emoji) are a common break. Pass raw strings and let the package handle encoding; if it doesn't, htmlspecialchars_decode() on the way in often fixes mangling.

Config cache. If you edit config/share.php, run php artisan config:clear (or config:cache in production) or your changes won't apply.

Facade alias on older Laravel. If you get "Class 'Share' not found," the alias isn't registered. Add 'Share' => Chencha\Share\Facades\Share::class to config/app.php under aliases.

Rendering vs raw URLs. If the package provides a render() or Blade helper, it produces unstyled markup—plan to override the view or ignore it and render your own <a> tags. getRawLinks() is usually the safer default because it keeps markup, accessibility, icons, and analytics in your control.

Upgrade hygiene. Before bumping to 6.1.0, skim the diff on the connector classes and the service provider—a compatibility PR can quietly touch the provider's bindings or the illuminate/support floor. Run your share-link tests (the assertion pattern above) after the bump; that's cheaper than discovering a broken URL in production.

Mobile-only networks. WhatsApp and Telegram share links behave differently on desktop (WhatsApp shows a QR/web fallback). Hide those buttons on desktop or keep them as a secondary "more" menu.

Open Graph is doing the real work. The share URL only tells the network what to share; the preview comes from your page's og:title, og:description, og:image, and og:url. Verify with each platform's debugger (Facebook Sharing Debugger, LinkedIn Post Inspector) before you blame the package for an ugly preview.

Cache the result if hot. Building URLs is cheap, but if a page with share links is cached, remember the URL embeds the canonical page URL—regenerate on deploy or when routes change, and invalidate when the title changes.

Security. Always render with rel="noopener noreferrer" and target="_blank"; the URLs are attacker-influencable only insofar as the page URL is, but if you reflect user-supplied titles, escape them in the title attribute or keep them out of href entirely (they only live inside the share URL, so urlencode handles it).