Gravatar Bundle Laravel Package

Product Decisions This Supports

• Avatar strategy for user-facing surfaces — profile pages, comment threads, activity feeds, team directories, and notification emails all need an avatar source. This package remains one option in the "where do avatars come from" decision alongside local uploads, SSO/IdP-provided photos, and third-party avatar services.
• Build vs. buy (and the third option: build-in-an-hour) — the capability is still just a URL builder against gravatar.com/avatar/{hash} plus default-image and size parameters. The realistic decision is "in-house helper vs. thin dependency," not "buy vs. buy." This release does not change that math.
• Scope negotiation on profile/settings work — the helper still lets you defer a full avatar-upload pipeline (storage, resizing, moderation, CDN) by shipping Gravatar lookups first. That roadmap-sequencing lever is unchanged.
• Fallback and default-avatar policy — configuration of default images and sizes still forces an explicit product decision about what an anonymous or non-Gravatar user sees (identicon, initials, brand silhouette), which is a visible design and brand surface.
• Not a Laravel decision — this remains a Symfony bundle registering a service and a Twig helper. The 7.0.0.2 release confirms it now tracks Symfony 7.x, not just Symfony 4. If the product is Laravel, this package is still not a candidate; the relevant decision becomes "adopt a Laravel Gravatar package or write the helper."

When to Consider This Package

Consider it when all of the following hold:

• The application is Symfony 6.4/7.x (the 7.0.0.2 release updates the bundle to current Symfony DI conventions) and already consumes bundles as a delivery mechanism.
• Avatar needs are read-only lookups — you need a URL from an email address, nothing more (no profile data, no upload, no moderation).
• You want a configurable service plus a Twig function so templates stay clean, and you value that over owning ten lines of code.
• The 7.0.0.2 release and MIT license satisfy your OSS intake policy, and you accept that this is a single-maintainer, single-digit-star dependency with zero dependents — effectively unvetted by the ecosystem, so it should be vendored, pinned, or copied rather than trusted as infrastructure.
• You have a plan for the Symfony 8.x transition: this release exists because Symfony\Component\HttpKernel\DependencyInjection\Extension is internal as of Symfony 7.1 and slated for deprecation in 8.1. The bundle still extends that class, so a future breaking change is already telegraphed.

Look elsewhere — or write it yourself — when:

• You are on Laravel, or on a Symfony version where this bundle/Twig-helper pattern is legacy. The package will not fit Laravel's idioms.
• You need GDPR/privacy controls. Gravatar lookups transmit a hash of the user's email to a third party; that is a data-processing decision requiring disclosure, consent handling, or a self-hosted proxy — none of which this package addresses.
• You need upload, cropping, moderation, storage, or CDN delivery. This does none of it.
• You need resilience — caching, timeout handling, or graceful degradation when Automattic's endpoint is slow or blocked. A raw URL builder simply emits an <img src> and hopes.
• Your OSS policy requires active maintenance, security response, or meaningful adoption. Two stars and zero dependents still says the cost of adoption exceeds the cost of authorship. The honest recommendation for most teams remains to inline the hash-and-URL logic and own it.

How to Pitch It (Stakeholders)

For executives: This is a tiny, free, MIT-licensed convenience wrapper around Gravatar — the service that maps an email address to a profile picture. It is not a strategic asset and not a platform decision. The strategic question is unchanged: do we pull third-party images (fast, free, zero storage, but leaks an email hash externally and shows nothing for users without a Gravatar account) or build first-party uploads (cost, infrastructure, moderation, but full control and better privacy posture)? Recommendation: treat Gravatar as an interim default to unblock profile work, and keep first-party avatars on the roadmap behind a real user need. The 7.0.0.2 release is a maintenance fix, not a capability change; do not spend political capital or procurement cycles on this dependency. A single engineer can replace it in under a day.

For engineering: The package is a Symfony bundle providing a configurable service and a Twig helper that returns a Gravatar URL from an email. That is still its entire surface area. The 7.0.0.2 release is a compatibility/deprecation fix: the bundle's DI extension still extends Symfony\Component\HttpKernel\DependencyInjection\Extension, which is internal since Symfony 7.1 and slated for deprecation in 8.1 in favor of Symfony\Component\DependencyInjection\Extension\Extension. Two implications: (1) it now targets Symfony 7.x, correcting the earlier "Symfony 4 only" read; (2) a breaking migration is already signposted for Symfony 8.1, so if you adopt, budget for that. It remains a single-maintainer, zero-dependents package — treat it as sample code, not infrastructure. Because the logic is a hash plus a query string, the sensible move is still to copy the helper into our codebase rather than add a supply-chain dependency: it removes the upgrade risk, lets us add caching, a default-avatar policy, and a self-hosted proxy for privacy, and it costs an afternoon. If we do take the dependency, pin it, vendor it, and put a fallback behind every avatar render so a blocked or slow Gravatar endpoint never degrades page load. Flag for the record: this is Symfony-only, so if the target product is Laravel, the answer is no and the work is a small in-house helper instead.