Socialize Laravel Package

Getting Started

This is the initial 1.0.0 release, so there is no migration path — treat the whole surface area as new.

1. Install with composer require and confirm the service provider is auto-discovered. If it is not, register it in bootstrap/providers.php (Laravel 11+) or config/app.php.
2. Publish the config and views first: php artisan vendor:publish --provider="Vendor\Share\ShareServiceProvider". The published config is the source of truth for which networks are enabled — read it before writing any markup, because the enabled/disabled list is what actually drives rendering.
3. Read the published Blade view next. At 1.0.0 the package is small enough that the view is the documentation for the output markup, classes, and attributes.
4. First use case: drop a share row onto a public content page — a blog post, product page, or changelog entry — where the URL and title are known server-side. Render it once on a detail page, not in a loop, to confirm the anchor markup and target/rel behaviour before rolling it out.

Minimal first render: enable only twitter, facebook, and email in the config, then include the package's share component/directive in the show view, passing the model's canonical URL and title. Verify the generated href values in the HTML source rather than trusting the visual output.

Implementation Patterns

Single component per content type. Wrap the package's output in your own Blade component (<x-share-links :model="$post" />) so the third-party markup appears in exactly one place. When the package changes its markup or you swap it out, you edit one file instead of every view.

Build the share payload from the model, not the request. Derive url from a canonical accessor (route('posts.show', $post)) rather than request()->fullUrl(). Share links with query strings, tracking params, or pagination fragments fragment your analytics and confuse the receiving network.

Config-driven network sets. Define named sets (social, minimal, internal) in config/share.php and select one at render time. Marketing wants the full row on landing pages and a single Email link inside the authenticated app — modelling that as config beats conditionals scattered through Blade.

Layout variants. Expect to render the same links three ways: a horizontal row under article content, a compact icon strip, and a sticky vertical bar on mobile. Keep the package's default markup for the row and override the view (once published) for the variants, rather than duplicating anchors.

UTM and attribution. If you append utm_source per network, do it in a wrapper that maps network key → source value. Do not let the package's url parameter and your tracking decorator both encode the URL — encode once, at the end.

Feature-flag the email button. mailto: shares are the one network here that can leak a subject line from internal titles. Gate the email button behind a config flag and default it off in authenticated areas.

Testing. Assert on the rendered output with assertSee against the encoded share URL for one network, plus a count assertion on the number of share anchors. That catches both broken URL encoding and accidental duplicate rendering when a component gets nested inside a loop.

Analytics hooks. Because these are plain links, client-side click tracking is a delegated listener on a stable wrapper class you control — not on the package's internal class names, which you do not own at 1.0.0.

Gotchas and Tips

• URL and text encoding is the number one failure mode. Titles with &, #, apostrophes, or emoji break href attributes and silently truncate the shared message. Always pass an already-encoded URL and let the package handle the text; if you must encode yourself, encode exactly once. Test with a title containing & and '.
• No share counts. None of these three networks exposes a usable public count endpoint anymore, and this release does not claim to. Do not plan UI around a number badge.
• target="_blank" without rel="noopener noreferrer" is a real security and performance issue. Confirm the published view includes it; if not, add it in your own override.
• Config caching. After editing the enabled-network list, run php artisan config:clear locally. A stale cached config is the usual reason a newly enabled network "doesn't appear."
• Published views shadow package views. Once you publish, upgrades to the package's Blade file will not reach you. Keep a note of the published view and diff it against the vendor copy after each release — this is the most likely source of silent breakage in a 1.x upgrade.
• CSP and inline handlers. If the package ships any inline onclick for popups, it will fail under a strict Content-Security-Policy. Prefer the plain-anchor mode; the popup behaviour is not worth loosening script-src for.
• Email sharing is a mailto: link, so it inherits the OS mail client, has practical length limits on subject and body, and cannot be styled or tracked reliably. Do not treat it as equivalent to a web share.
• Share buttons are downstream of Open Graph tags. Every network here reads the target page's og:title, og:description, and og:image. If previews look wrong, the bug is in your <head> or your canonical URL, not in this package. Verify with each network's own debugger before filing anything.
• Pin the version. At 1.0.0 the public API — method names, config keys, component signature — is still settling. Use ^1.0 at minimum, and re-read the release notes before any minor bump, since a first-major package may still adjust its config shape.
• Extension point: if a network you need is missing, prefer adding a new entry to the config/network map over forking the package. The three supported networks share a single URL-template shape, so an extra entry is usually a config line rather than code.