Funky_Boris

I have an event description in which I maintain a list of confirmed registered attendees. When people cancel, I've been adding the HTML5 <del> tag in the description source code to signify that they no longer expect to attend. https://coord.info/GCA8H3J This has been working as a charm until fairly recently, where it appears that even though it is present in the source, it gets filtered before the HTML that the users see is rendered. The <del> tag is the official semantic tag in HTML5 for signifying that something has been deleted. It usually renders in browsers as text with strike-through. https://www.w3schools.com/tags/tag_del.asp Did you change the rules for which tags will get rendered recently ?

That was the exact reason I was going to edit the log in the first place...

I am trying to edit a log entry. https://www.geocaching.com/seek/log.aspx?lid=481823585 When I click the pencil icon, I get this page: https://www.geocaching.com/seek/log.aspx?lid=481823585&edit=true ... which is exactly the same as before, apart from the URI. Pressing the edit button a couple of more times yields the same result --- except that now the `true` value just becomes appended to the URI: https://www.geocaching.com/seek/log.aspx?lid=481823585&edit=true%2ctrue%2ctrue%2ctrue%2ctrue%2ctrue%2ctrue&edit=true Still no change to the page, still no editor. ---- EDIT (converted from reply): Additional info: It seems to work if I use the LUID instead of lid: https://www.geocaching.com/seek/log.aspx?LUID=a7f2b81d-0a12-4aa3-b20c-f884f1fb310b&edit=true Maybe just have the `lid=` variant of the page redirect to the `LUID=` variant ?

Fair 'nuff. I've done geocaching for over 16 years, so I've had my shot at getting this attribute back in 2010. Just wanted someone to clarify what is happening with this attribute. (Bearing in mind that @Isonzo Karst is probably not an authoritative source on this, lackeys are welcome to butt in here and let us know the official policy regarding this attribute )

Is the still the case? There are a lot of Community Celebration events taking place in conjunction with the (postponed) 20th anniversary of geocaching. Have none of them gained this attribute?

It has been almost 11 months and no reply. The problem is still present. Respectfully: bump.

Exactly what @mellers is describing. I, too, use the old Field notes page. DNF gets recognized with blue frowning face and all, but when the logging page is opened, it is converted into a found it . Like @mellers I am able to change the log type using the drop-down menu before logging but I have to be alert to what the correct value was in order for this to work. @Geocaching HQ: Please prioritize. This has worked for years and was by all accounts only broken recently.

I've recently gone over some of my remaining listings to see if they need maintenance from a listings-perspective. I came across this one: https://www.geocaching.com/geocache/GCNYYV_kulso-1 The immediate load of the page results in Firefox displaying a warning This warning is about mixed content which (depending on context) can be harmless or severe. It is a warning none the less. TL;DR: It is a page served with HTTPS that in turn contains reference to consistent elements by HTTP. I set out to see if I was able to clear this warning. If some of my user supplied content was referencing HTTP, it made sense that the warning was there. I edited the page to remove <img> references to content served by HTTP (and removed from <a> tags while I was at it). No change. I looked at the source of the web page. These are the HTTP-based references I could come up with: Now, most of them are links (<a> tags), which do not generate the warning. The one who does is: I have no option to edit this link at the cache page. When following it, I get a HTTP 301 (moved permanently): (I had to do something to the URL to prevent auto-expand, thus the "(slashslash)") If I try the same query with HTTPS instead of HTTP, I get exactly the same result. My questions then are: Why are you still referring to this image by HTTP? It would seem that HTTPS would yield the exact same result with the added bonus of clearing the warning Is there a reason to preserve the 301? You are using one level of indirection that can be avoided. This is the most pressing part of this request. As long as this remains the case, geocaching.com is actively contributing to user alarm fatigue: https://en.wikipedia.org/wiki/Alarm_fatigue I know that there are no security violations here, but that is not the point. The point is that inaction on this will lead to users being told once more to ignore a warning. Warnings like these should be either heeded or cleared and doing so is easy. Just add an "s" in the right place (or substitute "http://img.geocaching.com/cache/" with "https://s3.amazonaws.com/gs-geo-images/" if that is not somehow a problem). The rest of the references (that do not contribute to the warning being generated, but are there none the less) can then be subdivided into four categories: Identifiers that aren't necessarily meant to be followed by a user agent (like the xmlns ones). Never mind those. Links to social media pages (like Facebook or Twitter) Links to map services (like OpenStreetMaps or Bing) Links to other Groundspeak-owned sites (like Waymarking or shop.geocaching.com) It would seem that most (if not all) of these support HTTPS as an alternative to HTTP and some even do 301 or 302 to the same path with HTTPS instead if you try the raw HTTP links. Are there any reason to keep referring to the HTTP-based versions of these links on your site ?

