🇮🇹Italy @itamair

Closing this as Fixed, with MR70! merged. Thanks @aurora-norris ... crediting you for this opportune catch.

Marking this as Support Request, as this clearly doesn't report any Bug,
but just a lack of awareness (or documentation, but still on a very specific use case).

If you have multiple entities with a geofield that store the exact same (lat & lng) coordinates.
it is pretty obvious that you would end up on a bunch of different location entities that share the exact same coordinates.
Clicking on the Geofield Map, without markeclustering & spiderfying, of course it will open only the Popup of the Marker that is at highest level (Z-Index), and only render - list the Entity that is linked to that Marker.

The proper way to accomplish your needs should be to extend your data model and split it into 2 entities:
- location(s) entities, that embed the Geofield (and eventually the same Address), with unique (don't ever duplicate)
- content(s) entity that have an entity reference field to a location (entity). Eventually you could create both the new Content and new Location at the same insert time, if the Location (Address) is not yet created.

With this data model, architecture you can then create a Geofield Map of your defined Locations (and may be filter only those that have at least one Content referring to ... ) and then make each Marker Popup list all the Contents that refer to that Location (such an embedded reverse View: list all the Contents that refer to this Location).

This is a common (and smart approach) and you could eventually have a look to the "Geo Entity" module for some inspiration (or even exact reference) on what kind of Location Entity you might create and rely to ...

Hope (and very confident) this helps and points you to the proper approach.

@aurora-norris it looks that I was quicker and opened a MR !70 with a solution that relies on drupal_static cache so to mark the entity as being saved by the geocoder queue and stop any further processing in the geocoder_field_entity_presave.

That looks pretty logical and solid to me, and looks properly fixing this issue and stop further redundant entity save and revisions generations.

Please QA and Review ... and let me know if some more work is needed on this (and why eventually).

Hi @aurora-norris thanks for reporting and inspecting all this, so deeply.
Actually I am already inspecting and debugging this ... and indeed it looks that the GeocoderField @QueueWorker $entity->save() here:
https://git.drupalcode.org/project/geocoder/-/blob/8.x-4.x/modules/geoco...
is retriggering a new geocoder_field_entity_presave, at least once ... and then not a further time, as it looks the second time the $result === FALSE and then the $entity is not being resaved recursively ...

Thus I was thinking we should mark/flag the saved $entity in some way as saved by the @QueueWorker and stop all the new geocoder_field_entity_presave in that case.
I am going to inspect and implement this approach.
What you think?

Feel free to open your MR if you ended up to a better fix, so that I could review it, and compare, eventually.
Feel also free to PM me (itamair) on Drupal slack for more immediate feedback.

Never mind. Already moved forward on this.
New 10.3.7 release fixes all this.

thanks @erwangel for reporting this.
I could reproduce. Indeed this can happen the first time a new Leaflet View style is set, as the grouping options don't have pre-defaults.
Please Qa and Review the attached patch that should fix this ...

Moving this into Support Request, because
- no evidence is given here that is an objective bug: just reporting that something is not working on your side doesn't mean that there is a bug, and is not helping the community to identify and solve it
- I cannot reproduce it, and all is looking fine on my side, and on the Leaflet DEMO site here: https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geoplaces-ma...
that is now working on PHP 8.3, Drupal core 10.4.8 and Leaflet 10.3.6 ... (but this last upgrade cannot have any impact on what reported on this issue: Invalid LatLng object: (NaN, NaN))
- anybody else reported this same issue, as a Bug, and anyway the parent Issue should still be kept as main reference on this.

@praatts your profile looks totally new to the Drupal Community, so you should rather better inspect your Drupal instance setup and debug it ...
Are you using composer require etc. to build your Drupal instance and additional contro modules?

One thing that comes to mind, and that could be easily implemented/added, to avoid having to use the leaflet_choropleth_color_scale_alter hook (for defining custom labels for legend values), could be an additional long text configuration where the user enters the various values (labels) they want to associate with the different legend ranges (according to a specific requested pattern, such as each separated by a comma, a line break, or a pipe).
These values would then be translated by the %value placeholder into the Legend Items Format...
This is an improvement that's not difficult to implement in a future version of the module and would fulfill the Feature Requests of this issue even more easily (and with no custom code in your .module file).

thanks @ressa on this
what you are asking and mentioning as possibile further features is already perfectly accomplishable with the actual version and architecture of the module.

As mentioned in the README.md file, the Leaflet Choropleth is founded on Drupal Plugin API system ( https://www.drupal.org/docs/drupal-apis/plugin-api → ):
indeed both its already embedded classification methods and color scales/ranges are just “Classification
“ and “ColorScale“ plugins types, as defined in the module
and that comply and implement the following interfaces:

- ClassificationInterface: https://git.drupalcode.org/project/leaflet_choropleth/-/blob/1.0.x/src/P...
that implements the generateBreaks(array $data, int $classes) method, returning an array …

- ColorScaleInterface: https://git.drupalcode.org/project/leaflet_choropleth/-/blob/1.0.x/src/P...
that implements the getColors(int $classes, bool $reverse = FALSE) method, returning an array …

Thus you should simply create your own custom module and implement (in the proper src/plugin/Classification and src/plugin/ColorScale folders) the new custom Classification and ColorScale plugins that you need to implement additionally, naming them the way you prefer, and returning (for those methods) the array(s) values that you want …
Of course in case of Classification plugin type you should return a logical array of incremental integer(s) or float values, while each ColorScale plugin type should return an array of hex color values …

You could start doing this simply copying and pasting from one of the plugins already implemented in the module in the following folders:
https://git.drupalcode.org/project/leaflet_choropleth/-/tree/1.0.x/src/P...
https://git.drupalcode.org/project/leaflet_choropleth/-/tree/1.0.x/src/P...

If correctly created those new custom plugins of you, with proper naming and adjusting their namespaces to refer to your custom module, you can bet they will be added and appear as additional options in the Choropleth Map Settings of the LC module.

For what concerns custom Legend labels (for each interval)
it is also already possibile to alter the %min and %max values (and also a fixed %value for Categorical use case) that are then passed to the Legend,
throughout the leaflet_choropleth_color_scale_alter hook
that is triggered here: https://git.drupalcode.org/project/leaflet_choropleth/-/blob/1.0.x/src/P...
and better documented in the leaflet_choropleth.api.php file,
where I also added a real use case that simulate the use case where we want to alter the Legend items values with fixed values …

For your and the whole community convenience I am attaching here a custom “leaflet_choropleth_custom” custom module that exactly implements all this scenario.

In particular it implements the following:
- a new classification “FiveBreaksOn0100” that creates 5 class equal breaks from 0 to 100;
- a new classification “Custom Issue 3537366" that created the exact classification breaks that you mention in this support request Issue #3537366
- a new color ranges “Fuchsias (Sequential)"

and also a leaflet_choropleth_custom_leaflet_choropleth_color_scale_alter function (in its leafle_choropleth_custom.module file) where the default legend_items values are replaced with $custom_values.

Once enabled that module and once set the “Custom Issue 3537366" classification, and “Fuchsias (Sequential)" color range and set the Legend Items format as the following:
“%min - %max - %value”

I am easily able to generate the attached Choropleth Map and related Legend based on those custom value breaks / intervals (that you mentioned above).

Hope all clear with this.

Arggghhh ... totally my fault @ressa.
I simply forgot to do that, and definitely you deserve it also this time.
Let me try this new easier way and simply checking you along this additional message.

thanks again @reassa ... your inspections pointed me to the right direction.
It looks this was somehow caused and related to this open issue: https://www.drupal.org/project/drupal/issues/3272693 ✨ Simplify supporting AJAX/BigPipe in Drupal.behaviors: improve DX in case the selector to search is not in the given tree, but the root Active
that may be is not even a bug but just the proper ways Drupal behaviours work.
And luckily the fix was easy ...

This should now be solved by the latest 1.0.3 release, just deployed.
So closing this as Fixed.

Appreciate if you could confirm on your side, or reopen this if not ...

Ok super nice catch @ressa.
I can reproduce what you describe.
It looks that, with Big Pipe installed, the additional leaflet_choropleth js library is being requested too late, and it is not hooking on the 'leafletMapInit' event appropriately, and only when the user is logged in, etc.

I am going to better inspect all this, and implement a more robust (and forced) injection of that.

At the moment a quick workaround on this would be to always check/flag Lazy Loading of the Leaflet Map (that is the option right before the new Choropleth Map Settings section ...

Thanks @ressa for trying out the new Leaflet Choropleth module, and glad that your first feedback is so positive.
Please keep testing and reviewing it, and let the community know what could eventually be improved.

On this specific issue that you report as a (small) bug ... well I cannot reproduce it in both the Drupal playgrounds that I am developing and testing this module on.
As you can see from the attached screenshots, the Legend correctly shows up to my itamair administrator user, in the Leaflet Choropleth View.
And it looks weird and really un-expected what happens to you, because the leaflet_choropleth.js functional logics doesn't depend on any user permission, as you can see here:
https://git.drupalcode.org/project/leaflet_choropleth/-/blob/1.0.x/js/le...

It probably depends on some specific js settings or break that happens on your js workflow, on the FE with administrator user ...

You should inspect how your js workflow proceeds (and if it breaks) in your Browser Js inspector, with proper breakpoints ...
if that self.addChoroplethLegend method is correctly invoked, that (ste by step) you should also check if it correctly goes through here:
https://git.drupalcode.org/project/leaflet_choropleth/-/blob/1.0.x/js/le...

Of course, be sure you are testing lates module release (1.0.2) and please clear both your drupal and browser cache, to make sure ...

Please refer to this new issue on important updates on this topic: https://www.drupal.org/project/leaflet/issues/3536863 📌 Leaflet Choropleth (sub)module Active

Please refer to this new issue on important updates on this topic: https://www.drupal.org/project/leaflet/issues/3536863 📌 Leaflet Choropleth (sub)module Active

The brand new Leaflet Choropleth module → is now implementing all this ...

itamair → created an issue.

Thanks @dieterholvoet ... for providing all this.
Not yet (super) clear to me what all this is already achieving or is setting to make the module ready to achieve,
thus I will need to better go through the parent reference: https://www.drupal.org/node/3218156 →

But one question from now. Is it not needed the autowire: true to enable autowiring, as mentioned inside that?

thanks @toki for reporting this, and sorry that you are experiencing this issue ...

It looks pretty weird because it is happening to you ONLY on Safari, that lately cannot be considered the most solid browser among the others, and also because that is happening to you ONLY on that specific Drupal application / website.

As you can see from these Leaflet Demo Pages:
https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geoplaces-ma...
https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geojson-map-...

Drupal Leaflet map show correctly on Chrome, Firefox, Safari, etc,

and due to what is say here:

I have another Drupal 10 site configured almost identically, and there, the maps work perfectly under all browsers.

this doesn't really look a bug of the Drupal Leaflet module, but almost certainly a singular configuration or app state for that specific one from you.

So I am moving this from Bug Report to Support Request ...

Does this happen to you both on the local and live environments? Or only in the live / production environment?
May be you should also try with Incognito mode?
and indeed check and detailing debug what is preventing your Leaflet map to load only on some browsers ...

Latest mentioned commits fix this in both10.2.x and 10.3.x branches.
Going to deploy new Drupal Leaflet releases (on both branches) that include these ...

thanks @gillesbailleux for reporting this ...
BUT indeed I couldn't reproduce this issue that you report
in my playground in Drupal 11.2.0 with Leaflet 10.3.3,
and both css and sj aggregation enabled.

Screenshot attached ...

Worth to mention that Leaflet 10.3.3 (that you explicitly mention "after upgrading to" ...) didn't touch any code related to "Reset Map View Leaflet Plugin" functionality.

Please run your further inspections/debugging and provide clear evidence of what changed changed in Leaflet 10.3.3. that is now potentially causing this issue of you ...

My greatest apologises @devarch ... I was finally able to reproduce all this.
Committed into both
with the following:
https://git.drupalcode.org/project/leaflet/-/commit/7b73ca47a59cea41d3a0...
https://git.drupalcode.org/project/leaflet/-/commit/a867dd314edb6554afd4...

Going to deploy a new Leaflet release with all this.

I further tested the actual MR!59 state and the following fix:

$this->renderer->renderRoot($elements)

was always causing the following Exception:

LogicException: A stray renderRoot() invocation is causing bubbling of attached assets to break. in Drupal\Core\Render\Renderer->renderRoot() (line 105 of /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php).

In the end the fix to this looks as simple as simply omitting the render $is_root_call = TRUE param.

Closing all this as the lates https://git.drupalcode.org/project/leaflet/-/commit/65363711efec28463179... commit is (looks) fixing all this.

Deploying a new 10.3.2 with this, and crediting @f0ns just for this reporting (though his fix didn't work to me).

Also I had to change the target branch from 10.2.x to 10.3.x ... (be more carful with all this please, guys).

Ehi @f0ns shouldn't also this same $this->renderer->render (with $is_root_call === TRUE) here:

https://git.drupalcode.org/project/leaflet/-/blob/10.2.x/modules/leaflet...

be fixed in the same way?

leaflet 10.3.1 release → should have fixed this.
Please confirm ...

leaflet 10.3.1 release → should have fixed this.

Ok ... I extended the leaflet.reset_map_view fix (removal it explicit load from the header) to all the other leaflet modules libraries requested in the same way, and I couldn't find any regressions, in the drupal instances and use cases that I tested,
and even some performance improvements.

This commit https://git.drupalcode.org/project/leaflet/-/commit/c6f962793fd7f6c1fcd3... includes this MR!58 fix.
Closing the MR!58 and going to deploy new releases for both the 10.3.x and 10.2.x brach with all this.

@devarch I checked your screenshots and read your last report,
so I was persuaded to further test all this, and try to reproduce your very clean Drupal 11 use case.

thus I simply replicated this basic Drupal 11 installation process:
https://www.drupal.org/docs/getting-started/installing-drupal/install-dr... →

and I only enabled the Leaflet module (with Geofield dependency of course)
then I created a Geoplace content type with only a Geofield, etc.
then generated a Leaflet View and set Leaflet Popup on Geoplace Default view with Ajax ...
and everything still looking (and loading) good on Leaflet Ajax based Popups, and even showing nested Leaflet Formatter Maps,
as you can see in the newly attached screenshot of mine (that doesn't report any js console error/alert, nothing ...).

Indeed the core/drupal.ajax library is (still) loaded with this very basic Drupal 11 clean setup, indeed without any other contrib module or theme added and enabled, just Olivero 11.1.8 (default theme) ...

Sorry, I am not going to spend further checking time on this (as this is al free time from me), and also if still nobody else is going to step in here and confirm your issue.
Thus please, rather than with SimpleTest, etc. try to replicate what I just did and described, with this basic Drupal 11 installation process
and come back here with evidence of the bug source you could find.

thanks @devarch for reporting this and providing all your details

BUT I cannot reproduce your issues, and Leaflet Popus load nicely with Ajax (as expected) in all the following combination that I (just) tested out on this purpose:

- Drupal Core 10.4.8 & 11.1.7
- Drupal Leaflet 10.2.48 & 10.3.0

More specifically:

1. Check this Leaflet Demo page: https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geoplaces-ma...
that at the moment loads (nicely) Leaflet Popups via Ajax, with Drupal Leaflet 10.3.0 and Drupal Core 10.4.8

2. I tested the new Drupal CMS 1.1.1 with this Drupal Geoimages Recipe ( https://www.drupal.org/project/drupal_cms_geo_images → )
implementing Drupal Core 11.1.7 and Drupal Leaflet 10.3.0 ... and all looking good also there, on Leaflet Popups via Ajax.
I am attaching screenshots of this test case of mine ...

SO please, try to replicate this valuable General Test Case autonomously,
simply reproducing that Recipe Instructions (with its Step 1, 2 and 3)
and eventually upgrade the Drupal Leaflet module at its very end, with:
ddev composer require 'drupal/leaflet:^10.3'

I have the strong feeling that your specific Drupal instance setup is breaking somehow the JS workflow, and somehow not properly loading / requiring the core/drupal.ajax library.
It looks that you already checked the Js console ... but you should also inspect why that is happening.

It looks still you are the one (among thousand of Leaflet module adoptions and adopters) reporting this issue ...
Thus I am closing this for now as "Cannot reproduce".
BUT feel free to re-open this if you find (and can provide objective) strong evidence of a more general use case of the issue that you report.

Regards

More tech info in this Linkedin Article: https://www.linkedin.com/pulse/drupal-leaflet-widget-map-geojson-overlay...
Leaflet GeoJSON Overlays - Demo Overview (Youtube): https://www.youtube.com/watch?v=Pb7z7fnXMt0

🚀 Leaflet 10.3.x and 10.3.0 release → now supports GeoJSON Overlays in Leaflet Widget Maps

The latest Drupal Leaflet 10.3.x release brings a powerful new feature to the Leaflet Widget Map: support for custom GeoJSON overlays. These overlays can serve as non-editable, snappable drawing references, enhancing both the usability and interactivity of geospatial content editing in Drupal.

🧩 Full Backward Compatibility

Drupal Leaflet 10.3.x remains fully backward-compatible with the 10.2.x branch—so upgrading is safe and seamless.

🔍 Feature Overview

This release introduces a new configuration section for each Leaflet Map Widget instance, enabling the inclusion of GeoJSON sources as visual overlays on the map. These overlays are read-only but can optionally support snapping during geometry creation or editing, streamlining workflows for editors and site builders alike.

For convenience I am adding this weblink reference: How to use Drupal rector to get started converting annotations to attributes?

Indeed this issue (finally) happened to me also, and I was able to solve it following the suggestion #64 🐛 How to add Gecoder 3.x providers Needs review :

Solution is to change weight of the module geocoder.
Edit the core.extension.yml file and update geocoder to below:
geocoder: 1
then run drush cim command

Note: geocoder weight should be higher than geocoder_address module.

Ok, improved ... merging into 8.x-4.x-dev

itamair → made their first commit to this issue’s fork.

Thanks. Makes sense.
Improved text message committed into 8.x-4.x-dev.

The use case described in this issue is very confused and also looks controversial to me.
Thus it looks that you have (in your configuration) the field_location that is both being geocoded by/from the field_address and the plain text field field. How could it be possible?
The actual Geocoder module doesn't support that (you can only geocode from 1 existing field, no more ...).
Please provide a better description (and a feasible version) of your complicate setup OR make it more feasible.

thanks. Committed into 8.x-4.x-dev

Thanks @stefan.korn nice catch.
Completed the MR with better coding and proper documentation.
Merging into 8.x-4.x-dev ...

itamair → made their first commit to this issue’s fork.

@ressa @phenaproxima is this still valid / valuable for the Drupal CMS?
I cannot see any reference to this feature request / patch in the Drupal CMS repository,
and all this looks kind of very specific use case ...
Thus I am not fully incline to commit this into the Geocoder 8.x-4.x-dev branch.
But didn't fully investigated this use case, so not 100% sure in either direction.
Please let me know if this could be closed as Outdated or still moved forward and how ...

itamair → made their first commit to this issue’s fork.

Ok. QA and Reviewed this on, merging into 8.x-4.x-dev ...

I tried to reproduce this issue / use case (with the Geofield instead of Geolocation) and was never able to do that.
I never intercepted the 'data' value,
I was correctly able to Translate the content (according to the described use case) and rather the added code always breaks the Geocoder workflow (and the application) because most of the times the unset is applied to a string (rather than an array), such the following:

$result = ["POINT(XX.XXX YY.YYYY)"]

I am closing this, as Cannot Reproduce.
Please reopen but ONLY providing a better use case description and much more solid and defensive code.

itamair → made their first commit to this issue’s fork.

I am not confident that this is really RTBC ... so moving back to Postponed, also because I can see a lot of new commits have been added, and the MR !34 is still marked as Draft etc.

Is there still some activity and commitment here?
Could we eventually have something more solid that Needs Review?
May be a brand new spinner off Issue could also make sense, after closing this as Outdated.

Nice catch. Merging (and sorry for this delay ... )

itamair → made their first commit to this issue’s fork.

I didn't have any feedback on my changes reuqests from some days, thus I implemented those.
Going to Merge and commit this proper improvements into 8.x-4.x-dev.

Thanks for your last fixes and all the provided explanations.
I am still not convinced that we should introduce the Plugin Attributes and still keep BC with Annotations and Drupal Core < 10.2.
At least we still have time to implement this, as (ref: https://www.drupal.org/project/drupal_cms/issues/3501710 🌱 Drupal 12.0 compatibility planning Active )

Drupal 12 will be released at the earliest in June 2026 which is in 15 months

and probably we would rather deploy a new release in some months that would drop support to Drupal Core < 10.2
(and be cleaned up with all the Annotations Plugins code).
Let me still think about all this for some days ... and let's see if you or another community member has stronger opinion on all this.
Let's still keep this in "Needs review" for other comments ...

thanks @codebymikey for moving ahead on all this ... that looks definitely wise and opportune.
I opened a review to you MR and left some comments.

A couple of other questions and considerations:
- did you QA & Test your new implementation? Does it work properly without introducing any regression to the 8.x-4.x-dev branch?
- do you really think we should introduce all these new Attributes pattern still keeping the Annotations classes and backword compatibility for Drupal Core versions < 10.2?
Wouldn't be better to spin a new major Geocoder release that supports only "^10 || ^11" and remove all the Annotations? (not to maintain parallels patterns)?

Ok ... I properly inspected all this issue and found the cause and the fix (that I pushed into dev) wasn't that complex.
Everything already deployed in new media_library_importer 2.1.5 release → , that should fix and be free from this.
Please test it out and eventually reopen this, if not solved ...

Thanks @Nate for this super detailed and clear report.
I will (would find some time to go) deeper in this and my analysis.
Did you eventually elaborated any clue on how to properly fix this?
Or just identified the code area that brings this incorrect behaviour ...
I mean. Do you already have a patch for this?

Thanks!

itamair → made their first commit to this issue’s fork.

thanks @valthebald for the clarification.
Well, actually my WIP was already provided with version 1.0.5, and now it looks that I should re-start over, with 1.1-beta.

Perhaps, in accordance with Drupal's semantic versioning model ( https://www.drupal.org/docs/distributions/degov/semantic-versioning-model → ) and given the discontinuation of BC, a new 2.0.x release would have been a better name for this branch... (?).

itamair → created an issue.

Thanks. Merged this ...

itamair → made their first commit to this issue’s fork.

itamair → created an issue.

just a further refinement, so to generate a GEOMETRYCOLLECTION only if more than one Geofield values, otherwise just use the first Geofield value (GEOMETRYCOLLECTION needs at least 2 sub features, otherwise Geojson is not valid, apparently).
The generated Geojson looks valid now on my side, on top of multivalue Geofields ...

Ready for QA and Review.

Please Test and QA ...
Would be (soo) nice to approve and create a new Views GeoJSON release with this, to provide a more extended and strong support for the Drupal Geofield module → .
Thanks!

itamair → created an issue.

bonnet clear what you mean (to me).
Anyway there is no presence of any "leafmap" string / term in the whole Drupal Leaflet module code base,
and that gives me the evidence that this issue of you is not related at all with this Leaflet module.

Hi @promes
what makes you thinking that this warning is coming and being caused by the Drupal Leaflet module?
From the waring you mention / pasted it looks totally unrelated to the Drupal Leaflet module ... isn't it?

Please also test new Leaflet 10.2.46 release → and check if that new release also fixes this issue.

New Leaflet 10.2.46 release → just deployed with #2 patch.
Closing this as FIXED ... please reopen if this issue still happening.

Anyway ... the error message that you describe looks similar to/ identical to the one reported also in this other issue) still related to Leaflet release 10.2.45 ...: https://www.drupal.org/project/leaflet/issues/3521371 🐛 Version 10.2.45 introduces a bug with Views tooltips. Active

Could you please QA and Review the patch attached in comment #2 in that Issue thread here (?):
https://www.drupal.org/project/leaflet/issues/3521371#comment-16087181 🐛 Version 10.2.45 introduces a bug with Views tooltips. Active
and let us know if that eventually fixes this issue on your side?

Thanks!

KML format is not directly supported in the Geofield ( https://www.drupal.org/project/geofield → ) and Leaflet ($this) modules, hence I assume you are referring to a user scenario where the Geocoder module ( https://www.drupal.org/project/geocoder → ) is being used to transform a KML file into a Geofield (WKT or GeoJson), throughout the KML Geocoder provided.

Well ... all looks good to me (and no sign or log of that error you report), also in the Geocoder module scenario and with Drupal Leaflet 10.2.45, as you can see in the attached screenshot where the attached simple.kml file is being geocoded into a Geofield field ...

Hi @mwynne ... don't really get what's happening on your side.
Make sure to set in "fields" the "Show" format of your Leaflet View style,
and select a for the "data source" option ...

All should be fine with that.

thanks @bigbaldy for reporting this,BUT I cannot reproduce what you report.

This Leaflet 10.2.45 based demo site / view:
https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geo-place/da...
is working correctly with tooltips (as you can clearly see), with not logging that error that you report.

You mention the Leaflet Formatter, but then your error reports the LeafletMap View style class,
and that is also a bit misleading ...
But also the Leaflet Formatters are working correctly, as you can see from these 2 example pages:
https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geo-place/da...
https://www.geodemocracy.com/drupal_geofield_stack_demo/web/it/geo-place...

Anyway, may be your use case is having some specific Leaflet Tooltip token / replacement setup,
and some more solid and defensive code in parsing/casting that Render/Markup into a string is worth the case.

Could you please QA and Test the attached patch with the latest Leaflet 10.2.45 and confirm if that solves this issue of you, or still not?
And let us know here ...

thanks @john.oltman for reporting this ...
BUT I cannot reproduce any of the issue that you report.

Let's do it together, and with the new Drupal CMS (Drupal 11 based).

Please follow the steps on "How to install Drupal CMS using DDEV" as described on this page:
https://new.drupal.org/docs/drupal-cms/get-started/install-drupal-cms/in...

At the end of the ddev composer create drupal/cms command you will see that everything is being required without any issue and warning, and geocoder module is part of it ... because a dependency of the drupal/drupal_cms_events recipe.

But also let's try to specifically require the drupal/geocoder project, applying the following composer commands:

# remove the geofield stack module (and the geocoder module) along with the drupal/drupal_cms_events recipe
ddev composer remove drupal/drupal_cms_events recipe

#then let's specifically require the drupal/geocoder module:
ddev composer require drupal/geocoder

and all is being required correctly, to me ... with any of the warnings that you report.
Isn't it?

Could you kindly instruct me how to reproduce the warning that you experience and report, in the above (very general) scenario that I provided?
I need to have evidence that what you report is a general / established uses case ... and not a specific of you.

Otherwise I would Close this as "Works as Designed".

Thanks ...

Committed into 10.2.x dev branch.

thanks for providing all that @boulaffasae ... I am going through it and check asap