Bl4ckH4wkGER

The cache details page you want to print is the same, regardless of whether you access it from the old dashboard or the newer dashboard. Hard to call it new when it's been around since 2017.

Both your operating system and your web browser versions are several years old. Your browser version for example was released on June 30, 2020. Your operating system is even older. A guess could be that the new logging flow release requires technology that's not offered or supported by these old versions. I'd recommend trying a different browser to start.

Congratulations Team ONE (Scott, Brandon, Alex, Joshua, Cory) on completing this project.. Huge thank you to Jessica for the design and all the other lackeys who provided feedback. I'm glad to see it out for people to use and enjoy. I'm excited to see what other work this reduction in tech debt and duplicate experiences will enable.

Works fine for slowly! & Booklady! Still not working for ohjoy! Seems it's just me for a single account so chances are this won't be fixed. Could be worse

I did some more testing and it appears that it's only an issue when the user you've never messaged before has special characters in their user name. If they messaged you before or there's an otherwise standing conversation, it works. To repro: Click into message center Compose a new message Type in "ohjoy!" Now click into the message field and try to start typing Result: After the first character your message disappears and you're automatically brought back to the user name input field Expect: You can type a message, regardless of what characters are in the users username. Similarly, if you click on the "message owner" link at the top of one of their caches, e.g. https://www.geocaching.com/geocache/GC6GF55_the-things-glaciers-leave-behind , the user name isn't pre-populated as it should.

https://forums.geocaching.com/GC/index.php?/topic/394149-cant-change-map-on-search-geocaches-map/

It does, so it's only for new chats.

Related to To repro: Log into website Open message center Start chat with a new user you've not talked to before (existing ones work fine) Type in user name - works Try to type in a message test Result It glitches you back to the user name input you can't send a message Expect: you can type in and send a message Related - the automated "Message the owner" at the top of the cache page also doesn't work. Device: Mac 13.4.1 (22F82) Latest Chrome

Same issue here even after reinstalling. To repro: Create a new chat in app message center Try and send a message Result Sending fails Expect Message sends Device: Pixel 7a App 9.36

You're based out of Germany which requires that annual subscription be automatically switched to monthly at the end of the first year. This is per EU regulations since December 2021 and has nothing to do with this price increase. You should've received an email about that notifying you that'd happend and how to return to your annual membership.

It's not just about the publish log, the issue is more complex than that. You can read more on the issue in this thread that's currently #5 in this sub section. It was #4 before you posted. Would be great if somebody could merge this into the older thread

We did some more cookie wrangling that should also address this issue as it's similar to the one reported here: Please hard refresh the pages you were having issues with.

We did some more cookie wrangling. Please hard refresh the pages you were having issues with.

We did some more cookie wrangling. Please hard refresh the pages you were having issues with.

I don't have an explanation for this one. I see that you logged it on Jul/21/2022 20:45:12 and the date or time on the Event was never changed. It's also not a time zone issue, so getting to the bottom of this will require further time. As this seems to be a one-off so far, I'm don't have a timeline for when that would happen. If you find further examples and or other players chime in with similar issues, that may help bump this in priority. I do however have one for this one. This Event pre-dates us enforcing that Events could only be logged with the date that matches the Event date. The date on this Event was never changed either, so the date discrepancy must have slipped through the cracks when the Event was published.

This has been fixed.

This should now be resolved.

This should now be resolved.

After internal review, all our email servers properly deliver to comcast and we don't see any spikes in rejections. So I'd encourage you to pursue the two options I gave above.

Couple items you can do yourself to avoid this: Explicitly put geocaching on your email allow list / whitelist Contact the comcast postmaster https://spa.xfinity.com/postmaster to bring it to their attention I'll forward this to our IT department as well.

This should now be fixed

This should be fixed, thanks for bringing it to our attention.

Thanks for keeping us posted and glad it resolved itself. I can share that we didn't do anything on our end, yet. Overall, it may've just be a case of gremlins in the system

I actually wrote up a bug report for this on the 13th, believe it or not, while testing something else. So we've been aware, it's just not a drop everything to fix it type of bug. For any code change, there's a mix of manual and automated testing involved. Unit tests are written by developers to help guide their development and make sure that they build what is asked. Further manual tests by an QA engineer are used to validate the acceptance criteria of any particular ticket. As an example: is there a button now where there was no button before in space X. Automated tests are used to validate certain essential features of the website. As an example: can a player create an account, can they sign in, can they run a search that returns results, etc. All of this happens at multiple stages: - in a test environment - during deployment - in production once things are live Catching that a style change in area A had an unintended impact on a otherwise unrelated area B would require some degree of "turning over every stone" of the website every time you make any kind of change. That's not feasible for any company. Testing styles outside of the changed area or essential areas is generally uncommen. The focus of testing is generally to make sure that "a button is there and works". Visual mismatches 9 times out of 10 tend to be annoyances that are then prioritized as such.

It's not, it's a bug in the CSS styles for that page. Thanks for bringing it to our attention. It's been passed on to the appropriate parties.