🇮🇹Italy @itamair

thanks @jlstrecker for better describing the use case you wanted to solve ..
and Only now I had the occasion (let me confess) to have a look to your custom code implementation from #2.
Smart one ... basically you are extending / overriding the existing Drupal.Leaflet.prototype.initialise and Drupal.Leaflet.prototype.create_point methods ...
.
BUT (? question) wouldn't you be able to accomplish the same results taking advantage of the 'leafletMapInit' event (or the same 'leaflet.map' one), defined here:
https://git.drupalcode.org/project/leaflet/-/blob/10.2.x/js/leaflet.drup...
and available/triggered the first time the Leaflet Map is loaded, and then interact with (or even alter) 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 ...

This long standing issue was created to better explain all that (how to interact and alter with generated Drupal Leaflet Maps and its Properties, Features etc.)

That isse also drives you on how to better inspect that Live Demo Drupal Leaflet additional Drupal.behaviors.geofieldMapLeafletMapInteraction ....

Let me know if this could also help you, or Not, you still need to alter the original methods.

sorry sorry my bad ... @jlstrecker
I wanted to point to this comment of you (and that related issue):
https://www.drupal.org/project/leaflet/issues/3129345#comment-15815947 💬 Displaying marks as map pans Active

Doesn't it also solve also this one for you?

@jlstrecker doesn't this comment of you (and related Fixed issue) solve this issue too?

Please close and mark this as Fixed in that case.

Thanks @phenaproxima for your clarifications .... and all your time!

another question, sorry @phenaproxima
as you just removed what looked an practical tool for easily generate a Drupal Recipe,
is it out there any handy way / tool, or even instructions on how to to easily generate a Drupal Recipe, from a working Drupal site?
I couldn't find any, so far ...
Only this looks aiming to that goal: https://www.drupal.org/project/recipe_generator →
but it also looks pretty outdated and not supporting Drupal 11.

