Google Map Form Type Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package. The first thing to understand is that yappabe/google-map-form-type-bundle integrates with Symfony's Form component and Twig. You cannot composer require it into a Laravel app and expect a working form field — there is no service provider, no Blade view, and it depends on symfony/form and symfony/twig-bridge classes. For a Laravel codebase, the realistic path is to read the source and reimplement the small piece you need, or fork the Twig/JS into a Blade component. The whole payload is essentially one form type plus a Google Maps JS snippet, so porting is a few hours of work, not a migration project.

If you are actually on Symfony (or evaluating for one), the minimal steps are:

1. composer require yappabe/google-map-form-type-bundle (pin the 2018 release; it is archived, so no bugfixes).
2. Register new Oh\GoogleMapFormTypeBundle\OhGoogleMapFormTypeBundle() in config/bundles.php / AppKernel.
3. Add the field to a form:

use Oh\GoogleMapFormTypeBundle\Form\Type\GoogleMapType;

$builder
    ->add('latitude', HiddenType::class)
    ->add('longitude', HiddenType::class)
    ->add('map', GoogleMapType::class, [
        'lat'   => $entity->getLatitude() ?: 45.4642,
        'lng'   => $entity->getLongitude() ?: 9.1900,
        'zoom'  => 12,
        'width' => '100%',
        'height'=> '400px',
    ]);

4. Include the Google Maps JS API on the page (with a key) and render the map widget. The bundle ships a Twig form theme that wires the marker drag/click to hidden inputs.

Where to look first: the form type class (options and data mapping) and the bundled Twig template (the JS that pushes marker coordinates into the hidden fields). The README is thin; the template is the real documentation.

First use case: an entity with latitude/longitude columns (e.g. a store, venue, or delivery address) where an admin drags a pin instead of typing coordinates.

Implementation Patterns

Store coordinates as two scalars, not a single field. The type is a compound widget that writes into lat/lng inputs. Keep latitude/longitude as nullable decimal(10,7) columns and let the form type populate hidden inputs; map them in the controller with a small data transformer or a setCoordinates() mutator.

Compose with an address field. In practice the map is secondary: users type an address, you geocode it (server-side via the Geocoding API or client-side), then set the hidden lat/lng and let the map widget initialize at those values. Pattern:

$builder
    ->add('address', TextType::class)
    ->add('latitude', HiddenType::class)
    ->add('longitude', HiddenType::class)
    ->add('map', GoogleMapType::class, ['lat' => ..., 'lng' => ...]);

Then a small JS hook moves the marker after geocoding and dispatches change on the hidden inputs so Symfony's form sees the values.

Use it as the canonical "location picker" type. Wrap it in your own LocationPickerType so every entity form gets consistent defaults (zoom, height, map type, API key) instead of repeating a dozen options. That wrapper is also where you attach a PRE_SUBMIT listener to reject null/invalid coordinates.

Form theme override. The bundle registers a Twig form theme; if your design system expects specific markup, override the block in templates/form/ rather than editing vendor files. That template is your extension point for adding an "address search" box or a "use my location" button.

For Laravel (the likely real-world path): copy the concept into a Blade component.

{{-- resources/views/components/map-picker.blade.php --}}
<div x-data="mapPicker(@js($lat), @js($lng))" wire:ignore>
    <div x-ref="map" style="height:400px"></div>
    <input type="hidden" name="latitude" x-model="lat">
    <input type="hidden" name="longitude" x-model="lng">
</div>

With validation rules ['required','numeric','between:-90,90'] / between:-180,180, and a controller that writes the validated pair to the model. This gives you the same UX with none of the abandoned-bundle risk.

Gotchas and Tips

• Archived since 2018 and barely used (2 stars, 0 dependents). Treat it as reference code, not a dependency. No security updates, no Google Maps API compatibility fixes, no Symfony 5+/6 support guarantees.
• Google Maps billing changes will break it. The bundle predates the 2018 API key/billing requirement. You must supply your own key, enable the Maps JavaScript API, and restrict the key by HTTP referrer. If you see "For development purposes only" or a greyed-out map, it's a key/referrer/billing problem in the Google Cloud console, not a bundle bug.
• Script loading conflicts. The widget expects the Maps JS to be loaded once. Including it both globally and in the form template causes "You have included the Google Maps JavaScript API multiple times" warnings and occasionally a blank map. Load it once in your layout and guard with if (!window.google?.maps).
• Coordinates are strings until you cast them. Hidden inputs submit strings; persist as floats/decimals and validate ranges explicitly. null from an untouched map is a common source of 0,0 ("Null Island") records — add a PRE_SUBMIT/request validator that rejects lat === null || lng === null.
• CSP and mixed content. The Google Maps script needs script-src https://maps.googleapis.com and often img-src https://maps.gstatic.com data:. On HTTPS-only pages an internally hardcoded http:// marker icon will silently fail.
• No API key option in older versions. Depending on the tag you pin, the key may not be a form option — you'll inject it with a Twig parameter or data-* attribute. Don't hardcode it in the vendor template; put it in .env/parameters.
• Debugging checklist: open the Network tab and confirm a 200 from maps.googleapis.com/maps/api/js; check the console for RefererNotAllowedMapError / ApiNotActivatedMapError; inspect the hidden inputs in the DOM after dragging — if they don't update, the Twig theme's JS didn't attach (usually because the map container rendered before the script loaded).
• Extension points worth keeping if you fork: the form type's configureOptions (defaults for zoom/type/dimensions), the Twig block (markup + JS bootstrap), and a data transformer if you want to map a value object (Coordinates) instead of two scalar columns.