I have come across a peculiar bug. When I click the "Message this owner" link on top of a cache description, I get redirected to the message center (which is what to expect) and a new conversation with that user us commenced with a prefix "Regarding <GCcode>: <Title> – ". When I then use it to send a message, I get a mail saying that I got a new message from myself: "Geocaching: Funky_Boris, you have a new message from Funky_Boris!" The message body then starts with "Funky_Boris has sent you a new message." followed by my message. Underneath there is more: "Visit the Message Centre to view and reply to this message. View Funky_Boris’s profile" I have not gotten any replies from any of the messages sent in this manner which prompts the question of whether the messages have even been delivered. When I open the message centre they seem attached to the correct conversation with the intended recipient. I certainly get a reminder that I have sent a message to myself. Perhaps someone from Geocaching HQ should see if they can reproduce the bug and fix it if that is the case?

It would seem that within the last hour that the reset point deadline has been extended by 7 days ? The countdown clock got 7 days added and the text on the friends league page now states that the reset is on April 15th. https://www.geocaching.com/play/friendleague EDIT: There are others that seem to have come to the same conclusion:

I don't seem to be able to send to users with ampersand in their name. Here are a couple of examples of profiles with ampersand in them: https://www.geocaching.com/profile/?guid=cde83765-b18e-45de-a7f1-29fb0275539b https://www.geocaching.com/profile/?guid=8567ee7c-9099-4c66-b0b6-c3e2afb56eaa When you click on "send message", a conversation with their name is not brought up. If I click on "new message" and type in their name, the "send" button is greyed out.

Losing all hope that Groundspeak would eventually make previously uploaded field notes display correct time again, I cleared them all out and uploaded anew. They seem to be all correct now. The workaround seems to be just that: Construct a txt file containing the field notes you want to have in your field notes after you are done Clear all field notes from geocaching.com Upload the file with the field notes you want to keep. This may be somewhat inconvenient but there you are. It seems to work. I used the following one-liner with a regular expression to extract the entries I needed (Sep. 28th and onwards): $ cat 20161122143001.txt | grep -E '2016-((09-(2[89]|3[01]))|1[012])' > 20161122143001_fixed.txt Applicability may be limited on non-UNIX-derived systems

That is 10 hours ahead of UTC (Zulu time), 9 hours ahead of UTC+1:00 (Europe/Copenhagen). My bad. Edit: It may even have been 8 hours since Daylight savings time was in effect in my local area at the time (2016-09-28) which would set the local clock at UTC+2:00 for a total time difference of 8 hours between actual local time and the time displayed at the field notes.

As of 2016-11-17T16:43:17+01:00 the problem is still not fixed. Any updates as to what happens with this issue ? EDIT: Not directed at Babsbaby but more a request in general

I would just like to confirm that I also see this bug. It has worked in the past, but now somehow it does not. I am a bit behind with my logs and I can confirm that the uploaded logs have been correct at some point, and that the bug also includes times that have previously been displayed correctly at the field notes page. From my perspective: Just revert to what worked. The field notes feature has been working correctly just a week ago, and now it doesn't. My data (incl. example to reproduce): Time zone (from preferences on geocaching.com): UTC+1:00 (Copenhagen) Time in uploaded field note file: "2016-09-28T20:03:39Z" (for https://coord.info/GC59HWW) Time currently displayed in field notes page on geocaching.com: 29 September 2016 06:03:39 That is 10 hours ahead of what it should be.

Thank you. I will vent my discontent there

I recently discovered that the Premium membership buying proces has changed. Now the first step in buying is to choose your location. I live in Denmark. A one year membership costs 29.99 euro. If I choose my location to be something outside the EU, the price is suddenly $29.99. Same number, different currency. Currently a euro is worth 1.38 dollars which means that residents in the EU pays 38% more than the rest of the world for their membership. What gives?

