🇮🇹Italy @itamair

Patch #88 works pretty handy for me, as it allows to configure from the Manage Form Display the Media Library View & Display to use for the Media Library Widget, and also the Media entity view mode.

Sure @alfthecat ...
The Localstorage (or may be better Sessionstorage) approach looks promising, but I don't know if it could be kept embedded only in the new dedicated @GeofieldProximitySource Drupal Plugin.
If not, may be you could also propose some patch / Merge Request to the whole Geofield Proximity system itself ...

Please keep me updated on your progresses, Pretty curious about those.

Thanks @alfthecat for reporting this.
As immediate feedback I would highlight to you that the "Client Location Origin" (id: geofield_client_location_origin) is a @GeofieldProximitySource Drupal Plugin, like any other @GeofieldProximitySource ones (that implement GeofieldProximitySourceInterface),
and that you, as everybody else, can implement your own @GeofieldProximitySource Drupal Plugin in a custom module,
and thus try to implement all the features that you further require as custom.

I might find some spare time to better go through this feature request of mine (I couldn't reproduce your use cases yet, and make it more mine) but in the meanwhile I welcome you to eventually contribute in start developing / drafting yourself the @GeofieldProximitySource plugin & related functionalities that you have in mind / need ...

It looks the targetDefinition is only accessory variable used in the constructor, and in any other geofield_feeds_target methods, etc.
Thus what about just keeping it as a simple variable in the constructor itself only?
I don't see any requirement to declare it as class property at the moment. Do you?

Please rather QA and Review the attached patch.

This cannot be defined as a BUG issues, because it looks all about @rahul-kumar-07 specific settings.
May be @rahul-kumar-07 is not so experienced with Drupal Images styles ( https://www.drupal.org/docs/user_guide/en/structure-image-styles.html → ) ?
What is being reported clearly shows images urls generated throughout a "medium" images style,
thus some specific user case settings ... and not much dealing / related with the media_library_importer module logics.

Closing this consequently.

trusting and committing into dev the patch provided

Thanks @marcoliver, patch #4 committed into dev branch, will be part of the next incoming Geofield module release.

Patch 3 committed into dev branch, is going to be part of the incoming Leaflet module release

Thanks @marcoliver ...
could you rather Test and QA the attached patch, that more properly corrects the GeoPHPWrapper->load method implementation so to always and more properly match the interface return options?

Thanks @uniquename for this input, that indeed makes sense.

BUT I attach here a patch with the aim to accomplish what you require/mentions in a more general way,
potentially/practically extending to and supporting all the options available in the Leaflet Geojson object (https://leafletjs.com/reference.html#geojson).

Can you please confirm that this patch also includes also properly implements your requested pointToLayer function ... ?

Well, imho
you should apply what Leaflet Js library explains here:
https://leafletjs.com/examples/overlays/

and do that with the Leaflet Map that is being generated by the Leaflet View / Formatter,
and that could be achieved following the hints/example and instructions explained here:

https://www.drupal.org/project/leaflet/issues/3047091 📌 Leaflet Map & Markers external interaction, on events - LIVE DEMO Needs review

This is not a big deal, at all.
I just checked this and I cannot reproduce.
With the actual Leaflet 10.2.25 release, and Leaflet js local library, marked as 19.4 all looks being reported as expected in the Status Report page and in the XDebug report.
So I am asking myself what kind of use case are dealing with ...

Anyway, worth adding a fallback string to that code line logics and I just did it in this latest commit:
https://git.drupalcode.org/project/leaflet/-/commit/7ea8a00a229f435d7f94...

Hi @f0ns ... now probably better understand your needs here.
Yes, at the moment the Leaflet module is using the leaflet-geoman js library to enhance its widget editing experience,
and that doesn't yet implement a geocoding/reverse geocoding address mechanism to input and manage your points insertions on the map.
May be we should find a way to add all that, but won't be immediate, and still haven't properly though about that ...

Also because the most proper way for inputing JUST Geofield POINTs on the Map would be (imho) to use the additional and complementary Geofield Map module → , that indeed implements a Geocoding additional Input element on the Geofield Field Map widget itself, and also the option to sync the Geofield itself with an additional Entity Field that could act as Reverse Geocode result on the map.
As Geofield Map Widget backgrounds Tile you can still use Leaflet js library and also the Geocoder module integration, with GM module, so not forced to rely on Google Maps API Key for that ...

Hope this helps you further ...

Further checked this and still working as expected, with Leaflet version 10.2.25.

See the attached screenshots,
this Leaflet Demo page:
is working with version 10.2.25
has the "Icon Class Name" setting configured with {{title}} replacement

and all working as expected.
I also made sure that things also work without token / replacement result, and it works ...

No to much to further comment here, on Leaflet version 10.2.25

Complex (depending on the Leaflet plugin to add) ... but not impossible, I guess.
I didn't try so far such a thing ...

First of all I wouldn't say "replace" but simply implement the Leaflet Popup plugin you want, probably in the following way:
1. don't enable any Leaflet Popup throughout this Leaflet View (or Formatter) settings ...
2. use the 'leafletMapInit' (or the same 'leaflet.map') event, defined here:
and available once the Leaflet Map is loaded, to interact with the Leaflet Map itself (data.lMap) and its markers (data.markers) adding your code (and new Leaflet Popup plugin or whatever else) the way you prefer ...

Of course you should be able to properly manage Leaflet JS library and its js coding practices ...

As further hint, something similar (additional interaction with loaded Leaflet Map, and its markers) is being done in the Leaflet module demo map itself, here: https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geoplaces-ma...
to make the list of right sidebar Locations interacting with the main Leaflet map in the page.
Check out the instructions below the righter itself and in particular look at the additional js file implementing all that (throughout the Drupal.behaviors.geofieldMapLeafletMapInteraction) from here:
https://www.geodemocracy.com/drupal_geofield_stack_demo/web/modules/cust...

Hope all this helps (to better help yourself and find your specific way).

Agreed. MR !48 merged ... all this will be part of next Leaflet module release.

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

May be you are a bit confused between what is a Formatter (that is the way fields are shown in the FE) and what is a Widget (that represents how a field is managed / setup in the BE), in the Drupal conventions.
You mention you want to accomplish the Popup in the Leaflet Formatter, BUT you post the screenshot of the (Leaflet Map (default) Widget instead.

Thus, please move away from the "Manage Form Display" TAB (that manages fields widgets), and rather move to the "Manage Display" TAB (that manages fields formatters) and there configure properly the Leaflet Map Formatter, also with the Leaflet Popup section / option, that supports "Replacements Patterns" (@see the attached screenshot).

Keep in mind that same Leaflet Popup section / option is also available into the Leaflet Map View settings (with Tokens support).

Having received Maintainer privileges, I am merging all this into the 2.x branch ... and closing this.
I am going to deploy a new 2.1.0 Entity PDF module version with all this General improvements.

Yes, indeed I could reproduce this issue, after a clean Drupal 11 install, though pretty weird this doesn't happen in my existing Drupal 11 (and 10 site).
I could see that the GeofieldMapSettingsForm is not passing the needed second TypedConfigManagerInterface object to the ConfigFormBase parent object.

Anyway I implemented a better fix (that the classical proposed in patch #4, thanks anyway for that) with this commit:
https://git.drupalcode.org/project/geofield_map/-/commit/969a7eb21104bca...
where the GeofieldMapSettingsForm is refactored to rely on the dependency injection container for adding new services instead of overriding the constructor (@see https://www.drupal.org/node/3076421 → )

New releases of geofield_map ( 11.0.2 → and 3.0.24 → ) are solving all this ...

No evidence of this, that looks just assumption or wrong setup on your side.

The GeofieldMapSettingsForm constructor was created 7 years ago ... (and apparently never changed)
https://git.drupalcode.org/project/geofield_map/-/blame/11.0.x/src/Form/...

Cannot replicate what you report, at all.

Suggestion: clear you drupal cache, if not yet done ... and (if not solved) eventually check what kind of override you are injecting on that Form setup / constructor.

Eventually, reopen and mark this as bug, ONLY if you have clear and objective evidence of the bug you found.
(just assumptions, sorry, are not enough).

Last but not least, a screenshot of the new implementation of an "Entity Pdf Download" action plugin, to automatically generate collated (paginated) pdf entities, via Views Bulk Ops.

PS: this MR!4 changes are both major improvements to the Entity PDF code quality and functionalities, so as they (should) stay respecting complete backward compatibility with the actual 2.0.6 module release ...
Anyway all this could be reflected into a brand new 3.0.0 release of the Entity Pdf module (if not a more simple 2.1.0).

Ok ... the MR!4 implements the following tech features:

• adoption of README.md file with module documentation
• extended compatibility with Drupal 11
• implementation of an "Entity Pdf Download" action plugin, to automatically generate collated pdf entities, via Views Bulk Ops, directly replicating a similar action present (and very useful) in the Entity Print module (https://git.drupalcode.org/project/entity_print/-/blob/8.x-2.x/src/Plugi...)
• replacements of many \Drupal calls (that should be avoided in classes) in favour of the correct use dependency injection
• perform Drupal and PHP coding standards fixes and full compliance with phpstan quality standards and phpcs quality standards (according to Drupal, DrupalPractice and Slevomat CodingStandards)
• implementation of GitLab CI

and is ready for QA and Peer Review.

Note: Due to the amount of contribution performed on this, I felt to add also myself in the list of maintainers of this Entity Pdf module, in the newly added README.md file. Just feel free to object on that, eventually ...

itamair → created an issue.

It what you report is totally out of the real Geocoder 8.x-4.x actual branch, that as instead the following composer.json requirements:

    "require": {
        "php": ">=7.3.0",
        "php-http/guzzle7-adapter": "^1.0",
        "php-http/message": "^1.6",
        "willdurand/geocoder": "^4.0",
        "davedevelopment/stiphle": "^0.9.2"
    },

as reflection of its actual code base:
https://git.drupalcode.org/project/geocoder/-/blob/8.x-4.x/composer.json...

Closing this, as totally misaligned (untrue),
and also not properly taking into account this parent (duplicate) issue:
https://www.drupal.org/project/geocoder/issues/3283651 ✨ Drupal 10 compatibility: changing php-http/guzzle6-adapter dependency into php-http/guzzle7-adapter RTBC

Thanks ... I felt free to extend and use all the available 200 chars, with the following summary:

Provides a geo-location field for storing and managing geographic data, enabling the integration of maps, geocoding and location-based functionalities. It supports all geo-types (points, lines, polygons, multi types geometries).

Regards

thanks @erikbrgn ... nice catch.
Agreed. Going to merge this into both 11.0.x & 3.0.x branches ...

Thanks here, nice catch ...
This latest attached patch is adjusting the getGeoJsonData method so to admit also $entity_id null values, thus still preserving the generation of a geofield map preview.

It has already been committed into 11.0.x and 3.0.x dev branches, and is going to be parto of the next incoming 11.0.1 and 3.0.23 releases.

Regards (and happy mapping with Drupal Geofield Stack modules!)

Indeed I could replicate this issue / blocker ... but indeed this looks strictly related to the specific "Read-only Field Widget" module way of altering the default / specific field widgets, basically translating the Formatter UX / logics into it.

Hence I changed this issue Tile accordingly, because definitely this looks something potentially (& specifically) caused by the "Read-only Field Widget" module ... and may be not a Geocoder bug / limit, isn't it?

I can also see that the provided patch is successfully working around this "Read-only Field Widget" use case,
and I don't know if this deserves more inspections and debug analysis, and a more solid solution.
(every body is welcome to provide further contribution on this ... ).

Let's mark this as ready for review and let's see if some further opinion come to better understand what should be (eventually) committed in the Geocoder module codebase (this patch or something more solid and general).

What about also opening a new issue in the "Read-only Field Widget" module thread that points to this one?
May be its maintainer(s) could better understand what to fix / adjust and where ...

@hswong3i I better reviewed this feature Request of you and QAed also the MR !40.
and then I also included some enhancements that reflect a new Fork and consequent the following PR#1 to the drustack/Leaflet.SyncView repo itself:

https://github.com/drustack/Leaflet.SyncView/pull/1

That have the following tech specification:

Refinement in the L.Control.SyncView.js:_pullView function #1
This PR implements the following:

parsing of Lat and Lon to 6 digit float;
trigger dynamic sync / update of the proximity-origin-summary Lat and Lon elements (eventually present in case check/selection of "Show (anyway) the Origin coordinates as summary in the Exposed Form" option
This implementation syncs with latest improvements implemented in Geofield version 8.x-1.61 → ., greatly aimed to enhance dynamic sync between Origin coordinates input and Origin coordinates summary elements.

It would be great if you could merge that PR1 into master and deploy a new 1.9.3 release of drustack/Leaflet.SyncView.

We then should just update this Version number in the MR !40:
https://git.drupalcode.org/issue/leaflet-3254562/-/blob/3254562-add-drus...

Thanks a lot! @hswong3i ... finally I get the nice value of your work and inputs.
Indeed this looks a very useful add-on and setup to search by a specific area and mostly to limit the number of loaded market on the map.
I am going to definitely better inspect this solution of you, and eventually embed in the leaflet module, with proper documentation.
ASAP ...

ok ... I better inspected all this and I must say that it doesn't match my agreement.

First of all the Title of this issue ("Dispatch events for certain situations") trigger a wider use context compared to the specific use case the provided MR / Patch tries to implement ... (that only focus on the Geocoding failing cases).

Furthermore there is a not so strong and opportune use of the drupal_static function (in my opinion), because of the following:
- drupal_static() and drupal_static_reset() are going to be soon deprecated ( https://www.drupal.org/node/2260187 → );
- from my test (on the MR !58) passing the whole ContentEntityInterface $entity in drupal_static doesn't work, as the &drupal_static(self::STATIC_ENTITY_KEY) will always return NULL (rather / eventually a string, such as the $entity->label() should be used ... );

It looks (to me) a much better and more general approach should be implemented, to comply to this title ambitions / goal ...

Thanks here ... this looks a nice feature / add on and a technically correct implementation, that indeed will dispatch a specific Geocoder Event every time a Geocoding operation is going to fail, but why do you call it GeocoderLogEvent instead of something more properly related to the specific context you want to intercept / catch, and that is strictly dependant from a caught exception message?

Rather I would define a GeocoderFailExcpetionEvent and trigger it only in the same Geocoder catches exceptions that you pointed.

GeocoderLogEvent sound more something that might / should be dispatched every time a 'geocoder' log is generated in the system, isn't it?

Closing this for lack of activity and feedback.

It looks this support request was spread / duplicated in almost every Geofield Stack modules.
Please refer to this parent issue: https://www.drupal.org/project/geofield/issues/3466765 💬 how to get users location from browser programatically before going to map Fixed

Patch #2 committed into 10.2.x dev branch, will be part of the next Leaflet module release.

Thanks for this heads-up. Patch provided accomplishing what is being requested ...

Patch #4 committed into 10.2.x dev branch, will be part of the next Leaflet module release. Thanks ...

Thanks! Nice catch @woutgg ... merged into 10.2.x dev branch, going to be part of the next Leaflet module release.

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

thanks @mandclu ... what about the attached patch, rather?
We would keep the weight option schema for the "leaflet_map" view settings plugin and skip it for the "leaflet_formatter_default" plugin.

Cold you QA and review also this, and provide your feedback (does it solves yours issues with tests?)

I would prefer to keep the weight property in the leaflet_views/config/schema/leaflet_views.style.schema.yml file

Nice catch. Thanks @frankied3 ... patch #2 committed into dev branch. Will be part of next incoming Geofield module release.

This doesn't look any evident and general BUG,
and it should depend from your specifici Geocoding / Geocoder setup.

Using this Geofield demo page: https://www.geodemocracy.com/drupal_geofield_stack_demo/web/
I can easily look for Plymouth and select the GBR specific one result ... (@see the attached screenshot).

Closing this, due to lack of activity, after being marked as "needs review".

Closing this, due to lack of activity, after being marked as "needs review".

Take inspiration from this comment of mine, of some time ago, that is still valid:
https://www.drupal.org/project/leaflet/issues/3212148#comment-14092596 →

Note that leaflet.drupal.js triggers both 'leafletMapInit' and 'leaflet.map' events once the map is Initialised, through which you are able to get and interact with each leaflet map on the page, and their Markers.

Ref: https://git.drupalcode.org/project/leaflet/-/blob/10.2.x/js/leaflet.drup...

In the "Path Geometries Options" settings block you could use the following option:

"interactive":false

according to this Leaflet Js property:
https://leafletjs.com/reference.html#interactive-layer-interactive

See the attached screenshot.

New leaflet_more_maps 2.2.2 release → implements Drupal 11 support ...

@W01F still cannot reproduce this issue of you,
as all looks properly translated in the Leaflet Popup, also when the Leaflet Map (Formatter) in injected and rendered throughout the Layout Builder.

I also specifically provided the following translated Content demo page, for your evidence:

Fat Cat: https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geo-place/fa...
Gatto Grosso (corresponding in Italian): https://www.geodemocracy.com/drupal_geofield_stack_demo/web/it/geo-place...

Note: Differently from the Leaflet Formatter field (first map on the right region),
the second bottom map (below on the right region) is being rendered with the following technique (that I prefer over the Leaflet Formatter):
- still use the Leaflet View style, but render only the feature / item corresponding to the node that is being viewed (throughout the Contextual Filter);
- inject the above set Leaflet View in the specific Node content View throughout the View field module (properly setup for the specific Node / Content type): https://www.drupal.org/project/viewfield →

Hence, I cannot say what could be wrong on your side / setup (also because all looks good to my side ... ),
BUT, if Leaflet Popup translations works fine with the Leaflet View, well, surely you could go with the 2nd Leaflet Map View technique that I briefly described here ...

Thanks for all this contribution ... BUT I parallel worked on this and opened a new 11.0.x main branch that will support ^10.2 || 11 from now on, and that is going to become the default branch too.
New geofield_map 11.0.0 release → deployed with this.

Great! New leaflet 10.2.24 → just released with all this ...

Sorry, new final patch, that re-adds the leaflet-geoman library version tag (removed by mistake) ...

thanks @steven ... for your detailed and clear explanation.
I would go for the simplest solution, also from the maintenance effort side (that is already quite demanding an all this geofield stack modules), hence simply remove all the versioning tagging and management for libraries that are not remote/external ones,
considering that you don't highlights any caching side effect doing this, but rather a proper and automatic handling from the PHP cashing/cashing system ... isn't it.

Please, give me a final green flag on this new attached patch, or let me know what might be stil missing.
(and super thanks again for your guidance ...)

Thanks Steven ... yer right you are, I missed the leaflet-drupal library version fix/update,
thus here it is a new attached patch, that includes also it.

For what regards the naming approach I am taking inspiration from the Geolocation module that is using as version the same dev branch name:
https://git.drupalcode.org/project/geolocation/-/blob/8.x-3.x/geolocatio...

This might have the advantage not to need an update of the version for each new release of the module, and of the specific js/css release and I am assuming it will behave similarly to the option 2 that you mentioned and the js/css caching system will look for hashed changes in each library?
Or would I be too much optimistic on this?
What would be the behaviour in case of this naming simply based on the module release dev branch?

Thanks a lot Steven ... that all makes sense,
and also according to this article from Chromatic: https://chromatichq.com/insights/drupal-libraries-version/

With the new attached patch I comply with your suggestion and fix all the not Remote libraries versioning, aligning them with the current dev branch.

Please QA and Review this attached Patch (which is more accurate than the provided MR !43), if you have some more time on this ...

Please don't report and mark issues as Bugs if you don't have clear evidences that it is so, and only assume due the fact things don't work as you expect on your specific side.
Moreover you are referring to an existing similar Bug report that looks resolved / fixed.

Indeed I cannot reproduce what you report (with latest 10.2.23 Leaflet version) and all looks good on the Translations side, both on the Leaflet Popups and Tooltips and whatsoever, as you can see from attached screenshots.

In the end the Leaflet View Style is reflecting normal translation features of the View module itself, and you should probably address this issue on your specific setup.

For instance, make sure you you are using proper Content Translation setup, Translation detection and negotiation, so as
Rendering Language: Interface text language selected for page
in Language View Style setting ... etc.

Move this back to BUG only if you have deeply debugged what is wrong in the Leaflet module code base and you can clearly prove and document you buggy code findings ...

all good with the polygons and multi polygons with new Leaflet module 10.2.23 ...
and also with your attached one (see the attached screenshot).

Just make sure to clear the cache of your browser so that it refers and loads the new version of the js/leaflet.drupal.js file ...
(trying with private navigation helps on this)

thanks a lot @iamfil ... I QAed and Tested your MR!19 and it looks having much sense and not introducing any evident regression (also in the Lazy Load ...).
thus I merged it into the 3.0.x branch. All this will be parto of the next incoming Leaflet module release,

Hi @dianacastillo
I recalled that this was faced sometime ago, but couldn't make it work by some embedded setup / settings in the Geofield module,
and (I feel) some custom frontend js hack should rather be applied.

Please refer to this existing issue / thread that looks very related to what you are trying to accomplish:
https://www.drupal.org/project/geofield/issues/3065776 →

Hi @dianacastillo
I recalled that this was faced sometime ago, but couldn't make it work by some embedded setup / settings in the Geofield module,
and (I feel) some custom frontend js hack should rather be applied.

Please refer to this existing issue / thread that looks very related to what you are trying to accomplish:
https://www.drupal.org/project/geofield/issues/3065776 →

Patch #6 was deployed into the 10.2.x branch, and new Leaflet 10.2.23 release was deployed with all this.
Thanks @Irina.povjakel for your contribution and MR (that I am going yo close).

BTW, a relevant question Kristen on this.
The Geofield Map doesn't show up AT ALL in my Project Browser search, and also without this customized Logo (as you can see from the attached screenshot), though it correctly appears in the project_module page (even searching just for "Geofield"): https://www.drupal.org/project/project_module?f%5B0%5D=&f%5B1%5D=&f%5B2%... →

Do you have any clue why that is happening (and rather NOT happening)?
Is the Project Browser module still missing some modules search indexing?

thanks Kristen,
I fixed that, so that now you can see the logo.png in the 3.0.x branch:
https://git.drupalcode.org/project/geofield_map

I attach here the exact version that was committed, that can still look a bit blurry,
but that comes from the perspective distortion applied to the globe with the cardinal points, through the raster program Procreate, and given the 10k limit reached via pngquant.
But it doesn't seem like a big issue to me, also given the small size with which this logo is represented with the Project Browwser.
I really can't do better than this (in terms of logo definition).

Bugs cannot be reported in this easy way, with no evidence and with this clear lack of context and information.
You don't provide:
- any description of what you experience;
- any clear/objective evidence that it is a general Bug, and not caused by a potential custom setup of your project environment;
- you don't provide any information on how to clearly (and objectively) reproduce what you report ...
- you don't also provide any screenshot go what you report, to better help who is supposed to support and re-act on this ...

On the minimal info you provide only in your title (that you also changed) I cam say that all is working good on the Geofield Map side (
3.0.20), on the Geofield Map View, with Proximity Filter, Ajax and Cache enable,
as you can check from this demo Goofield Map Page: https://www.geodemocracy.com/drupal_geofield_stack_demo/web/

Hence, I am moving this into normal Support Request and Closing as cannot reproduce.
Please reopen this only providing proper and detailed documentation, and info on how to reproduce your use case.

Set this as Bug ONLY if you can provide clear and objective way that it is a General Bug, and not an assumed one on something on your side that doesn't behave the way you expect (and that could depend by so many things from your setup).