maybe default could be optionally set as collapsed or expanded. ‘show map’ button could remain as it is while map is collapsed, and button renamed to ‘hide map’ while map is expanded?
how much participation is required to post a feature request?
The map location was also raised as a bug because in some instances, parts of the map were being rendered off-screen.
So, I’ve actually gone ahead and broadened the map on both mobile and desktop and made sure it keeps within the bounds of the screen. It still floats. Anything more would need to be funded.
This is slightly fiddly work as I’ve had to move elements around and be careful not to upset any of the numerous map views nor the existing map controls.
I will release it soon, but you can test it here:
git clone https://github.com/paviliondev/discourse-locations -b bigger_topic_map
Let me know if you see any issues.
OK I’ve gone ahead and merged that to expedite feedback. Please let me know of any issues.
it’s a start, thanks. i’ll be giving it a try and will let you know how it goes…
Hi Robert,
Thank you for the update. I really like the bigger map
Little fix for mobile view (topic and user card):
COMMON CSS
.location-details .location-label-container {
align-items: baseline;
}
.map-container.small {
margin-top: 5px;
}
MOBILE CSS
.location-and-website.map-location-enabled .user-location-widget .map-wrapper {
position: inherit;
}
.location-and-website.map-location-enabled .user-location-widget .map-container.small {
top: auto;
width: 100%;
margin-top: 5px;
}
Little bug on topic map, when i release dragging on desktop the map close immediately.
Yeah I deliberately left user card map behaviour as before as was out of scope of reported bug. I don’t intend to change that at present.
I noticed the over sensitive map behaviour on touch. I’ll see what I can do when I get chance. It relates to out of bounds click to close I suspect.
@angus @merefield is there a parameter available that I can use to specify the map pin title/legend when adding a location via the Discourse API?
For example, when adding a new topic to our Discourse I currently post this to our forum API in order to add a Location to the topic:
This results in the map pin title/legend being identical to the topic title:
Which in our use case, is often long.
I was wondering if there was pin_legend_title element or something that I could use to pass a different title to the pin, from the discourse topic title? (as I wish to pass a shorter pin/legend title)
Something like this:
Anyone else know if this is possible?
How to default the map to be shown without first clicking?
For the users map, look for location users map default
in the Plugin settings and check Default to users map when navigating to 'Users'
.
This is better than before!
Do you think it would be possible, in the future, to include this widened map when we click a user’s location too?
An upgrade to latest Discourse (2.6.0.beta5, 886d619d3f) with the Locations plugin active resulted in a blank site. It worked in safe mode when unofficial plugins were disabled. Commenting out the Locations plugin in the yaml file and rebuilding fixed the issue.
from_version: be5efc9410, f178532, 1460764, be5efc9410
repository: /var/www/discourse, /var/www/discourse/plugins/discourse-data-explorer, /var/www/discourse/plugins/discourse-locations, /var/www/discourse/plugins/styleguide
It’s due to a deprecation in core. I just pushed a fix
https://github.com/paviliondev/discourse-locations/commit/6dc4b1f4ae4892658a470c503bcf70f97027e466
Would appreciate feedback.
Thanks for the quick fix, Robert. After a rebuild all is back to normal and working as expected.
There is a delay of about 3 seconds in map display at /u/user-map?period=location
. During this time “No results were found” is shown. Is it possible to change this to say “Loading map…” instead?
I don’t have data to support it, but I think many users will not stick around and wait for the map to load since there is no indication it’s coming.
When page is first loaded:
After about 3 seconds:
Unfortunately the current architecture is at its limit. I recently deployed a fix which doubled this performance (goodness knows how you got on before?). Looks like you have an extremely demanding use case (quite an impressive number of locations!). I’m not sure we have a solution atm.
It was faster before - can’t remember when it got slower, but performance is fine as-is; that’s not the complaint. Setting the expectation that the map is about to be displayed would be a good fix for this.
Got it, yes that’s more doable. Can you please raise the request here?
I can’t promise that it will get looked at imminently (am crazy busy at moment and have imminent house move to contend with) but this would address the demanding use cases to some extent, thanks for the suggestion.