linsrille

Just noticed that the map is fixed! I was looking forward to the two month anniversary but I guess the champagne can be repurposed Sending my gratitude to the dev who finally got it fixed!

msrubble's solution does not work, as the browser history updates when panning, also reload does not help in some scenarios depending on what the URL says. In Firefox, if I go to the inspector and remove the CSS statement: min-height: 100%; then the map works again. I understand that it's not this easy to fix the map, as it probably breaks something else. But unlike me, your developers (hopefully) have the code that did work and can compare to the current broken code. Also lame move to remove my last post. If you take issue with what I express be upfront about it! It was to the best of my intent constructive albeit a bit harsh.

I can't believe this bug is still here two full weeks later. It's abyssmal how HQ handles updates and the associated bugs. * No testing before release? * No rollback * No bug tracker * Poor response, at least the no-pq-for-you bug and message center bug is resorted now (thanks for that I guess) For the time being project-gc.com has a map.

No worries

It's correct that I didn't set the wheelchair attribute, but I was under the impression that the wheelchair attribute only affect terrain rating? My question concerns difficulty rating. I have not tested with terrain 1.0 with and without wheelchair attribute. I'll have a look at that thread you linked now.

I have noticed that when I register a new cache and set difficulty to 1.0 it will be reset to 1.5 on the preview page. Same if I go back to the description page, when I return to the attributes page it will be reset to 1.5. I have checked with others and they have seen the same behavior. It's a minor annoyance as there is little difference between the two, but still. If there is a reason for this it should be stated in some way imho.

I've gotten this a few times in the past. Not frequent at all so it's not that annoying. When reloading page all is fine. Just wanted to mention it.

This has been resolved - players can now open drafts in a separate tab. Thank you! Thank you for listening and restoring the functionality!

Just noticed this too. I've become quite accustomed to this way of logging through the years. I feel it is quite a big usability regression. Also why?! * Use-case 1: Slow internet connection Load a few compose tabs in the background while writing the current log. * Use-case 2: Simple workflow 1. Ctrl-click compose link 2. Write log 3. Ctrl+w closes tab, the tab with the drafts list appears 4. Goto 1. * Use-case 3: Getting the story straight Sometimes when I've been out caching I've visited a cache here, a cache there and lost track of which was which. Then I write a few logs simultaneously, tabbing between them and their listing page. These use-cases are no longer possible

I just got this error. It works on my android phone on the official geocaching app. In my case it is just one conversation of many that is borked. On the phone I can see that the next message in the borked thread has a backtick (`) in it, and as a hobby coder I can imagine that it has to do with it. Also, is the entire Groundspeak HQ on vacation? I find their lack of involvement abysmal. If I wasn't hooked on the premium features I would've voted with my wallet..

I should add that I have my local timezone set in my prefs.

The wrong date is presented in logs for geocache listings on the site (including view/edit log, view logbook). Probably in other places too, like statistics for instance. * The details of your configuration (browser and version, application version, etc.) Any browser through the geocaching.com web site. * The specific steps you are taking that lead to the observed behavior 1. Log a find through a live-anabled app, like geocaching live or neon geo. 2a. Compare logging date in application to the date on the cache listing page. 2b. Wait for friends to remind you that you logged the wrong date. * Details of the observed behavior On the cache listing page the date is sometimes not the same as the date logged. By downloading a GPX file for the given cache it can be verified that the correct time and date is stored on the server. Take a look at this example (which I will leave as is for reference): http://www.geocaching.com/seek/cache_details.aspx?guid=7175d7d6-8363-48eb-a3f5-83eb9935d045 I logged this cache on the 10'th of june at 8:58 am local time (GMT+2, Stockholm DST) My found-log in the gpx file for that geocache correctly states "<Groundspeak:date>2012-06-10T06:58:43Z</Groundspeak:date>" while the cache listing page displays the 9'th of june. In this example http://www.geocaching.com/seek/cache_details.aspx?guid=217d782c-7ed4-447b-8763-13e3d8af1a53 logged 20 minutes later the date is correct, and the subsequent finds for this day is also correct, from which I find that there is a breaking point at 7:00 am GMT in the datestamp. Interestingly this is also the current time offset in Seattle from GMT with daylight savings time. * Details of the expected behavior, i.e. what you believe should be happening instead I expect the date on cache listing pages to correspond to the recorded log date. Logs from fieldnotes seem to be unaffected as the timestamp is lost somewhere in the web logging process, which in itself is a bug I suppose.