The A-Team

More than likely. The OP mentioned that this is a powertrail, or more accurately probably a geo-art where the final coordinates for each cache are hidden in the description. The CO has probably incorrectly used the "masculine ordinal indicator" character (º) rather than the proper "degree" character (°). The latter is accepted by the corrected coordinates feature, but the former isn't and gives you an error, so copying-and-pasting the coordinates containing the wrong character won't work. The CO of the powertrail would need to update all of their descriptions to use the proper character. As a workaround until they do, finders could copy-and-paste, but then remove the ordinal character (º) before submitting the corrected coordinates.

If you run into this again, can you post a link to the cache so others can try it out? That would help determine whether it's a larger issue affecting many members or one that may be user-specific.

This is a bug. The tagging function should only be offering your friends as suggestions, which should quickly all be eliminated as options as you keep typing (this is probably what's happening on your phone). For you, it seems to be looking up any user in the database rather than just limiting to your friends. I would think this would all be handled on the server side, but maybe Windows 7 is having some effect on the behaviour. Do you have access to a computer running Windows 10 to see what happens there?

I just did some testing with some usernames in my area. When I tried it with a username that contains all uppercase letters (as well as a hyphen), I got the same result as you: caches that should have been filtered out were displayed on the map. When I tried the same thing with a username that contains only lowercase letters and numerical digits, the caches they found were filtered out as expected. I then did a series of tests for various combinations of different character classes (uppercase, lowercase, digits, punctuation, spaces). The only class of characters that causes this issue is uppercase letters. You could have the name "tester123 456-7", and it will work as expected. However, the inclusion of even a single uppercase letter then breaks it. Earlier posts pointed out that uppercase letters are automatically changed to lowercase in the URL, so it could be that the search engine is doing a case-sensitive search when looking up the lowercase-ified username in the database and not finding a match. If this is what's happening, it could be resolved by either not changing the case in the URL, or changing the underlying search engine to do case-insensitive lookups in the database. This is also very easy to reproduce. Look up a cache that a user has found. Filter for "Not found by" that user, map the results, and see if that cache is filtered out of the map. That cache shouldn't be displayed, but it will be if the username contains an uppercase letter.

Yes, I noticed that option and was able to use that to download some GeoTour caches, so there is a workaround for some members. Thanks for looking into it.

If I go to a GeoTour page and download the GPX file, I get an empty, 0 byte file. I tried a few GeoTours, and I get the same result on each of them. I tried in Firefox and Chrome and got the same result in both, so I suspect this is likely an issue on the server side.

This is already how it works. Despite the new draft page not showing that feature, it's still doing it in the background. I haven't cleared my geocache_visits.txt file in years, but I only get the new drafts when I upload it. You're saying that each time you upload, you're getting all of the old drafts again rather than just the new ones since the last upload?

I didn't think you could add or remove locations once an Adventure had been completed by someone. Has this changed?

Yep, I just tried to view some profiles and I get a 404 error. It looks like the entire geocaching.com/profile directory is missing or otherwise broken.

That depends on when "in the beginning" was. When I ran into a glitch in the app on February 1, 2020, I then went to the website to delete my logs and see if I could complete the Adventure again. The website happily allowed me to click on the "Delete" icon and wiped the logs from existence. They disappeared completely from the website and there wasn't any option to undelete them. It turns out that the logs didn't get deleted from the database that feeds the app, so the app continues to think I've completed stages 1, 3, 4 and 5 of a sequential Adventure. There remains no option for me to restore the original finds on the website, though. I'm guessing that was added at a later date.

That's good to know. I guess improvements have been made to the deletion process since my issue. The one Adventure is still in an unplayable state for me, but at least I don't need to worry about similar issues with future Adventures. Thanks!

You can? I haven't been hanging around the forums for a while, so I may have missed something, but I haven't seen anywhere where you can hide lab finds. You can definitely delete lab finds, but as of earlier this year the lab deletion code hadn't been completed, so deleting didn't do all the things it needed to on the server side and was irreversible (ie. you couldn't just go and log it again). I still have an Adventure in a state where I'm unable to complete it due to this. Until it's confirmed otherwise, I would strongly recommend never deleting any lab finds unless you're absolutely positive you never want to log that Adventure ever again. Maybe I'll do some testing with a test account to see if deletion works better now.

I just tested and confirmed that this is now working as expected. Thanks!

I agree with TwigNZ that there's still something off in places. I didn't realize that there was an issue until just recently, when I completed an Adventure from approximately 4:30 to 4:40 pm PST on November 29. This corresponds to around 00:30 UTC on November 30. The five finds were correctly added to November 29 on the Geocaching.com stats calendar. However, the app, labs.geocaching.com, and the API show me as finding them on November 30. My guess is that Project-GC is now using the API, and that the API isn't passing the correct time zone offset along with the UTC timestamp.

I replied to a Message Center email on November 18th, and I only now realize that it isn't showing up in MC and the member didn't receive my reply. Has anyone noticed if this is an intermittent issue, or is it completely broken? If it's broken, some error log at HQ must be blowing up with all of the unhandled emails. Hopefully this can be dealt with soon so the number of missed communications can be minimized.

I just ran into this for the first time. When I click the "Send e-mail" button on a particular member's profile page (who has made their email address public), it only acts like a "mailto:" link rather than navigate to the usual messaging form. Hopefully this can be sorted out by Monday when the old page goes away. One other thing I just noticed is the title for the page. The title is always "Geocaching > Groundspeak - User Profile", with no indication of whose profile it is. I think it would be more useful to include the member's name in the title. If you have multiple profile pages open in tabs, currently there's no way to tell them apart.

I ran into this about a week ago and figured it was just a temporary glitch. However, I just went to log some more caches from field notes and had it happen again. HQ, can you please acknowledge that you're aware of this issue and are working on it? This bug will lead to quite a few mis-logged caches.

When viewing a GeoTour page (e.g. https://www.geocaching.com/play/geotours/cache-the-coast-central), the icons for FPs, difficulty, terrain, and size aren't showing up on each cache. This leaves some unlabelled numbers that are hard to decipher. I'm seeing this in both Firefox and Chrome, so I don't think it's a browser issue.

What actually changed here? Don't get me wrong. I'm all for changes that attempt to fix issues, and this is something that was definitely an issue. But in what ways will this change resolve the issue? The issue was always that some cache owners clicked the edit pencil and then didn't read what was written in the modal. In order for them to learn that this isn't what they should be doing, they were being expected to voluntarily read the content of the modal. They weren't doing this, and thus the issue resulted. With this new version of the modal, while the content has changed, the expectation on the user remains the same. If the user is clicking the edit pencil because they want to update the coordinates for everyone, they're presented with a bunch of text and a box that fulfills their need (see: confirmation bias). Sure, the new text may catch the eye of some users, but the same underlying deficiency in the modal remains. If the user chooses not to read this new text (remember, they weren't reading the old text either), then they'll just make the same mistake as they would have before. A little over a month ago, I posted here in the forums suggesting a fix that would force the user to make a conscious choice between two provided options before they'd be able to change any coordinates, thus eliminating the potential for the user to skip reading things and run into the issue. My suggestion appears to have been well-received by my fellow members, but I guess HQ didn't have the same opinion. Hopefully I'll be proven wrong and this change will ultimately solve all of the confusion, but I don't think that will be the case. My bet is that this is just kicking the can down the road.

Your profile shows that you own 10 "Lab Caches". This means that you've already used two credits to create two 5-location Adventures. Therefore, you have no remaining credits for creating additional Adventures. Unless you mean that you were recently awarded a third credit and that isn't showing up? If that's the case, you'd have to contact HQ for support.

Sorry, I guess I should have been more specific. The icons that suffer from the issue are the ones on the initial map displaying all of the Adventures in the area (the "Explore" tab). They have a pin-like shape: round but with a tapered point at the bottom. Users would expect that point to be the location being indicated. As HHL showed, the round icons for the individual locations within an Adventure don't have the same issue, because they're designed such that the center of the icon points to the location.

One thing that bugs me as a technical user is that the anchor point on the main map icons is in the wrong spot. The icon has a point on the bottom similar to the stereotypical Google Maps icon, and a user would expect that this point is where the icon is pointing. However, the anchor seems to be set for the center of the icon. This means that as you zoom in and out, the point on the bottom of the icon points to wildly different places and never the actual location of the Adventure. Fixing this should be as easy as determining the pixel location of the point at the bottom of the icon and adjusting the code accordingly.

Yes, there's nothing we can do stop it. However, I like to think that feedback is truly appreciated, so those of us who see issues want to point them out. Browser add-ons are fine as a fall-back if HQ never changes something, but the primary course of action should be to get the website itself fixed or improved so add-ons aren't required.

I realize now that I've never really used the new public profile page and have never provided feedback. I guess I've left it to a bit late in the process, but here's what I see: I agree with others that there's unnecessary whitespace that can be removed, especially in the left side of the "profilepanel" div. Excessive whitespace has been a recurring issue with changes on the site over the last few years and minimizing unnecessary whitespace should be an integral step of each project. The navigation jumps to the wrong "div". Rather than jumping to "#profilepanel", it should jump farther down to "#profiletabs". If I'm switching to view other details of someone's profile, I don't need to be shown the overall details each time. There's an error with the formatting of the souvenirs. Judging by the large empty space on the right side, it looks like these are intended to be 4 across, but something is causing the 4th ones to be wrapped and we get only 3. There's probably just some CSS that needs to be tweaked to narrow each souvenir's footprint. In the Lists tab, there's no formatting to indicate the presence of hyperlinks. Both hyperlinked and non-hyperlinked text are the same colour (the almost-but-not-quite-black #4A4A4A). As a result, it isn't immediately clear that GC codes in the Favorites list - nor the name, owner, or view under Bookmark Lists - are links that can be clicked. In the Lists tab, the presence of the "by [Owner name]" on every Bookmark List is unnecessary and extends the height of the page for no gain. The only lists that are being shown are those of the member whose profile page is being viewed, so this information is redundant. With all of the fresh feedback that's being provided, I'm hoping that the renewed focus on these new pages means that the projects will be resumed and they will finally be finished. To be honest, compared to some of the other changes that I've blasted in the past, the new public profile page actually isn't bad. Most of the issues I detailed above (and those mentioned by others) are relatively minor and wouldn't take much effort to deal with, so the new page should be able to be tweaked to be in a good state before the end of November.

I can confirm that all of the above links now work as expected. Thanks!