EngPhil

Yes, it's most unrealistic and unreasonable of us to expect them to listen to what their paying customers have been requesting for years. It'd distract them from all the other stuff that nobody has asked for...

THIS. Please, Groundspeak, Stop Doing This. By all means, allow Markdown -- but only if the author of the content has designated it as such. Otherwise -- it's plain text.

But using Markdown instead of BBcode prevents that kind of problem! Because "increase site security and promote cross-platform compatibility", you know. Looks like in the process of turfing out a mature, supported rendering engine, the Frog is inventing new vulnerabilities from scratch.

That's not how things work around here.

That's almost always the case with us over here in AU/NZ. Because only Seattle time matters.

Indeed, perhaps it'll lead people to look further afield and realise there are much better offerings out there.... certainly the geocaching.com website is a last resort for me nowadays, and I can't remember the last time I fired up a Groundspeak app....

It seems to be behaving itself up there for me. As well as the checkbox when logging a find. Don't think that's ever worked. My recollection is that the "Add to your favourites" checkbox only appears on initial log submission, not on an edit. (Which makes perfect sense to me.)

...there, I fixed the emphasis for you.

Correct. Even more so given that the CO is not even notified when a photo is added to a log. In my opinion, EXIF data (at the very least, location data) should always be stripped from log photos. Images in the cache description shouldn't be touched (EXIF data is a valid thing to use in a puzzle, after all) but for logs? I can't see it ever being necessary there. If there is a use case for it, the log can always be hosted elsewhere and referenced with a link.... [edited because words put I cannot order in the right]

I've hacked up that script and made it work again:- https://openuserjs.org/scripts/EngPhil/Geocaching.com_Correct_All_Cache_Coordinates If anyone knows who the original author was, please let me know, so I can credit it appropriately! (Disclaimer:- I'm no Javascript expert. I make no guarantees as to the validity of that code. I found it on the Internet and modified it to make it work. If it breaks, you get to keep all the pieces.) ETA: This post suggests the author was pailakka.

Very little. The limitation is actually an artificially imposed condition within the Javascript on the website itself; remove the logic there and it will just work. (There's a tampermonkey script floating around that did exactly this, unfortunately it seems to have been rendered ineffective by geocaching.com enforcing HTTPS for cache pages.) People have been asking for this for quite some time ...

Indeed it is. Again, the website should not attempt to render any logs last edited before 02-February as Markdown.

Doubly so, if it retrospectively does this on logs that were not previously rendered as such. Groundspeak: please stop treating pre-Markdown logs as Markdown. You know when a log was last edited; surely a simple check of that date before passing the log off to the Markdown parser wouldn't be too much to ask?

Are you suggesting barnold should go back and edit 1,869 logs to fix this? Because.... No. Groundspeak broke it, they should fix it.

Yes. I might have been a bit quick here, but GSAK will at least render HTML and BBCode correctly. * But will it render something like *this* correctly if found in a log from, say, last week?

Does GSAK know not to misparse plaintext logs from before today as Markdown? (It can't, with 100% accuracy, as the date on the log is not necessarily the date of the log, but it should be able to get pretty close.)

That's the only option that makes sense. The API must only return the raw text (as I believe is currently the case), and not try to interpret it. Returning rendered HTML defeats the whole purpose of, well, everything. That leaves the API client to render the log as they see fit. As indeed it should be. I'm hoping that all non-Groundspeak API clients just render the text as they always have: Pre-Markdown logs will display as originally intended Post-Markdown logs will benefit from the "graceful degradation" of Markdown into readable raw text The only place that existing logs will then render corruptly is www.geocaching.com (erroneously interpreting text as Markdown)

Honestly, I'm beginning to think that the way to ensure your logs look right is just to view them anywhere but geocaching.com. If S*W*A*G is stored as S*W*A*G in the database, and only broken upon display at geocaching.com, then the only place that is broken is the website. As long as GSAK, mobile apps, project-gc, etc. don't go out of their way to misinterpret innocuous characters, then they will continue to display logs as intended. This seems like yet another case of geocaching.com shooting themselves in the foot....

How would the website know you'd done that?

Yes. Actually, what would be better still would be a switch to switch on Markdown. Leave it off by default. If you're using character sequences that you want to show as Markdown, then you should tell it so -- the system should not assume that innocuous characters like _, *, -, etc have any special meanings on their own by default. Their non-Markdown usage is just too common.

^^^^THIS. Markdown has the unfortunate attribute that it is all too easy to accidentally introduce formatting by using perfectly un-format-like character sequences. That's not a feature, it's a bug.

Could you not just publish a series of traditionals, with the final "multi" simply listing each of the traditionals as a virtual (reference) waypoint? I'd think the existing guidelines should accommodate that. This is consistent with the way our local reviewers handle mystery finals in a series (with the reference waypoints, in that case, being hidden rather than visible.)

It's almost as if someone decided that the move from plain text to HTML wasn't quite awful enough already...... (I hadn't noticed this latest uglification, as after the HTML fiasco, I made sure all my notifications go through a filter that strips out all the HTML rubbish and formats them sensibly once again....)

Is there any reason why this couldn't be extended to all email addresses registered to the user?