🇮🇹Italy @itamair

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

@boulaffasae thanks for reporting this and providing your MR !64 (and parallel patch)
but I am not going to approve and merge it for the following reasons:

1. I ask you to better elaborate about your logical findings in the breaking workflow in the correct enabling / availability of the required geocoder providers and the parallel (or subsequent) enabling of the geocoder submodules (geocoder_address, geocoder_field, and geocoder_geofield): could you properly explain what you mean with "submodule's interference with the Geocoder provider plugin configuration" and how and where it exactly happen?
Also could you explain what your MR !64 is supposed to accomplish and workaround those interferences?

2. I further (once again) tested the scenario that you describe (the way I got it ... ) with a fresh install of a Drupal 10 (and 11) instance, and a Geocoder 8.x-4.28 release, and I could find any issue in correctly enabling and using the required Geocoder Providers, also with subsequent (or previous) enabling of those geocoder submodules. You could see a detailed description of of my Test and QA in this comment of mine (in this parent issue): https://www.drupal.org/project/geocoder/issues/3153678#comment-16065922 🐛 How to add Gecoder 3.x providers Needs review

I am incline to Close this as "Works as Designed" asap, but I am still curious to read a further explanation of your problematic use case (those kind of interferences explained) and the solving logics of your proposed MR !64 ...

