Locations Plugin

  • FIX: opening the global Topic map directly should not cause an issue
  • FIX: transitioning between a Category map and the global map should now work correctly
  • Non-functioning WIP map tests

@vincefrommtl, @Stephane_Roy @packman could you please give this update a try? Note the scope of the fixes. Another fix coming soon.

(Technical note: due to Leaflet library being a global object, apparently QUnit cannot see it, so I’ve not been able to provide fully integrated FE tests for these fixes - if anyone knows how I might get Leaflet and QUnit to play together please let me know)

3 Likes

My feedback:

  • Transitioning between the global map and a category map is working. But the opposite is broken (category map to global map), just like category to category.
  • I have not seen this error in my log since I upgraded: ActionView::Template::Error (No route matches {:action=>"map_feed", :controller=>"list"}). :slight_smile:
  • New bug: Sometimes, clustered links on the map are only showing the position marker on the map when zoomed in, not the label.
  • New bug: Sometimes, labels of markers on the map are not linking to the corresponding topic.
  • New bug: the global map is now affected by the same bug as category maps: only showing a few markers (see below).

Concerning maps that have fewer markers than supposed to: I took a good look at it, and it’s only showing markers for topics active in the last 20 days (or something like that), and a maximum of 30 of them. Is it possible it’s a configuration issue on our forum? It seems very specific! But we did not change anything in those settings. I have a maximum of 1700 location map max topics and I don’t think there is any setting related to time that would lead to only show markers from topics active in the last 20 days?

1 Like

After upgrading I opened the global map and there were no markers (topic) displayed. If I edit the location for a topic with a marker and just save with no changes the marker appears. All my markers are over 20 days old so maybe this is the same issue that @vincefrommtl is seeing?

Edit: The Show Map button for each topic still shows the correct marker location when that marker doesn’t display on the global map.

1 Like

Thanks guys, I’ll take another look.

2 Likes

This is not a full fix but should I believe, restore the old topic locations whilst avoiding the map error when loading directly from an external link or a browser refresh:

Known issue: I haven’t solved the direct Map => Category Map transition (but this should be an edge case), but everything else should be better.

1 Like

I’ll test tomorrow but a user has just pointed out that US locations are now being named as City, Country, State, e.g. Atlanta, US, Georgia

Quick test: I can confirm that I can see every markers on the map with this new update. Thank you very much. :slight_smile:

For the moment I will advise my users not to jump from one Category Map to another, to bypass the broken transition.

1 Like

The only recent changes are related to the map population.

The country/state order isn’t the very latest version. I mentioned it because I don’t remember seeing that in before the versions of the last couple of days.

1 Like

@packman for now I’ve fixed your earlier issue:

and this is now covered by tests.

thanks again to @david for getting me out of the bunker on that one.

2 Likes

@merefield Hey just a heads up, the modify_user_params method has been deprecated for sometime now, and will be removed soon now that Discourse is on version 3.2.0.beta1-dev

discourse-locations/lib/users_map.rb
35:  def modify_user_params(attrs)

Could you work on updating it to use the users_controller_update_user_params modifier when you get a chance? Thanks!

1 Like

sure, thanks for the additional heads up, I’ll look at it this week.

1 Like

Blake, this is done, mind if I add you as reviewer?

2 Likes

Awesome, thank you!

2 Likes

Thanks, merged!

1 Like

Sorry to bring bad news, but I have a bug report.

We’re currently running latest, we updated this morning: 3.2.0.beta1-dev (7ca5ee6cd2)

Running in to a strange issue, which wasn’t present two weeks ago when we last updated, whereby we can no longer edit a user profile if they have custom fields.

I wish to edit this user: https://example.com/u/username/preferences/profile

Page loads fine:

As soon as I click on Save, I get an error:

This came to light because one of our other web sites updates the “membership” custom field when our club members upgrade, and it the Discourse API endpoint was throwing a 500 error.

This is evident when I try to repro using Postman too:

The discourse logs show:

and:

plugins/discourse-locations/plugin.rb:188:in `block (2 levels) in activate!'

lib/discourse_plugin_registry.rb:293:in `apply_modifier'

app/controllers/users_controller.rb:2036:in `user_params'

app/controllers/users_controller.rb:198:in `update'

actionpack (7.0.7) lib/action_controller/metal/basic_implicit_render.rb:6:in `send_action'

actionpack (7.0.7) lib/abstract_controller/base.rb:215:in `process_action'

actionpack (7.0.7) lib/action_controller/metal/rendering.rb:165:in `process_action'

actionpack (7.0.7) lib/abstract_controller/callbacks.rb:234:in `block in process_action'

activesupport (7.0.7) lib/active_support/callbacks.rb:118:in `block in run_callbacks'

app/controllers/application_controller.rb:420:in `block in with_resolved_locale'

i18n (1.14.1) lib/i18n.rb:322:in `with_locale'

app/controllers/application_controller.rb:420:in `with_resolved_locale'

activesupport (7.0.7) lib/active_support/callbacks.rb:127:in `block in run_callbacks'

activesupport (7.0.7) lib/active_support/callbacks.rb:138:in `run_callbacks'

actionpack (7.0.7) lib/abstract_controller/callbacks.rb:233:in `process_action'

actionpack (7.0.7) lib/action_controller/metal/rescue.rb:23:in `process_action'

actionpack (7.0.7) lib/action_controller/metal/instrumentation.rb:67:in `block in process_action'

activesupport (7.0.7) lib/active_support/notifications.rb:206:in `block in instrument'