And my English is way better than my German as well, but I think we agree on the essence of that log in that he was tired of people posting pictures taken with their own cameras when the description of the cache clearly said no webcam picture, no find. I was (though not in the watchlist sense). I wanted to log them in the correct order to get the path of the trackables correct. Of course any indication of the slightest chance that I might lose the ability to log the cache would have made me log it straight away, since good logs and correct paths of trackables are far less important in comparison. The point is that I did not know this and despite having been a geocacher since 2004 have not ever heard of this. I fail to see how procrastination has anything to do with this other than dumb luck. Two of them did, yes. Yes, they acted timely, but neither them nor I had any idea that they acted timely, since neither of us knew that there was an urgency about it. There is another problem. Webcam caches are sadly one of the cache types in which failure to live up to the requirements are all too obvious, even from behind your screen. Most cache types today feature a physical container and has a physical log, the entries of which no reviewer, lackey or Groundspeak support employee can do a cross-reference check on. Cache owners can, but in my experience next to none do. It is very hard to read from an online log just saying "Found it. TFTC!" whether or not the cacher has actually even been near the site where the container is. Thus, there may be any number of "couch cachers" who go undetected for years. There is little or no control over what actually happens out there, and any suggestion that this should be scrutinized could easily be rejected solely on lack of feasibility. I am a cache owner myself and I tend to give people the benefit of the doubt. One of my caches is in a park in my town. It has been there on and off since 2005. I have lost count of how many times I have had to replace the container because someone stole it. They usually take the log book with them when they do. Since replacing log books is not an activity I undertake every week, all the physical log entries since the last log book replacement are thus lost which could be anything from a few months to a whole year. When this happens I don't go and start deleting all the interim online logs on the grounds that I no longer have the means to cross-reference to check that they were there physically -- which by the way provides no guarantees at all. If conspiring with other geocachers is an option you can just make a deal with your friends to have them sign the log books that they visit and stay home yourself watching TV or whatever. My point is this: Stop pretending that there is any 'security' whatsoever in the current system, because there isn't. Its a gentleman sport like golf - no one sees what does and does not happen out in the bushes but you come out of the bush and tell your buddies that this thing or the other happened and unless they have any reason to doubt the correctness of the claim, it is taken at face value. The paradox here is that my visit to this particular webcam and my conformity to all the requirements is way better documented than most 'traditional' logs. It would seem from the response I have gotten so far that meeting the stated requirements does not cut it in order to log this cache -- there was an invisible, undocumented, arbitrarily imposed deadline to log it online. I'm upset that the cache owner's underwear got in a twist. Certainly owning a containerless cache leaves one in position where people may be logging finds without completing the requirements for logging. If a cache owner doesn't want to be bothered policing logs because their webcam is offline much of the time, they can archive it. I don't understand the need for locking the page to prevent people who have legitimately found the cache and met the requirement from logging it. But this appears to be common policy, especially for containerless caches that get lots of "bogus" finds. It seems that "puritans" are worried that these archived caches invite bogus logs and have to stop the bogus logs at any cost including telling legitimate finders they can't log a find. Let's get rid of found it logs altogether - that way there won't be any bogus finds. People (on the forum in particular) seem to insist that I blame the bogus logger for my not being able to log a cache I legitimately found. This is a bit of stretch for someone who is known for saying that most bogus logs don't bother me. I don't care if someone else believes that when a webcam is down or a cache is missing they should get credit for trying. It's silly, but I can't think of a case where it made any difference as far as my enjoying a cache. Instead I'm more effected by puritan cache owners and Groundspeak lackeys who decide they have to lock the cache page. Fortunately, the smiley isn't all that important to me. If I see an archived virtual or perhaps even a webcam that looks interesting I may just go and find it. A locked page just means no one else gets to read about my experience. My point exactly. There is little or no actual 'security' in the traditional system, so why pretend? For a lack of a better explanation I am going to assume that it happens for the sake of convenience in the sense that bogus virtual and webcam cache logs are so much more obvious that someone are going to have to delete them, whereas in the traditional system they usually get the benefit of the doubt and everybody is happy. If the cache does not get locked, the archival does not have any consequences (so it does not provide a solution for an owner of such a cache who wants to put an end to it). The logs will come in nevertheless. There is no way to distinguish between those who found it legitimately and those who did not except that the cache owner takes care of that. Even a solution to lock only logs for a date after the archival would not help as people simply would date back their logs. What you say would mean that if someone once came up with a containerless cache that worked fine, he/she can never decide to put an end to it or would be willing to delete later logs manually for years to come. Cezanne No, what I am suggesting is not disallow locking of caches. On the contrary, I think the locking mechanism is a necessary tool for the reviewers and others to control f.x. locationless caches. What I am suggesting is transparency and a policy on locks so that it is transparent what happens and why as opposed to arbitrarily imposed requirements imposed on a whim. I don't see the harm in a one month warning. Local cache owners usually get one month to respond to reviewers if their cache is disabled for extended periods of time or has huge amounts of not-found logs. This deadline does also seem arbitrary but at least its transparent. It explains in advance: why this reviewer warning has been posted (usually extended periods of the cache being disabled or many not-founds) what happens if no response is sent or no action is taken before the deadline: reviewers are going to archive the cache. who is imposing this sanction (usually a reviewer) what to do to prevent the sanction (prevent the reviewer from archiving it): Check up on the cache and reenable it. No words minced, no one in doubt about what happens from here and what their options are. In the case of the locking mechanism Groundspeak has only gotten as far as to explain what -- namely that the cache now no longer accepts logs. All the other details are kept in the dark. I have yet to hear good arguments that the locking mechanism should not have the same level of transparency as the abovementioned practice of fair warning before archiving neglected caches the logging of webcam caches should be held to a disproportionally higher standard for evidence of compliance to cache log requirements

