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.
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.
For the moment I will advise my users not to jump from one Category Map to another, to bypass the broken transition.
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.
@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.
@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
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!
sure, thanks for the additional heads up, I’ll look at it this week.
Blake, this is done, mind if I add you as reviewer?
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 (
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:
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:
plugins/discourse-locations/plugin.rb:188:in `block (2 levels) in activate!'
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'
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'
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'
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'
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'
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'
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)>'
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:
@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.
Ah, so maybe me editing my own profile successfully was a red herring, as I do have a location on mine
I’ll patch it soon
No worries, thanks for the continued support
I believe that should be fixed now:
Update this morning, no more HTTP/500 errors.
Thanks for the speedy fix Robert
I’m just retesting a previously reported problem that it was thought had been fixed. Apologies for going back a month…little things like getting married, dog-sitting for a few weeks and an overseas visitor have kept me busy!
Set location topic default to User
Set a location for your user (if you don’t already have one)
Add a topic in a location enabled category. The topic gets your location and appears on the topic map with any other relevant markers.
Delete your user location
Add a topic to the same category as in (3). The topic doesn’t get your location (as you’d expect), but when you display the topic map all markers are missing.
Set location topic default to None - all markers reappeared on the topic map…initially. However, when viewing the user map there were no markers and after going back to the topic map all those markers have now disappeared again. I’ve tried deleting the two posts from (3) and (5), setting Location Topic Default back to User and adding a location back to my user but none of those make any markers reappear on any of the maps.
Has anyone implemented a view where you see the map on top and the list items underneath?
My client want this, but I’m advising against it. It seems to me like it would be cake on cake both ux and codewise since they both perform the same functions.
Opinions or tips on this?
the map on top
Are you referring to the Locations Plugin?
Apologies, yep I am. Looks like
this at present on my site.
In an ideal world selecting tags on top would limit both the map and a list under the map to the selected tag.
Perhaps one could:
Check if we are on the ‘Project and Gemenskaper’ page (easy)
Inject a duplicate list under the map (no clue how)
Hide the duplicate category/tags bar (easy)
…question is if that would make the tags work as expected (filtering both map and list on click and showing both) or if selecting one would make it default to only the list view - as it currently does when selecting a tag on the list.
Just spitballing. I don’t have a lot of hope.