activesupport (7.0.7) lib/active_support/notifications/instrumenter.rb:24:in `instrument'

activesupport (7.0.7) lib/active_support/notifications.rb:206:in `instrument'

actionpack (7.0.7) lib/action_controller/metal/instrumentation.rb:66:in `process_action'

actionpack (7.0.7) lib/action_controller/metal/params_wrapper.rb:259:in `process_action'

activerecord (7.0.7) lib/active_record/railties/controller_runtime.rb:27:in `process_action'

actionpack (7.0.7) lib/abstract_controller/base.rb:151:in `process'

actionview (7.0.7) lib/action_view/rendering.rb:39:in `process'

actionpack (7.0.7) lib/action_controller/metal.rb:188:in `dispatch'

actionpack (7.0.7) lib/action_controller/metal.rb:251:in `dispatch'

actionpack (7.0.7) lib/action_dispatch/routing/route_set.rb:49:in `dispatch'

actionpack (7.0.7) lib/action_dispatch/routing/route_set.rb:32:in `serve'

actionpack (7.0.7) lib/action_dispatch/journey/router.rb:50:in `block in serve'

actionpack (7.0.7) lib/action_dispatch/journey/router.rb:32:in `each'

actionpack (7.0.7) lib/action_dispatch/journey/router.rb:32:in `serve'

actionpack (7.0.7) lib/action_dispatch/routing/route_set.rb:852:in `call'

lib/middleware/omniauth_bypass_middleware.rb:74:in `call'

rack (2.2.8) lib/rack/tempfile_reaper.rb:15:in `call'

rack (2.2.8) lib/rack/conditional_get.rb:40:in `call'

rack (2.2.8) lib/rack/head.rb:12:in `call'

actionpack (7.0.7) lib/action_dispatch/http/permissions_policy.rb:38:in `call'

lib/content_security_policy/middleware.rb:12:in `call'

lib/middleware/anonymous_cache.rb:389:in `call'

lib/middleware/gtm_script_nonce_injector.rb:10:in `call'

rack (2.2.8) lib/rack/session/abstract/id.rb:266:in `context'

rack (2.2.8) lib/rack/session/abstract/id.rb:260:in `call'

actionpack (7.0.7) lib/action_dispatch/middleware/cookies.rb:704:in `call'

actionpack (7.0.7) lib/action_dispatch/middleware/callbacks.rb:27:in `block in call'

activesupport (7.0.7) lib/active_support/callbacks.rb:99:in `run_callbacks'

actionpack (7.0.7) lib/action_dispatch/middleware/callbacks.rb:26:in `call'

actionpack (7.0.7) lib/action_dispatch/middleware/debug_exceptions.rb:28:in `call'

actionpack (7.0.7) lib/action_dispatch/middleware/show_exceptions.rb:29:in `call'

logster (2.12.2) lib/logster/middleware/reporter.rb:43:in `call'

railties (7.0.7) lib/rails/rack/logger.rb:40:in `call_app'

railties (7.0.7) lib/rails/rack/logger.rb:27:in `call'

config/initializers/100-quiet_logger.rb:20:in `call'

config/initializers/100-silence_logger.rb:29:in `call'

actionpack (7.0.7) lib/action_dispatch/middleware/remote_ip.rb:93:in `call'

actionpack (7.0.7) lib/action_dispatch/middleware/request_id.rb:26:in `call'

lib/middleware/enforce_hostname.rb:24:in `call'

rack (2.2.8) lib/rack/method_override.rb:24:in `call'

actionpack (7.0.7) lib/action_dispatch/middleware/executor.rb:14:in `call'

rack (2.2.8) lib/rack/sendfile.rb:110:in `call'

actionpack (7.0.7) lib/action_dispatch/middleware/host_authorization.rb:131:in `call'

message_bus (4.3.7) lib/message_bus/rack/middleware.rb:60:in `call'

lib/middleware/request_tracker.rb:233:in `call'

railties (7.0.7) lib/rails/engine.rb:530:in `call'

railties (7.0.7) lib/rails/railtie.rb:226:in `public_send'

railties (7.0.7) lib/rails/railtie.rb:226:in `method_missing'

rack (2.2.8) lib/rack/urlmap.rb:74:in `block in call'

rack (2.2.8) lib/rack/urlmap.rb:58:in `each'

rack (2.2.8) lib/rack/urlmap.rb:58:in `call'

unicorn (6.1.0) lib/unicorn/http_server.rb:634:in `process_client'

unicorn (6.1.0) lib/unicorn/http_server.rb:739:in `worker_loop'

unicorn (6.1.0) lib/unicorn/http_server.rb:547:in `spawn_missing_workers'

unicorn (6.1.0) lib/unicorn/http_server.rb:143:in `start'

unicorn (6.1.0) bin/unicorn:128:in `<top (required)>'

vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `load'

vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `<main>'

Strangely, I can edit my OWN profile and update the custom user fields just fine.

But I can no longer edit any other user, and neither can system perform the updates through our API either.

If I disable the Locations plugin, everything works fine again:

3 Likes

@Richie thanks for your report.

I can reproduce this.

It only seems to happen when someone does not have a location.

This code was recently refactored due to a deprecation in core and I’ve missed (a pretty big) case.
I’ll patch it soon.

5 Likes

Ah, so maybe me editing my own profile successfully was a red herring, as I do have a location on mine :slight_smile:

No worries, thanks for the continued support :slight_smile:

I believe that should be fixed now:

6 Likes

Update this morning, no more HTTP/500 errors.

Thanks for the speedy fix Robert :smiley: :clap:

3 Likes