Because of some (really few) issues still being posted that relate to some difficulties in adding Gecoder 3.x | 4.x providers, and assuming that possibly related to the conflicting enabling of geocoder_field, geocoder_geofield and geocoder_address submodules (such this latest one: https://www.drupal.org/project/geocoder/issues/3518956 🐛 Geocoder Submodules Preventing Installed Providers from Displaying (e.g., Google Maps) Active )

I further performed a deep insight and QA & test that could try to replicate the reported problematic scenario,
and still I couldn't experience any issues in enabling those Gecoder Providers that I required, and still having them enabled after subsequently enabled those geocoder submodules.

In particular I accomplished the following tasks in the following sequence:

1. I installed a fresh Drupal 10 (or Drupal 11) instance (locally with DDEV);
2. Required and enabled the Geocoder module with the following commands:
ddev composer require drupal/geocoder
ddev drush en drupal/geocoder
all good ... the Geocoder 8.x-4.28 release is installed and enabled.
3. I required the google-maps-provider and arcgis-online-provider Geocoder providers with the following commands (--with-all-dependencies):
ddev composer require geocoder-php/google-maps-provider -W
ddev composer require geocoder-php/arcgis-online-provider -W
ddev drush cr (always better to clear the drupal cache)
all good ... I could then find the required geocoder providers in the Geocoder provider options list, at the admin/config/system/geocoder/geocoder-provider settings page (@see the attached screenshot)
4. I enabled the geocoder submodules geocoder_geofield (after requiring the geofield module) with the following commands:
ddev composer require drupal/geofield
ddev drush en geocoder_geofield
ddev drush cr (always better to clear the drupal cache)
and still all good ... I could still correctly find the required geocoder providers in the Geocoder provider options list, at the same geocoder-providers settings page (@see the same attached screenshot)
5. I also enabled the geocoder submodule geocoder_address (after requiring the address module) with the following commands:
ddev composer require drupal/address
ddev drush en geocoder_address
ddev drush cr (always better to clear the drupal cache)
and still all good ... I could still correctly find the required geocoder providers in the Geocoder provider options list, at the same geocoder-providers settings page (@see the same attached screenshot).

My further established conclusions on this are that all is working fine with the expected workflow to require and add Geocoder Providers with actual Geocoder 8.x-4.28 release

this looks solved to me with latest Geofield Map release (11.0.x)

may be something changed / improved since you opened this, but now it looks what you report here is not really true.
The default Camera Control appears in the Google Map generated by the Geofield Map module, as you can see from the attached screenshot and the Demo site itself: https://www.geodemocracy.com/drupal_geofield_stack_demo/web/

Hey ok ... let's hopefully solve all this, once and for all.
I made a definitive test (using the new Drupal CMS) that clearly proves how the geocoder-php/arcgis-online-provider geocoder provider is correctly required and works correctly with the current version of the Geocoder module (8.x-4.x).

Please accomplishe the following steps, to achieve the same evidence:

1. Install the new Drupal CMS (https://new.drupal.org/docs/drupal-cms/get-started/install-drupal-cms) choosing the Events recipe/profile: the Events recipe requires Geofield, Leaflet and Geocoder modules, and also by default the geocoder-php/nominatim-provider provider ...

2. once accomplished point 1, then require the geocoder-php/arcgis-online-provider geocoder provider with the following ddev / composer command:

ddev composer require geocoder-php/arcgis-online-provider

and clear the drupal cache (drush cr)

3. go to the Geocoder provider settings (/admin/config/system/geocoder/geocoder-provider) to have evidence that the ArcGisOnline is now correctly available among the options of the Geocoder Providers options (see the attached screenshot).

and that's it ...

Please, for further informations and issues on to how correctly add Gecoder 3.x | 4.x providers please refer to this longstanding and still open issue: Gecoder https://www.drupal.org/project/geocoder/issues/3153678 🐛 How to add Gecoder 3.x providers Needs review

Well actually indeed I can recall that I already Closed (as Won't Fix) this parent Issue / Feature Request with the same reasons.
Such also this one: https://www.drupal.org/project/geofield/issues/3042880#comment-13039900 →

Thus I am closing also this Feature Request as won't fix.
I am still not persuaded to implement all this in the Geofield code base ...
BUT you arel free to implement your specific alterations in your specific use case and Drupal project instance.

There are many issues (drawbacks) that I see in this feature request and its actual implementation.

Regarding the feature request itself (to not expose the distance value in the Exposed Filter) I have the following blocking issues:
- I don't get which is the normal and recurring use case and need for doing this. It should always be evident to the uses the distance the proximity search is being performed upon. So I really don't get the reason to hide it;
- rather than completely hide the distance value, it should at least kept as a read only value in the Exposed Filter, to keep it still evident all the parameters of the Proximity Filter (both origin and distance).

Regarding the actual MR !40 state, that I quickly QA and Reviewed I can clearly see the following issues:
- the newly added "Expose distance field" checkbox element is totally disconnected from the "Distance" textfield and this is very bad from the UI/UX perspective. Why this is not kept close to the Distance element?
- once the "Expose distance field" is unchecked and the Proximity filter settings popup is saved than it becomes impossible to check and change the Distance element, both in case the filter is set as exposed and when not. This is super bad and makes everything totally unusable and not properly configurable ...

How did you test and QA this MR !40 state implementation?

BTW ... as general feeling I am really not incline to accept this Feature Request and implement it in the Geofield Proximity filter code base,
because this use case need looks very singular to me, and for accomplishing this I would still suggest you to override the @GeofieldProximitySource you are using (with a custom of you) and later its buildOptionsForm method, or even more simply use an hook_form_alter on the exposed filter form itself (and hide or make it readonly or disable the exposed Distance field),
as I already suggested in this comment: https://www.drupal.org/project/geofield/issues/3273483#comment-14475860 →

I would personally really close this as "won't fix".

Let’s try to keep staying respectful and polite here,
Where we are providing feedback and support mostly for free.
…
This issue looked pretty old to me and with no contribution for a long while,
And I guessed it was already solved.

Especially as consequence of numerous lates posts that clearly explain how to interact with Drupal Leaflet map, once it is generated.

For instance this one: https://www.drupal.org/project/leaflet/issues/3047091 📌 Leaflet Map & Markers external interaction, on events - LIVE DEMO Needs review
that points to the Live Demo,
and explains how to interact with the Leaflet Map and its features.

Basically in your case you will need to re center the Leaflet Map against the latest / newest Marker on the map.

How to pick the newest?
Well, taking it as the last if properly ordered by the Leaflet View sorting,
Or adding each date to each feature with the Leaflet Feature hook, ecc.
Kind of that …

Hope this helps.
Happy extending your Leaflet Map!

ok ... also interaction on the Geofield Map View page was improved. Now it works in an acceptable way.

Hi @òrahulkhandelwal1990 thanks for your head-up.
Indeed the Live Demo link was still pointing to a previous address.
I corrected it in this post description into this update and correct one:

https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geoplaces-gm...

Also the weblink to the geofield_map_interaction.js file mentioned in the Left sidebar block as initial guidance & inspiration of this interactivity was corrected.

Additional Note: On this Geofield Map View page the interaction is not working so great (the Google Map Infowindow sometimes doesn't open, etc.) as it is in the corresponding Leaflet View interaction example: https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geoplaces-ma...
Not sure why, at the moment ... but I will find sometime to better inspect and improve it.

Ok ...
so, do you really want to keep this open, with "needs work"?
I don't think this can cope in code every possible user use cases (and custom Leaflet Map Info definitions),
and that can end up into the Leaflet module code base.

Could we rather close as "Closed (works as designed)"?

Ok ... I went much better through all this,
and required & enabled the Content Security Policy module on my local instances of the following 2 (Leaflet powered) websites:

https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geoplaces-ma... (Official Leaflet Module Live Demo)
https://www.taranto-viva.com/it

Yes indeed, all the Leaflet maps break 8and not only the Leaflet widgets maps), with a long list of errors/warnings in the inspector console ... etc.

But also the MR !31 Draft doesn't help on this ... and all still looks broken.
It looks that is trying to cope some very specific use case and Leaflet context, that means if the Open Street Map Tile (default in the module) is used ... and for the widgets.

But it looks that also Leaflet Formatters and Leaflet View Styles are breaking ... isn't it?
And e should consider that in most cases users will implement different Leaflet Map background tiles ... (from Open Street).

May be I didn't get the proper issue case (as I am not fully understanding all the CPS options and functionalities, etc)
BUT I don't think/feel the correct use of the CSP should be restored with whitelisting with additional code in the Leaflet module,
but rather with specific whitelisting in the CSP module settings, or eventually in custom modules by users implementing it ...

What could be a general fix in this Leaflet module instead, eventually? (that could solidly cope all the possible Leaflet Map Tiles implementations?)

I cannot replicate this issue ...
To me, the actual Leaflet module release (10.2.43) can correctly render different Leaflet Popups and Tooltips
according to the translated version of the content and the language selected for the specific page.

For instance you can see this Italian / English implementation:
https://www.taranto-viva.com/en
https://www.taranto-viva.com/it

Please, close the first welcome popup, just zoom in and check both the Popup and Tooltips on some of those icons,
such the "Cathedral of San Cataldo", for instance ...

Suggestion: make sure you set in the View settings:
Language
Rendering Language: Content language selected for page

Screenshots attached ...

10.000 thousands features is pretty a lot ... and may be too much indeed.
And for sure you should enable the Leaflet Markecluster (sub)module (and its settings), at least trying that.

Views GeoJson module could be a nice option, but for sure won't reduce the number of features that you try to load ...

With that you should try to implement a Decoupled Solution that simply fetches that GeoJson data response.

Leaflet View map is only going to fetch data from a Leaflet Map View style,
or may be you simply can try to replicate this Leaflet View Geojson Demo example here:
https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geojson-map-...
(@see the linked "leaflet_map_geojson.js" file in the right sidebar ... )

but for sure that approach won't easy the load and effort of such a big amount of features.

hi @joaomachado ...
thanks for posting this.

Your description is a bit confusional.
You mention different content types labelled as Origins, or Destinations, then you also mention the Proximity Module, that is not clear what it is ... and also you ask if you could mix the Leaflet module functionalities with the Google Routes API,

Well. it's hard to be exhaustive here, without spending a lot of time (that personally I don't have now ...).
But I would point you into some helpful directions, possibly.

If you implement a Leaflet View Map then you should eventually be able to add to it the:
Leaflet Routing Machine (https://github.com/perliedman/leaflet-routing-machine) and build your own interactive solution on top of it ...
How?
Well, you should be able to master Leaflet Js library and its plugins and know how to extend the Drupal Leaflet Map View.
Probably this Drupal Leaflet issue should provide you with proper hints: https://www.drupal.org/project/leaflet/issues/3047091 📌 Leaflet Map & Markers external interaction, on events - LIVE DEMO Needs review

Google Routes API? may be also ... but in that case you will send the user out of the Drupal website for processing the navigation operations.

May be also the Geofield Directions module could be inspirational to you: https://www.drupal.org/project/geofield_directions →
Also see this dedicated brief video: https://www.youtube.com/watch?v=7HxuVQ8WlNA
As far as I understood it simply implements a Geofield Formatter that Links out to a Google Map that presets that Target Direction from ... well, I guess where you are, or whatever you choose as Google Map starting point.

But may be you could grab its code, and eventually generate a Computed Field that automatically generates a Google Map link with preset both origin and destination taken from a pair of Origin and Destination geofield entities ...

Kind of all that / those ...

vrancje → credited itamair → .

Thanks @bachbach for reporting this ...
could Test and QA the attached patch?
It should restore backward compatibility on this.

Well ... the server type shouldn't make any difference in my opinion,
BUT (anyway) of course we are also testing all this on Linux based servers.

More specifically it works correctly locally on DDEV docker web image: https://hub.docker.com/r/ddev/ddev-webserver
and it also works correctly here: https://www.geodemocracy.com/drupal_geofield_stack_demo/web/
that is (of course) based on linux servers ...

BUT, rather then going around vague assumptions, why you don't provide more info on your error logs ... ?
what is not working with your "arcgisonline" provider instance?
Are you able to XDebug what is happening on your code workflow?
Are you checking it locally .. or directly on the production server? (not nice practice, in such latter case).

I am pretty confident that it could highly depend on your specific configuration setup. May be something was messed up in your Arcgisonline configuration setup ...
Would highly recommend you to remove all of it and re require it via composer
composer require geocoder-php/arcgis-online-provider
and re-enable it from scratch with your Drupal backend configuration.

The original lower case
id = "arcgisonline"
never changed over the last bunch of years, and no-one reported this same issue of your, for a Geocoder provider that is basically free for use, and definitely much used also with this Drupal Geocoder module ...
No-one else have reported this same issue ...

Great catch @ivnish ... thanks.
QAed successfully.
Merging and deploying a new 2.1.3 release with this ...

Adding reference to the parent issue, that I had do autonomously look for ... and find,
and that wasn't approved and merged, because not needed.

I better inspected this, and nothing looks wrong to me in the actual 8.x-4.x code,
and everything (still) works correctly with the "ArcGisOnline" (id = "arcgisonline") Geocoder provider.

Changing this into "Support Request" (because no proof/evidence of Bug) and closing as everything "works as designed" ...

Please provide better info context next time, and make better internal debug, because everybody time is precious.
and please don't reopen this without clear evidence / proof of your assumptions..