+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 2 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 Share Posted January 5 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 Share Posted January 5 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 Share Posted January 17 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 Share Posted January 21 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 Share Posted January 21 I merged JPAgeo's post into this existing thread about the same subject. Quote Link to comment
+Etherlord Clan Posted February 2 Share Posted February 2 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 Share Posted May 23 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
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.