🇩🇪Germany @christianadamski

christianadamski → created an issue.

christianadamski → created an issue.

I just logged out and tried to access an /admin page and was not redirected...

That did not work. I don't know how to build this. I exported it as is.

I don't know how to build this workflow. Just exchange to event?

christianadamski → created an issue.

Well, can you look up, if Tianditu is officially available worldwide now? I remember a year ago, I could not access there website, now I can...

If it really and officially and permanently is available everywhere, we could merge it back to geolocation.

I may have the same problem as with Baidu though: I cannot get map keys. For Baidu you need a chinese commercial something number. I don't have that obviously.

christianadamski → created an issue.

Please remove or explain the placeId usage and the sessionToken

This change does a lot more though...

Seems outdated? Nobody else came forward with a problem..

I had to alter it a bit..

Thanks!!

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

christianadamski → created an issue.

There are Formatters for the address field available in v3 and v4...?

christianadamski → created an issue.

christianadamski → created an issue.

I checked with tour module as well. I'm closing this. Please open a new ticket if clear reproducable issue occurs.

Thank you!

This was a lot worse than expected. The order of dependent libraries was not as Leaflet expects them for extensions.

1.) Leaflet library
2.) Extension library
3.) Instantiate Map
4.) Interact with extension properties

The MR here now adheres to that order. There is unconnected test failures with Google, afterwards this will merge.

Thanks!

Hu, this might simply be wrong? Or maybe it changed?

I cannot find any gestureHandling options in the leaflet docs right now. Maybe this was wrongly copied from Google Maps?

I think this needs to be removed completly?

Best to use the token support in combination with views.

4 Options:

1.) Use a custom module to override icon path.
2.) The icon path supports tokens. Use current user token object and go from there.
3.) Use CSS to alter the icon if the user class is i.e. added to body.
4.) Use ECA module.

This is already both in 3.x and 4.x... (?)

Ok, good to go I guess.

I tested locally with 3.0-rc15 and transferred the changes manually. So didn't technically test 4.x, but the code is identical, so should be the same.

For which version? 4.0.x? And then run webpack dev? Anyway, tomorrow...

Well, perfect example actually. See attached Screenshot of the tugboat install.

form ID and data-drupal-selector diverge after AJAX call. So the more-actions.js code does not apply anymore.

It seems however, that it is simply not executed here?

Want me to write an MR? If yes, what approach would you prefer?

So, the code needs to either query by ID instead of data-drupal-selector, or get the selector by ID first, and then use that next.

This is current 4.0.x:

https://git.drupalcode.org/project/gin/-/blob/4.0.x/js/more_actions.js?r...

formId is still directly used as selector for data-drupal-selector.

christianadamski → created an issue.

christianadamski → created an issue.

In v4 this is already done. It has quite substantial implications though and disables a number of features, which would break existing installs.

So I won't alter this in v3.

Thanks for your patch nevertheless!

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

v4 I already merged (and released) separately.

Hmm. Ok, I'll see if I get around to testing v3.

v4 is fixed. You opened a MR for v3. I haven't tested it. Did you extensively? Can I merge blindly?

Works locally in current -dev.

Any opinion? Will close in a few days if this solved itself.

The parent form is still the node form. So I don't see an obvious way to clearly identify the matching address form element relative to the geolocation form.

Right now I think it will come done to CSS selector guessing :(

I'm at DrupalCamp Berlin. Spend whole day looking at this. Not simple.

Could you in more detail describe the scenario? What would I have to set up to recreate this?

Just in case this is in any way helpful:
Geolocation module v4 moved to almost complete ES6 modules. A lot of them. And for lack of importmap support its all handled by dynamic imports. And they spread out over 10 sub-modules.

So, this is already out there and I would be more than happy to move away from keeping track of all the relative paths and to an importmap mechanism provided by core.

christianadamski → created an issue.

Are you sure this is about the geolocation module? Not Geocoder? Or Geofield?

If you are sure, please provide more context and what you did, what you expected and what you got instead.

1.) I don't see any CSS that geolocation would add there? Please provide a patch or Merge Request of what you have in mind.
2.) Please note, that InfoBubble is effectively discontinued by Google. The library has not been updated in many years and is incompatible with their new "AdvancedMarkerElement".

christianadamski → created an issue.

Please remember this is an unpaid hobby project by single developer. Be kind.

Updating settings from v3 will be added soon.

There are unified geolocation_map formatter/widget now for all supported Map providers. I will work on v3-v4 update soon.

christianadamski → created an issue.

christianadamski → created an issue.

Took a moment.

The migrate process plugin is called "geolocation_wkt_to_geometry". It should transform to geojson by default, but you can target differntly via "format"-flag.

This is not tested, didn't have WKT around.

christianadamski → created an issue.

christianadamski → created an issue.

christianadamski → created an issue.

Thanks, but no more v7 releases...

v3 does not really support layers. v4 does, but it's still a few weeks from beta1.

Could you describe exactly how I could recreate your scenario do get an idea what to achieve?

I see a whole bunch of migration D7 files in the geolocation_address sub-module. I do not remember writing those, so they where probably contributed by somebody.

The are aimed to move location_cck fields to address fields through geolocaiton gecoders. So that is not what you want. But maybe still helpful?

What exactly would be the goal here? Just get location_cck field data to geolocation and done?

Comitted a simpler version, hope it works.

Thanks!

As per @socialnicheguru - considering this fixed. I cannot reproduce this.

v4 works fundamentally differing.

christianadamski → created an issue.

Ah, what exactly? Not too familiar with D7 - D10 migration. What exactly would you put where to enable what?

Happy to commit something, if it might help others.

Comitted your patch. Thanks!

It's under my name. I don't know how to combine patch and MR with attribution. I hope assining authorship here works too.

Ok, so what I see trying on simplytest.me, is that when simply choosing the map widget, the "nominatim" geocoder will be set, which is not usable in the frontend.

This is no problem when opening the widget settings at least once, as then a different one will be set.

Not ideal, but not broken.

@flyke: that seems to be a different issue. Please open a separate ticket, if the issue still persists.

I'm closing this issue, as I'm focused on getting v4 ready. Sorry for the inconvience.

Google works fine for me, but for Leaflet can confirm

Did this fix itself?

I understand this is inconvienient, but due to limited resources, I won't work on this in v3 anymore.

This is not reproducible on simplytest.me in v3, not v4.

This is broken with any custom data (like custom map settings) as far as I can tell and I don't know how to fiy this.

Hey,

if you really want to work with multiple layers, v4 might work much better. You can create layers freely in views there or provide them custom in code. Also the features on the map can be added on a per-layer basis.

v4 is still WIP though.

Ok?