When we tried to deploy maps on staging, we got the following error
message in our Javascript console:
Error: Couldn't autodetect L.Icon.Default.imagePath, set it manually.
... so we did. The end.
Ugh, I know. But it's not any less secure than having it out there in
our Javascript, and it turns out Heroku just downright *refuses* to read
it from an environment variable during asset compilation. I even tried
an experimental Heroku addon
(https://devcenter.heroku.com/articles/labs-user-env-compile) but it
didn't work, so for now let's just do this and get it out there. I'm
sick of messing with it.
It seems that heroku generally denies us access to ENV['...'] during asset
compilation. They have reasonably good reasons for this, and yet I don't
know how else we're meant to get at our API keys (other than hardcoding
them into our config files, which we don't want to do).
So, to work around this, I'm recommending the use of the (experimental,
subject to removal/change, sigh) user-env-compile heroku addon. This
lets us use ENV during asset compilation.
For more info see
https://devcenter.heroku.com/articles/labs-user-env-compile
I'm not sure if this will do anything or not, but I can't figure out why
else the email address would have been getting inserted by ERB but the
cloudmade key wouldn't be.
Also removed distance/units from the places/show search, since you can
adjust nearness by zooming etc.
At this point the "members near here" stuff at the bottom of the page
exists mostly for accessibility and to give additional detail that we
don't currently show in the popups on the map.
So we're not using distance/units to search for members near here
anymore, but instead are just finding the 30 nearest members to the
specified location, and showing them in order of nearness.
We were getting annoying "couldn't close <p> with </script>" messages
when running tests, because escape_javascript was turning </p> into
<\/p>. We fixed this by gsub'ing \/ to / after calling
escape_javascript. What could possibly go wrong? :-)