This is a webcam cache, so there is no paper log. There is, however, a couple of thousand webcam pictures collected by a bash script from that day, some of which depict me and my three geo-buddies standing in front of the aforementioned webcam, two of whom got around to logging it before it was locked. I am mentioned in one of their logs. If this was some kind of hoax, it is pretty elaborate in that I would have to have planned it two months ahead of time and to have conspired with other geocachers in order to fake logs and webcam pictures. The idea that I would have gone through all this trouble instead of just logging the cache back when it was still active is simply ludicrous.

I can appreciate that. Depriving Groundspeak of this mechanism would probably result in utter chaos on the website. I still don't see the harm in stating a policy and referencing it when caches become locked. If you always lock caches just to prevent abuse just write that. So there is a difference between legitimate finds why? What? So the current Groundspeak recommendation on logging caches is something along the lines of: "Log your cache immediately, because logging it may become impossible at any time, without warning, explanation or oversight, at the discretion of one or more anonymous agents of Groundspeak." ? I will try to bear that in mind the next time I plan to go to some remote location to find a cache of a rare type.

On September 1st, I and a couple of other geocachers attended a MEGA event i Germany (GC44477). We had crafted an ambitious plan for the way home - to find 10 different types of caches within the same day (this is an ambitious plan, when you live in Denmark, far from Groundspeak HQ, Project APE caches and so on). 16 hours and 400 miles later we arrived home, having achieved our goal. So far so good. Now, most of the caches found were German. I am schooled with the doctrine that you should write "good logs" that describe your experiences and describes any problem that might be with the cache. Since my German is not that good, I postponed the logging thinking that I'd get around to it some day and that I'd always be able to post a log on a cache that I actually found. Come start of November, I did get around to it. I started logging the caches found that day in order so that the journey of the carried trackables would be correctly described. When I came to the 9th log (GCP30H - a webcam cache) i got this message when trying to log the cache: I then took the following steps (in order) I wrote the cache owner for help. No reply yet. I started a thread on our local Danish geocachers' forum in the "reviewers' corner"-category. The reply roughly translates into: I wrote to Groundspeak support through their website. After a day or so, I got this reply: Now, here is my problem: Aside from the obvious objection to being asked to settle for 9 and not 10 caches logged online, I have a more general criticism of the handling of this case, in particular in relation to the (lack of) transparency in the matter. I have been a registered member of geocaching.com since 2004, and I have never before been unable to log a cache, that I found in real life -- archived or not. The philosophy has always seemed to be that except for the travel history for trackables (which in essence are shared resources) it has always been the case that you could subsequently make data on the website reflect what has actually happened in the real world, as indeed should be the case. Any restrictions in this regard (deadlines) from a data-dependency point-of-view would be unnecessary at best and in any case disruptive to cachers who in good faith are trying to make the website data (logs) reflect reality. Now there is the issue of locked caches. I understand from the little information that Google was able to scour from this forum that is is a mechanism that is applied to caches that either have been abused or are in danger of being abused, and that it is mostly the grandfathered cache types that become locked since they are relatively rare and dwindling in numbers to boot. I can get behind the sentiment of this decision. If locationless caches were still accepting logs, I doubt that they would only be logged by cachers who had legitimately found them prior to them being archived. This locking of caches, however, happens with very little transparency: There is no notice on the cache description as such that it is locked - only that it has been archived. There is no explanation available as to when the lock was applied - was the lock applied at the same time as the log entry that archived it? Before? After? There is no explanation on the cache description as to why the cache was locked - did it happen automatically, triggered by the archiving of a grandfathered type cache, or was it a conscious action of a reviewer or lackey? The answers I got from the people I contacted on my quest to log the cache that I found were all "unable to help" -- both in regard to the actual problem (logging the cache) but also with regard to providing any kind of insight into why. I find it hard to believe that reviewers and HQ supporters are actually unable to do anything in the matter. Whether or not they want to is another matter entirely. If there is a policy it should be documented. So, to sum it up, my plea is this: Formulate a policy regarding the locking of caches and reference it if you apply locking. Give a 'fair warning' on caches that are they are about to become locked if the locking is being done automatically to pre-empt abuse. For each cache locked, provide the following information: Why was it locked (pre-emptively/abuse/other)? When was it / will it be locked? Who locked it (bot/reviewer/lackey)? In this way it will be transparent what has happened and why. Oh, and of course I would be thrilled if someone at Groundspeak helped me solve the little problem of GCP30H. It would itself not solve the general problem of transparency but it would restore my confidence in Groundspeak to do the right thing despite criticism.