- What is ivory/google-map used for in a Laravel application?
- It provides PHP objects for building Google Maps API v3 configuration, including maps, markers, info windows, polylines, controls, and overlays, and serializes that state for rendering in views. In Laravel you can use it to compose map options server-side and pass them to Blade instead of hand-writing JavaScript arrays. It also includes optional web-service wrappers for geocoding, directions, distance matrix, places, and timezone if you need server-side Google API calls. It is a Composer library usable in Laravel, not a full Laravel package with auto-discovery.
- Does ivory/google-map support Laravel 10, 11, and 12?
- The library itself is framework-agnostic and targets modern PHP, so it can be used with Laravel 10, 11, and 12 when your PHP and dependency constraints resolve. It does not ship a Laravel service provider, config file, facade, or auto-discovery, so you must wire it into Laravel yourself. Verify its exact PHP and Symfony component constraints against your composer.lock before adopting it. The recent 2025 release is a positive sign for PHP-version currency, but test it in your own application matrix.
- How do I install and configure ivory/google-map in Laravel?
- Install it with Composer, then create a thin application layer: a service provider that binds the map builders or factories as singletons, a config/google-map.php file for your API key and defaults, and Blade components such as x-google-map. Keep view code behind your wrapper so it never touches vendor classes directly. If you use the web-service client, you also need to bridge its PSR-18/HTTPlug-style HTTP adapter to Laravel's HTTP client or Guzzle. There is no publishable package config or auto-discovery, so this setup is manual.
- How do I add markers and info windows to a map?
- You build a map object, create marker objects with coordinates and optional content, attach them to the map, and serialize the result into your Blade view. Info windows are represented as objects too, so you can associate them with markers or positions and let the package emit the corresponding JavaScript configuration. Escape or validate any user-supplied marker titles or info-window HTML before serialization because the library does not guarantee XSS-safe output for arbitrary content. Exact method names are in the README and API docs; the pattern is typed objects rather than raw arrays.
- Can I render multiple Google Maps on the same Laravel page?
- Yes. The package is built around map objects, so you can instantiate multiple maps with independent centers, zoom levels, map types, markers, and overlays, then render each one in Blade. Give each map a unique DOM container ID and ensure your wrapper component passes a distinct identifier. Easy setup for multiple maps is a supported use case. Watch for shared API-key and quota concerns if you also use the service layer.
- Do I need the Google Maps JavaScript API key, and how should I store it?
- For map rendering you need a Google Maps JavaScript API key, and the package expects it to be supplied through your configuration rather than hard-coded in views. In Laravel, store it in config/google-map.php backed by .env and restrict the key in Google Cloud Console using HTTP referrer restrictions for browser use or IP restrictions for server-side web-service calls. Use separate keys for browser maps and server-side geocoding, directions, or places if possible, and set budget and quota alerts. Never expose server-side unrestricted keys in Blade output.
- Does ivory/google-map include geocoding, directions, or Places API support?
- It includes a web-service client layer with wrappers for geocoding, directions, distance matrix, places, and timezone that call Google REST endpoints through an injected HTTP adapter. That layer is separate from map rendering and adds an HTTP abstraction plus quota-bearing Google API calls to your app. Only use it if you genuinely need server-side calls, such as geocoding addresses during an import; otherwise the browser Maps JavaScript SDK may already solve the problem. You must add caching, retries, and quota handling around the adapter yourself.
- How can I test Google Maps rendering without a browser?
- The map-building layer is stateless and produces serializable configuration, so you can unit-test the PHP objects for center, zoom, map type, markers, info windows, and overlays without loading Google Maps in a browser. Assert on the generated configuration or JSON in your test suite rather than trying to test Google's rendered tiles. For the web-service layer, inject a fake PSR-18/HTTPlug adapter and assert request URLs and payloads. Browser-level tests are still useful for final UI checks but are not required to validate configuration logic.
- Is ivory/google-map production-ready and well maintained?
- Treat it as tactical utility rather than a strategic dependency. The assessment cites roughly 13 stars, zero dependents, a single effective maintainer, and a fork lineage from an abandoned upstream, though a September 2025 release is reassuring for PHP currency. There is little public usage evidence, so you cannot rely on community defect discovery. Its MIT license lets you vendor or fork it, and keeping it behind your own service provider and Blade components makes replacement cheap.
- What are the alternatives to ivory/google-map for Laravel?
- If you only need map rendering, you can use the Google Maps JavaScript API directly in Blade with a small wrapper, or evaluate actively maintained Laravel map packages that provide service providers and config publishing. For server-side geocoding or directions, Laravel's HTTP client plus the Google REST APIs, or a dedicated Google API client, may be simpler than adopting this library's adapter layer. The key decision is whether you need typed PHP map objects and serialization; if not, the dependency may not earn its place. Because this bresam fork has low adoption, compare maintenance and Laravel integration support before choosing it.