Gmap Widget Laravel Package

Product Decisions This Supports

• Build vs. buy (or build vs. borrow) for map embeds. This package answers a narrow question: "should we hand-roll a Google Maps block for our CMS, or reuse an existing widget?" For a Victoire DCMS-based product, it is a reference implementation of a map widget — its value is as a pattern, not as a dependency.
• Feature scoping for a "location/map" block. Reviewing the widget's inputs (address/coordinates, zoom, marker content) gives a quick baseline of the minimum viable field set for a map component in an editorial UI, useful when writing acceptance criteria for a homegrown equivalent.
• Roadmap de-risking for legacy CMS estates. If your product runs on Victoire DCMS and already has this widget installed, its 2016 last-release date is a roadmap input: budget for replacement or in-house maintenance rather than assuming upstream fixes.
• Not a decision lever for anything else. With 2 stars, 0 dependents, and a single maintainer organization, it carries no ecosystem signal — do not use its popularity (or lack thereof) as evidence about the broader market for map integrations.

When to Consider This Package

Consider it only when all of the following hold:

• You are already committed to Victoire DCMS (Symfony-based); this is a Victoire widget, not a general Laravel/Symfony bundle, so it is not usable outside that CMS without significant adaptation.
• You need a basic embed-style map for editorial content — an address, a pin, maybe a zoom level — and nothing interactive or data-driven.
• You are comfortable vendoring or forking it. The MIT license permits this, and given the release cadence you should assume you own maintenance from day one.
• You have verified the generated markup still works with current Google Maps Embed/JS API requirements (API key, billing account, and the 2018 pricing/API changes), or you plan to swap the map provider behind the same widget interface.

Look elsewhere — or build in-house — when:

• You are on Laravel, plain Symfony, WordPress, or any stack other than Victoire DCMS.
• You need anything beyond a static pin: directions, clustering, custom styling, geocoding, multi-location search, or privacy-compliant map loading (GDPR consent gating is a common requirement now and this predates it).
• Your security or procurement process requires a maintained dependency with recent releases, CVE response, or a named maintainer SLA — a 2016 last release will not pass.
• You need a supported vendor relationship for Google Maps terms-of-service compliance; that responsibility sits entirely with you here.
• You want to avoid Google-specific lock-in. A thin internal abstraction over a map provider (Leaflet/MapLibre plus a tile source) is likely cheaper over a 3-year horizon than resurrecting this widget.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Google Maps widget built for Victoire DCMS. It is effectively unmaintained — last release December 2016, two GitHub stars, no downstream dependents. Treat it as reference material, not a strategic dependency. Recommendation: do not adopt it as a component of a new product; if we already ship it, fund a replacement in the next planning cycle. The cost of adoption is not the license (free), it is the ownership — we would inherit all maintenance, security, and Google API-compliance work.

To engineering: The widget is tightly coupled to Victoire DCMS's widget model and predates Google's API-key and billing requirements, so integration testing against the current Maps API is mandatory before any reuse. Estimated effort to make it production-safe is comparable to writing a small map block from scratch, but with the added burden of unfamiliar legacy code. Preferred path: extract the field model as a spec, implement a thin map component with a provider abstraction, and gate loading behind consent. If we must keep it short-term, vendor the code into our repo so we control the fork.