search

trailheadlabs / outerspatial-map-library

A Leaflet plugin built for use in OuterSpatial
https://www.trailheadlabs.com/labs/outerspatial-map-library/
Other
6 stars 1 forks source link

Basemap thumbnails link to localhost:9876 on embedded Builder Map on Mat-Su #166

Closed jasonferrier closed 6 years ago

jasonferrier commented 6 years ago

The basemap images on Mat-Su's site are attempting to load from localhost:9876.

Their map is embedded via iFrame to https://www.outerspatial.com/builder_maps/21/fullscreen, so this seems like a bug with map-library and not how the embedded the map.

mat-su_map-library_bug

jasonferrier commented 6 years ago

162 would fix this issue if we want to punt it. 🏈

nateirwin commented 6 years ago

Yeah, that would help with the Mapbox-driven basemaps, but wouldn't work for the others. Still not sure what's going on with this one... seems like it should be an easy fix in Map Library. We should try to resolve it before we push the next version, 7.1.17.

jasonferrier commented 6 years ago

We can probably just have some type of flag like on team-website for the [NAC config]:(https://github.com/trailheadlabs/team-website/blob/e4798de51b2c3023bdd8e4f95de2e8e08178241f/labs/projects/nac/assets/js/app-new.js#L4)

var mapLibraryPath = development ? 'http://localhost:9876/' : 'https://staging-cdn.outerspatial.com/libs/outerspatial-map-library/2018-07-31-18:13/';
jasonferrier commented 6 years ago

This is also affecting Manager in production. It can be seen in the map builder section.

jasonferrier commented 6 years ago

It looks like something to do with this line of code in switcher.js:96

img.src = window.L.Icon.Default.imagePath + '/control/switcher/' + imgFileName + '.png';
jasonferrier commented 6 years ago

It seems as though Map Library being loaded into Manager was version 7.1.11 (details in other issue comment) and when I updated the path to 7.1.16, the actual code loaded was 7.1.15. Nate and I are thinking that what may have happened was that the deploy script was run without running another build and the 7.1.15 code was pushed into the 7.1.16 S3 directory.

Idea to fix would be to rebuild and re-deploy the 7.1.16 release to 7.1.16.1 since we won't be able to redeploy/overwrite to the existing directory.

Nate is taking a look at fixing the build failure right now that seems to have been caused by 61d02e3a3502e48f2155b2e5d41c85a5175ea261