+bon scott Posted December 23, 2022 Share Posted December 23, 2022 (edited) When I edit the hint on a cache page I frequently separate the sub-hints with a line break. I just noticed today that the line breaks are gone and all the sub-hints are run together. What happened, and is there a fix? I created the line breaks while editing and just used a simple carriage return to go to the next line. What used to look like: Decon 3rd tree from fence North side 6 feet off ground Now looks something like: Decon 3rd tree from fence North side 6 feet off ground Edited December 23, 2022 by bon scott 2 2 Quote Link to comment
Moun10Bike Posted December 23, 2022 Share Posted December 23, 2022 (edited) I'm not sure what you have been using, but you should be able to use markdown: in this case, [br] for a line break. Edited December 24, 2022 by Moun10Bike 2 1 3 Quote Link to comment
+bon scott Posted December 23, 2022 Author Share Posted December 23, 2022 Thanks for the tip. Not as simple as a carriage return but it works! 1 Quote Link to comment
+baer2006 Posted December 24, 2022 Share Posted December 24, 2022 This is a clearly regression in the code . I also use line breaks to structure my hints. They are all broken now, and in the editor it looks like this: "Stage 7: (hint) Final: (hint)". I.e., CR/LF encoded as HTML entities, which are apparently ignored by the code which renders the hint on the listing page. A [br] markup does indeed fix it, but this is _very_ non-intuitive (and probably not documented anywhere). I also wonder how long this "fix" will last? Sooner or later, the [br] will show up verbatim in the hint on the listing page . 3 1 2 Quote Link to comment
+baer2006 Posted December 24, 2022 Share Posted December 24, 2022 (edited) 15 minutes ago, baer2006 said: This is a clearly regression in the code . It's even worse than just broken line breaks! My hint for GC4ZRTB uses quotation marks. What happens is this ... I type in "b" in the hint field I click "Save" => The hint is then correctly rendered as "b" in the listing, but the text in the edit field is changed to "b" I click "Save" again (because I fixed a typo or whatever) => The text in the edit field changes to "b" , and the hint in the listing is now rendered as "b" I'm not really amused about this. Handling HTML entities correctly and consistently in back-end and front-end is Web Programming 101, and having a bug like that a) programmed in the first place and b) deployed to the production code is rather embarrassing. Edited December 24, 2022 by baer2006 Typo 4 1 2 Quote Link to comment
+KRON family Posted December 24, 2022 Share Posted December 24, 2022 (edited) 3 hours ago, baer2006 said: A [br] markup does indeed fix it, but this is _very_ non-intuitive (and probably not documented anywhere). I also wonder how long this "fix" will last? Sooner or later, the [br] will show up verbatim in the hint on the listing page . These markups have been available for many years and in the past could also be used to format logs or cache descriptions. Support in logs ended after announcement, support in cache description ended without announcement (and cache description then turned into one line without any formatting; it was not a nice job to fix it). So - no one can guarantee how long this "fix" will last, but so far it's still working in hints. If you want documentation, here it is: [b]text[/b] - text will be displayed in bold [i]text[/i] - text will be displayed in italics [b][i]text[/i][/b] - text will be displayed in bold italics (this is to show that markups can be combined with each other) [s]text[/s] - the text will be shown strikethrough [u]text[/u] - text will be displayed underlined [red]text[/red] - the text will be displayed in red (other colour names can be used too: green, blue, black, purple, pink, orange, yellow, white, brown, gold, maroon, navy and others) [code]text[/code] - the text will be displayed in "computer type" [size=3]text[/size] - the text will be displayed in a different size (numbers 1-6 can be used, two is the standard size) [font=Times New Roman]text - the text will be displayed in a different font (Arial, Arial Black, Book Antiqua, Comic Sans MS, Courier New, Impact, Tahoma, Verdana and others can also be used); there is no closing markup [/font], to end writing with the given font you must use [font=another font] [url=http://mapy.cz]Map portal[/url] - view as link - Map portal [center]text[/center] - text will be centered (right justified in the case of [right]) [br] - wraps the text on a new line at the given point [*] - wraps the text on a new line at the given place with a bullet at the beginning (if [list=1] is not used) [quote]text[/quote] - the text will be displayed as a quote (between the two lines below the quote) [list=1][*]text1[*]text2[/list] - the text will be displayed as a numbered list [:)] [:D] [8D] [:I] [:P] [}:)] [:O] [;)] [:o)] [B)] [8] [:(] [8)] [:(!] [xx(] [|)] [:X] [^] [V] [?] turns into these images: [text] - any other text in square brackets will not be encrypted, but directly displayed (without clicking on Decrypt) There is also an [img] markup, but its use is somewhat complicated. It must be in another bracket, the link must not contain http (or it is automatically recognized as a link), and the link must be encrypted via ROT13. As a result, it still does not insert the image, but only links to it. Example: [[img]//vzt.trbpnpuvat.pbz/pnpur/ynetr/2596qo28-8p1p-4s01-o507-ss5r863752o6.wct[/img]] will be displayed as [Image]. Warning - I recommend to not forget to close individual markups. Not closing a markup (for example missing [/b] or [/red]) will affect the display of all parts further below the listing, unless they have a CSS-styled appearance! 18 hours ago, bon scott said: I just noticed today that the line breaks are gone and all the sub-hints are run together. In my case, they are not only gone, but changed to . I agree that it's a bug and programmers should fix it. Edited December 24, 2022 by KRON family added image Quote Link to comment
Moun10Bike Posted December 24, 2022 Share Posted December 24, 2022 I already had a cacher reach out to me about this yesterday, and I have a suspicion about what happened. A couple of weeks ago we had to make a change to a third-party component involved in interpretation and cleansing of data on cache pages after penetration testers discovered a vulnerability. The engineers investigated and corrected a lot of issues that change created, but this may be a case that they missed. I have let the team know of this issue with hints, but given that it is Christmas Eve, it might be a while before the problem is investigated and addressed. 1 6 Quote Link to comment
+NanCycle Posted December 24, 2022 Share Posted December 24, 2022 6 hours ago, Moun10Bike said: I have let the team know of this issue with hints, but given that it is Christmas Eve, it might be a while before the problem is investigated and addressed. Bah Humbug 2 Quote Link to comment
+koebilee Posted December 29, 2022 Share Posted December 29, 2022 The same problem also exists with the waypoints and not only with the hints 1 Quote Link to comment
+Beardman75 Posted January 5, 2023 Share Posted January 5, 2023 Any update on this? I updated a couple of hints on my caches yesterday and found that the line breaks were stripped out and the quotes changed to html entities 1 1 Quote Link to comment
+Viajero Perdido Posted January 5, 2023 Share Posted January 5, 2023 57 minutes ago, Beardman75 said: quotes changed to html entities This also happens in the Description field for log images. It's broken, Jim. Same bug? Sometimes the Description field is important for telling a story. 2 Quote Link to comment
+Harley&Friends Posted January 17, 2023 Share Posted January 17, 2023 Any news on this problem? Is it going to be fixed? When? Many hints have changed (in a bad way) due to this change. The edit page of a cache is showing the hint correctly (with returns) so there is not much to fix for a cache owner. 1 Quote Link to comment
+JPAgeo Posted January 21, 2023 Share Posted January 21, 2023 Why don't work 'Enter' in Hints now? It's not good :-( Example (before): [cipher] second part, order [stage] under the tree, Samuel [final] a small stump two meters to the left [logbook] is there now: [cipher] second part, order [stage] under the tree, Samuel [final] a small stump two meters to the left [logbook] is there 1 Quote Link to comment
Keystone Posted January 21, 2023 Share Posted January 21, 2023 I merged JPAgeo's post into this existing thread about the same subject. Quote Link to comment
+Etherlord Clan Posted February 2, 2023 Share Posted February 2, 2023 On 12/25/2022 at 6:08 AM, Moun10Bike said: I already had a cacher reach out to me about this yesterday, and I have a suspicion about what happened. A couple of weeks ago we had to make a change to a third-party component involved in interpretation and cleansing of data on cache pages after penetration testers discovered a vulnerability. The engineers investigated and corrected a lot of issues that change created, but this may be a case that they missed. I have let the team know of this issue with hints, but given that it is Christmas Eve, it might be a while before the problem is investigated and addressed. Thanks for the info, @Moun10Bike. Do you know if the developers made any progress in resolving this over the last month? Quote Link to comment
+SvenGlyxpilz Posted May 23, 2023 Share Posted May 23, 2023 Is there still no update on this topic? I had the same problems while creating a new cache listing today. Fortunately I could use the (temporary?) workaround using [br], but how long will this work? 3 1 Quote Link to comment
+BasicPoke Posted March 7 Share Posted March 7 As of March 2024 a simple carriage return still does not work in hints, but [br] does work. Note that in a cache description, while editing, you can click the Source button then use html (hypertext markup language, developed for internet web pages), where a line break is <br>. 1 1 Quote Link to comment
+Geoboater Posted June 13 Share Posted June 13 While [br] works online, it doesn't display correctly on the Geocaching app or Cachly. A geocacher who found my cache GC9AYWG yesterday brought this to my attention by by sending me this message: "Sweet find I don’t know how br comes into play if you find time let me know". The hint in question reads this way in the app's: not magnetic [br] not a RX bottle. However, it reads correctly when viewed in the Geocaching site online, with "not magnetic" and "not a RX bottle" on two separate lines. Is there a fix that will work across all platforms? 2 Quote Link to comment
+Viajero Perdido Posted June 13 Share Posted June 13 (edited) Is [br] a secret known only to the 0.01% of cachers who read the forums, and in particular, this thread? Is it discoverable anywhere else? For that matter, "Markdown"? Does anyone truly understand the differences in formatting between logs, cache descriptions, hints, image titles, image descriptions, and for extra credit, forums? Does anybody know for certain whether *), is the correct sequence for all cases? (I dislike italicizing just one parenthesis, but apparently have to, and hope nobody notices.) Edited June 13 by Viajero Perdido Quote Link to comment
+niraD Posted June 13 Share Posted June 13 2 minutes ago, Viajero Perdido said: Is [br] a secret known only to the 0.01% of cachers who read the forums, and in particular, this thread? Is it discoverable anywhere else? For that matter, "Markdown"? Does anyone truly understand the differences in formatting between logs, cache descriptions, hints, and for extra credit, forums? Does anybody know for certain whether *), is the correct sequence for all cases? And how long will it be until the formatting system changes, leaving the existing formatting garbled yet again. Quote Link to comment
+Etherlord Clan Posted June 13 Share Posted June 13 (edited) 5 hours ago, Geoboater said: While [br] works online, it doesn't display correctly on the Geocaching app or Cachly. A geocacher who found my cache GC9AYWG yesterday brought this to my attention by by sending me this message: "Sweet find I don’t know how br comes into play if you find time let me know". The hint in question reads this way in the app's: not magnetic [br] not a RX bottle. However, it reads correctly when viewed in the Geocaching site online, with "not magnetic" and "not a RX bottle" on two separate lines. Is there a fix that will work across all platforms? @Geoboater This is what the hint on your cache looks like in the official GC app on my Android phone (split over three lines, with your line BReak code element on the second) Different apps render the code differently... also attached is what it looks like in c:geo on my 'droid (split over three lines, but without the BR) As to be expected, the website displays it over two lines given that the HTML of the webpage only has the one line BReak code. (why does the webpage have a HTML <BR> but the official app displays a Markdown [BR]?!?!?) abg zntargvp <br> abg n EK obggyr Edited June 13 by Etherlord Clan clarification Quote Link to comment
+Geoboater Posted June 22 Share Posted June 22 Is someone from Groundspeak going to respond? I still would like an answer on how to reliably display a two-line hint across all platforms. Having it display differently in the various geocadching apps is frustrating for me and confusing for most of the geocachers reading such hints in the field. Why is implementing standard HTML formatting not an option? For now, I'm going with: calling "221" .......... magnetic Although I wanted: calling "221" magnetic But was getting (in most apps): calling "221"[B]magnetic 2 Quote Link to comment
+Etherlord Clan Posted June 23 Share Posted June 23 Hi @Moun10Bike, Are any of your contacts at Groundspeak able to provide an update on this issue from 18+months ago? Please and Thank You! 2 Quote Link to comment
giacaches Posted June 24 Share Posted June 24 We've reported the issue, and the team will look into it. 1 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.