- Can I use lendable/google-map-bundle in a Laravel application?
- No. Despite being listed among PHP packages, it is a Symfony2 bundle whose public surface is a Bundle subclass, a DI extension, a compiler pass, and Twig templates. Laravel has no bundle registration, compiler passes, or services.yml semantics, so none of its entry points can be invoked from a Laravel app. The framework-agnostic map logic actually lives in the upstream egeloen/ivory-google-map library, and the bundle is only glue code.
- Does lendable/google-map-bundle support Laravel 10 and Laravel 11?
- No. The bundle is built against Symfony 2.x, which reached end of life in 2018, so its symfony/* constraints conflict with the Symfony 6/7 components shipped inside Laravel 10 and 11. You should expect Composer dependency resolution to fail rather than a partial install. Adopting it would require a fork with widened constraints and a rewritten container integration.
- How do I install and register Lendable GoogleMapBundle?
- In a Symfony project you would Composer-require the package and then register the bundle in AppKernel along with its configuration. There is no equivalent step in Laravel, because Laravel does not discover or register Symfony bundles. The package's setup instructions assume a Symfony kernel, a services.yml container definition, and Twig as the templating engine.
- How do I add markers and set the center and zoom with this bundle?
- The advertised workflow is to build a map object in PHP using a fluent builder, setting center coordinates, zoom level, markers, info windows, and display options, with sensible defaults overridable per map. You then render it from Twig through the bundle's map helper, which serializes the definition into markup and JavaScript. That object model is the only genuinely reusable part, and it can be reproduced in a few hundred lines inside a Laravel app.
- Can I render Google Maps with Blade instead of Twig?
- Not with this package as shipped. Its default rendering paths assume Twig templates provided by the bundle, and Laravel ships Blade only. A Laravel port would need the Twig templates replaced with a Blade component or with a JSON payload consumed by a small JavaScript component.
- Is lendable/google-map-bundle still maintained?
- No. The repository is archived with zero stars and zero dependents, so there is no maintainer, no issue triage, and no security response process. Code from that era targets PHP 5.6 through 7.0 and predates Google's current Maps API key and billing requirements. Any defect you hit becomes yours to fix, and there is no community corpus to search for answers.
- Which PHP versions does the bundle run on?
- The code dates from around 2016 and targets PHP 5.6 through 7.0. Running it on PHP 8.2 or later risks removed and deprecated constructs, such as each(), dynamic properties, and changed implicit type conversions. Those issues surface as fatal errors at runtime rather than at install time, which makes them easy to miss during evaluation.
- What is the best alternative for embedding Google Maps in Laravel?
- For most Laravel applications the requirement is simply to show a map with markers, which a Blade partial plus the Google Maps JavaScript API handles directly with no PHP package at all. If you genuinely need server-side map composition, emit GeoJSON from your own controllers and let a small JavaScript component render it, which is more portable. If you want a fluent PHP builder, treat the Ivory object model as reference prior art and write roughly 200 lines in-house.
- Why does the map show 'for development purposes only'?
- Google's Maps JavaScript API has required an API key since mid-2016 and a billing-enabled Google Cloud project since 2018. Output generated by a pre-2016 renderer like this one typically lacks the required key and billing context, so Google serves a degraded watermark map or the request fails outright. This is a functional break rather than a deprecation warning, so widening Composer constraints alone will not fix it.
- Can I fork the package or reuse egeloen/ivory-google-map in Laravel?
- You can vendor the handful of value objects you need, such as Map, Marker, InfoWindow, Coordinate, and Encoder, into your own support namespace so you control PHP version compatibility and can delete Symfony-only code paths. The upstream library is framework-agnostic but is itself abandoned, so fork-and-strip is the only realistic path and it carries ongoing maintenance cost. For most teams the honest recommendation is not to adopt either as a dependency and instead build a small Blade and JavaScript component.