Social Media Image Kit Laravel Package

Product Decisions This Supports

• Social/OG image generation as a product surface, not a task. The package lets you define templated social share images (Open Graph/Twitter cards) rendered from your content, which turns "we need better link previews" from an engineering backlog item into a design/config exercise. Decisions it informs: whether to standardise share imagery across the site, how much brand consistency matters in distribution channels, and whether share-image quality is a lever worth investing in for CTR and referral traffic.
• Roadmap: distribution and content amplification features. v1.4.0's augmented entry support (other relations and tags) materially widens what templates can express — images can now pull taxonomy terms, related entries, and relational data into the composition. That supports roadmap items like per-category or per-tag branded imagery, author/contributor cards, series or collection artwork, and segmented campaigns without one-off engineering work per variation.
• Editorial autonomy and content-ops headcount. The new Recreate action in the Control Panel means editors can regenerate an image after changing a headline, image, or tag set without filing a ticket or waiting on a deploy. This is a direct input to decisions about content-ops staffing, publishing SLA targets, and how much of the publishing workflow can be owned by non-technical users.
• Platform upgrade timing (Statamic 6). Support for Statamic 6 installs converts an otherwise blocked CMS upgrade into a viable option. If a Statamic 6 upgrade is on the roadmap, this release removes one dependency-level objection — useful for sequencing the upgrade and for negotiating scope with engineering.
• Build vs. buy. The alternative is a bespoke renderer (headless browser/screenshot service, image compositing service, or a CDN-side image API). Buying/adopting is defensible when share images are templated and content-driven; building is defensible when you need dynamic asset pipelines or non-CMS sources.
• Template design and brand governance decisions. Because output is defined in templates against entry data, design owns the visual system and product owns the rules (which content types get which template, fallbacks when no image exists). Use cases: default site card, per-section cards, per-tag cards, event/product/listing cards, contributor cards.

When to Consider This Package

Adopt when most of the following hold:

• You are on Statamic (v6 supported as of v1.4.0; earlier versions presumably still supported — verify the composer constraint before committing). This is a Statamic addon, not a general-purpose Laravel package; a plain Laravel app without Statamic is not the target.
• Share images are template-driven from CMS content — you want one or a handful of layouts, parameterised by entry fields, rather than fully bespoke artwork per page.
• Non-developers need to regenerate imagery — the Control Panel Recreate action is the strongest signal here.
• You need taxonomy/relationship-aware imagery (tag pages, category cards, related-content compositions) — the v1.4.0 augmented entry support is directly relevant.
• You want share-image work to be configuration and design, with the rendering, caching, and storage edge cases handled by the package.

Look elsewhere or plan mitigation when:

• You are not on Statamic, or you are on a Statamic version outside the supported constraint.
• You need per-request, high-cardinality dynamic imagery (user-generated personalised cards at scale) where a dedicated image CDN or rendering service has better cost and latency characteristics.
• Your share images are hand-designed one-offs — a template engine adds indirection with no payoff.
• Rendering happens at request time in your critical path. Treat this as a build-time/cached artefact decision; if your architecture can't accommodate generation-on-save plus a cached URL, this is a poor fit.
• You need fonts, emoji, or complex typography guarantees that depend on the underlying image/text rendering stack — validate your specific requirements against the renderer before committing.
• You have no owner for template design. The package provides the mechanism; someone must own the visual output and fallback rules, or you will ship broken or generic cards.

Because this is a single-maintainer-org addon with a first-time external contributor in this release, treat it as a normal small-vendor dependency: pin versions, keep a fallback image path, and avoid making it the only route to a valid share image.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost addon that improves how our content looks when shared on social platforms and in messaging apps — the surface that drives a meaningful share of referral traffic. The practical return is two-fold: better-looking, more consistent link previews (a marketing-quality win with essentially no ongoing engineering cost), and editors who can refresh those images themselves instead of filing tickets. The v1.4.0 release adds tag- and relationship-aware imagery plus an in-panel regenerate action, and unblocks a Statamic 6 upgrade. Risk is contained: it's a single dependency, images are cached artefacts, and we keep a static fallback.

For engineering: Adopt as a Statamic addon with a pinned version. v1.4.0 adds augmented entry data (relations and tags) to template context, a Control Panel Recreate action, and Statamic 6 install compatibility — the last of which removes a blocker on the CMS upgrade path. Ask for: template definitions committed to the repo, generation on save rather than in the request path, cached storage with a deterministic URL, and a static fallback when generation fails. Verify the composer constraints and that the renderer meets our font/typography requirements before we plan design work against it.

For design and content ops: You get a template system for share cards driven by CMS fields — headline, image, tag, author, related entries — plus a Recreate button so you can refresh an image after an edit without waiting on a release. We need one owner for the template set and the fallback rules; the package supplies the mechanism, not the brand system.