dhpunkt

@Martin A. Thank you so much for the fix, manual location update is now working here. 

There is still a tiny bug, the matching characters of the search result are wrapped in <strong>-tags after selecting the entry. However, it's still working fine.

---

Feature request

Your map is very useful for our community, Our members are working remotely and their location changes often. So far we made the experience that most of their locations are outdated, cause they forget to updated it. (It also happened to me...)

What do you think about an auto update feature? Every x day(s) when accessing the community the current geolocation is matched with the stored location. If the difference is more than x km, a dialog appears: "do you like to update your location?" 

6 hours ago, haqzore said:

@Martin A. - when I try to "Add Location" and use the "Enter your zip code, city, county and/or state/province, then pick your location from the results"... It is non-responsive. Nothing happens or loads, regardless of typing / hitting enter / clicking save / etc.

Thanks for the latest update, @Martin A., great that you could fix geocoding!

Autocomplete is also not working here. Response of the locationSearch AJAX request:

{"statusCode":"400","error":"Bad Request","message":"\"lang\" must be one of [ab, aa, af, ak, sq, am, ar, an, hy, as, av, ae, ay, az, bm, ba, eu, be, bn, bh, bi, bs, br, bg, my, ca, ch, ce, ny, zh, cv, kw, co, cr, hr, cs, da, dv, nl, en, eo, et, ee, fo, fj, fi, fr, ff, gl, ka, de, el, gn, gu, ht, ha, he, hz, hi, ho, hu, ia, id, ie, ga, ig, ik, io, is, it, iu, ja, jv, kl, kn, kr, ks, kk, km, ki, rw, ky, kv, kg, ko, ku, kj, la, lb, lg, li, ln, lo, lt, lu, lv, gv, mk, mg, ms, ml, mt, mi, mr, mh, mn, na, nv, nb, nd, ne, ng, nn, no, ii, nr, oc, oj, cu, om, or, os, pa, pi, fa, pl, ps, pt, qu, rm, rn, ro, ru, sa, sc, sd, se, sm, sg, sr, gd, sn, si, sk, sl, so, st, es, su, sw, ss, sv, ta, te, tg, th, ti, bo, tk, tl, tn, to, tr, ts, tt, tw, ty, ug, uk, ur, uz, ve, vi, vo, wa, cy, wo, fy, xh, yi, yo, za]"}

I'm not talking about the date/time that is shown, it's correct. The event disappears before it has started. I have to change my computer's timezone to UTC to make it work.

I guess this is not how it's supposed to be?

2 hours ago, Marc Stridgen said:

Could I please confirm you are aware these work on UTC, and will therefore always follow that timezone?

I'm not aware of that or maybe haven't got your point.

When we create an event we can select its timezone. I think it defaults to the timezone of the client who's creating the event:

In our database the event start date is correctly(?) stored in UTC

The issue: In the upcoming events block the event disappears at 16:00:00 client time, regardless of the client's timezone - i.e. my computer is set to Europe/Berlin time and the event is only visible until 16:00 local time although it starts at 18:00 local time.

When I change my computer's timezone to UTC the block works as expected. 

Thanks for clarification. We have the same issue on our production installation, I created an account for you.

On 8/11/2022 at 9:33 AM, Marc Stridgen said:

You have no licensed live URLs with that domain.  Please could you clarify?

Yes, this is our test URL that is running on the most recent IPS version. You can find everything to access in our profile. 

Do you need access to our live system as well?

I double checked, ACP is accessable for user invision.[...] (full admin).

I saved all credentials again, hopefully it's working now!

The relevant domain is: dev.me[....]

Thank you, @Marc Stridgen - I've updated the access information.

Let me know if you need anything else from me.

Hello,

we're heavily using the upcoming events block and experiencing an issue. Depending on the user's timezone events are disappearing too early / too late.

Most of our users are in Germany and events disappear 2 hours before the actual time (GMT+2)

Is this a known issue? Anything we can change from our side? (self hosted community on PHP 7.4)

Best
Dennis