Ok... got it,
But @phenaproxima as for the officiality of that wiki page, well
note that there is still a clear link to that in the Readme.md file itself (https://git.drupalcode.org/project/drupal_cms/-/blob/1.x/README.md?ref_t...)

itamair → created an issue. See original summary → .

I also report and confirm that this also happens to me (atm)
with the same setup of mine (described in this issue description, this with Safari 18.0, etc.)
with the install / build from the Drupal CMS GIT repo itself (https://git.drupalcode.org/project/drupal_cms)
if I run the following commands:

ddev start
ddev drush site:install --yes
ddev launch

as instructed from the "Contributing to Drupal CMS" page: https://git.drupalcode.org/project/drupal_cms/-/wikis/Contributing-to-Dr...

@pameeela here it is ...

I am testing on the 1.0.0-rc2 ( https://www.drupal.org/project/cms/releases/1.0.0-rc2 → )

I don't use DRUSH
and I simply follow the instructions and run (from my Terminal inside PhpStorm) the following script:
./launch-drupal-cms.sh

with the following setup:
MacOS X Sonoma 14.6.1
Safari 18.0
ddev version v1.24.1

and checking NONE of all the available pre configured types of content (blog, case studies, events, news, person profiles and projects).
But this also happens when I check some of the above.

Indeed all the process lands nicely in the Dashboard
BUT then when I click on the"Back to Site" link or on the Drupal drop icon (top left) and visit the Home / Front Page for the first time, the Hero image is not yet loaded / found as styled image ... in this use case of mine (this is not random, but happens every time to me)
(further screenshot attached)

Personally I couldn't reproduce this, just running the installer:
./launch-drupal-cms.sh

with the following setup:
MacOS X Sonoma 14.6.1
Safari 18.0
ddev version v1.24.1
and checking NONE of all the available pre configured types of content (blog, case studies, events, news, person profiles and projects)

The Drupal CMS sites builds fine to me,
but (still) for the NOT generation of the Hero home page ( https://www.drupal.org/project/drupal_cms/issues/3494618 🐛 Drupal Cms Front Page Hero image not visible in the first load / visit (needs a reload) Active )

Thanks a lot! I just re-tested the ./launch-drupal-cms.sh script / installer and all LGTM on my Local Mac OS X Dev env.

itamair → created an issue.

Great job. Thanks a lot!
Will try the new installer asap.

@pameela ... for sure!
Sorry, mine have nothing to do with complaints, but only feedback to try to represent the user experience of those who want to satisfy

What worked for me is unzipping the file directly in terminal.

Yes, ok. but assuming that a "normal" (marketers) users should only rely on the Terminal and stay far away from their Finder / Windows tools looks really mismatching with original goals of the Drupal CMS project

And after working around all the above I then now hit this new blocker:

[omissis]
Executing Composer command: [composer create-project drupal/cms --stability=RC --no-plugins --no-scripts --no-install /tmp/TAfujZ]

OCI runtime exec failed: exec failed: unable to start container process: current working directory is outside of container mount namespace root -- possible container breakout detected: unknown
failed to create project: exit status 126
stderr=
[omissis]

attaching a new related screenshot from my PHP Storm

and restarting over ... FYI I now have the following blocker:

./launch-drupal-cms.sh
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted
bash: ./launch-drupal-cms.sh: Operation not permitted

Brilliant!
But all this might easily block or mislead any normal Drupal CMS user, not so expert of any Terminal and that is so confident in opening folders in the Finder.
So I really think that rm -f .DS_Store should indeed be added to the launch script.

Worth to mention also that after running the rm -f .DS_Store and then again ./launch-drupal-cms.sh
I now receive the following stopper:

FATAL: We do not appear to be in a Drupal CMS project.

And what is that, now?

Pretty frustrating and hard to go through, for a not coder user (that the Drupal CMS is expected to speak to), isn't it?

Should I assume I need to start everything over, from the initial drupal-cms.zip unzip?

itamair → created an issue.

Thanks @phenaproxima!
Indeed upgrading to DDEV 1.24.0 fixed my issue ...

itamair → created an issue.

Ok I better inspected all this and all makes great sense to me also.
I just added a commit on better commenting.
Going to deploy this into new incoming 8.x-4.26 Geocoder release.

Thanks for al this, but I had some difficulties to understand that and how the attached #2 patch and the MR !60 are going to solve kind of same goal but in two parallels contexts of Migrations and Workspace publishing.

It looks most of the folks here do belong to TAG1 and perfectly know what they are debating about and accomplishing (as the Workspace module logics) but it would also help some better description that is going to be implemented here.
I kind of did it ... digging in the the MR !60, and its dependencies,
BUT it would be hard for a normal contributor to understand what is going here, also because the Workspace module is still missing basis documentation and help content (isn't it?).

So I feel to forward the following requests:
- could you proper provide some better extended description of what is being achieved here, at once on both Migration and Workspace sides, and mostly ...
- could you properly let me know if both the #2 patch and the MR !60 should be deployed in parallel (as RTBC) or even better could / should everything (from the #2 patch) be grouped / embedded in the MR !60 itself, if opportune?

Thanks!

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

Most of the Php & Drupal Cs reported here were already solved in the Geocoder latest releases code.

This commit https://git.drupalcode.org/project/geocoder/-/commit/9ba4e5aac48cae4bd35... is fixing this.

Thanks. Merged. Setting this as Fixed.

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

Thanks here, nice contribution ... I just merged the MR !53 and I am closing this as Fixed
(and providing credits to all of you)

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

Well ... ok. Nice catch.
You forgot to generate he MR from the Fork,
but I guessed what you meant and committed into dev branch.
This will be part of the new Geofield Map release.

11.0.2 release looks now D11 nicely compatible

Thanks @mrcdrx ... nice catch.
This last commit https://git.drupalcode.org/project/leaflet/-/commit/e4499518816dd52dc98c... implements your patch but with a better positioning of the 'weight' default value in the array.
Closing this as fixed (and crediting you).

Thanks a lot @jan kellermann
indeed the Klaro module looks an effective solution to this issue, with its service to block Leaflet ( https://www.drupal.org/project/klaro/issues/3491325 ✨ Add service to block Leaflet Active )
and the new Leaflet 10.2.28 release → already supports it!

hi @folks ... thanks a lot,
this related Leaflet issue: https://www.drupal.org/project/leaflet/issues/3491298 ✨ Add Attributes to template Active
has been fixed and is already part of a brand new Leaflet 10.2.28 release.
Thus, green flag for Klaro support to Leaflet maps!

Quickly QAed and Reviewed along with
#3491325: Add service to block Leaflet
I confirm that this works like a charm (and Leaflet with Klaro looks really smooth and eve more cool).
Merging ...
This will be part of a new incoming 10.2.28 Leaflet module release ...

Well, I didn't mean that the credit system isn't important. I'm very aware of it too... and I also recommend this recent article by Dries Buytaert which highlights the importance of contribution credits: https://dri.es/solving-the-maker-taker-problem

But I was just expressing the fact that I myself have often not received credits on some issues and modules to which I have contributed, but I personally have not made a big drama out of it, appreciating the work done by the maintainers anyway and taking for granted that maybe they have forgotten about it, or have considered my contribution to be of little importance.
In the end all this is done on a voluntary basis... and it's already a lot of time that goes into following up and solving the issues,
and as we have understood at the moment the credit system is not so clear and automatic.

As far as I'm concerned, I will continue to do as I have always done up to now (even if now with greater awareness of your explanations). That is, assigning credits to whoever I think is right by solving the issues as fixed ...
And I'm sorry if sometimes I forget or make a mistake in doing it as everyone would like (I'm not infallible, and I also have other duties to fulfill).

Bye, and see you on the next Drupal issue ;-)

@ressa thanks for your availability ... but the crediting is not such a big deal, in the end.
Myself is often not credited enough (or even at all) many times for all the job and the contribution spent in these modules.
But I don't do for being credited on every single commit I do ... but just to make these things / modules more solid and usable foro the Drupal community (and myself).

There is no permission role for just re-adjusting credits on past/fixed/closed issues ... and it is pointless to get any permission for no coding activities 8in this context).

Let's continue the way we work and have been working so far. Your care and contribution have been very valuable so far, on the Geofield stack of modules (and I hope will keep being) and I feel responsible for being sufficiently responsive when high quality contributors like you post something ...
And believe me this is not the case with many others, because indeed I am doing all this in my spare time, and without any payment,
but just as genuine passion and contribution to Drupal geomappig capabilities,

Bye and thanks again @ressa, and say hello to your (and my) dearest Denmark ;-)

Ok ... thanks @ressa for the further explanation.
But wow ... that looks pretty weird, and also weak.

So, please confirm me: it looks that someone is credited only when its username is checked and the issue is saved as Fixed?
Is this correct ... ?

Thus I could also fix and credit someone (that was originally not) simply re-opening the same issue (such in "Needs Review"), check the specific username and Resave it as Fixed again?
Would it make the work also ... ?

hi @ressa ... well, I read all you pasted on Crediting and sorry if I missed something,
but sincerely I don't know what I can do more with that ...

I always click on the contributors names (that look contributing to an issue) when committing a patch or something and you can see that in all these related commits there is the "by ressa" in the commit message.

But even in this latest one the commit itself (coming from the merging of MR !51) is at your name (you as author of the commit).
so indeed I assume the Drupal.org crediting system should be fairly happy with all this ... otherwise it is simply not working properly, and not reporting all that in the contributors profiles.

My apologises if I missed something here, and please explain me better and guide me how to rather assign credits (because may be your are more aligned with latest changes on that, and I am fully wilful to credit who contributes so nicely, as you do ... ),
because I am already dedicating much time in taking care of all the issues that come along all the Geofield stack of modules ...

ok @ressa ... nice catch.
This last commit accomplishes what you ask, harmonising the default values both for the Leaflet widget and the Leaflet Formatter & View settings:
if existing in the leaflet_map_get_info() results the 'OSM Mapnik' default map option will be set, otherwise the first in the list ...

This will be included in the new incoming 10.2.27 Leaflet module release

Thanks @ressa for reporting this, BUT I couldn't reproduce this on the official Leaflet Demo / playground: https://www.geodemocracy.com/drupal_geofield_stack_demo/web/geoplaces-ma...
all works as expected also in case of Zoom Fining +3 and even +5 ...

May be your attempt of Zoom Fining +3 is conflicting with your Max Zoom settings?
Please bear in mind that "Zoom Finer settings will still be constrained according with Max & Min Zoom settings" as specified in this last merged MR !51 / commit

Ok @ressa ... thanks to you.
I merged the MR !51 just adding a further comment / commit to specify that that Zoom Finer settings will still be constrained according with Max & Min Zoom settings.

#2 works!

Thanks @ressa for this heads up!
This commit https://git.drupalcode.org/project/leaflet/-/commit/146d53adec998339d37e... improved both Initial Zoom and Zoom Finer description/ help texts.
Will be part of the new 10.2.27 Leaflet module release.

Thanks. Merged / committed into 10.2.x branch, will be part of the next 10.2.27 Leaflet release.

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

Patch #4 committed into dev branch, will be part of the next Geofield module release.

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 ...