Line Breaks in Hints Have Vanished

[+bon scott]

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

[Moun10Bike]

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

[+bon scott]

Thanks for the tip. Not as simple as a carriage return but it works!

[+baer2006]

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 .

[+baer2006]

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

[+KRON family]

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

[Moun10Bike]

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.

[+NanCycle]

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

[+koebilee]

The same problem also exists with the waypoints and not only with the hints

[+Beardman75]

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

[+Viajero Perdido]

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.

[+Harley&Friends]

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.

 

[+JPAgeo]

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

[Keystone]

I merged JPAgeo's post into this existing thread about the same subject.

[+Etherlord Clan]

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?

[+SvenGlyxpilz]

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?

[+BasicPoke]

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>.

[+Geoboater]

  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?

[+Viajero Perdido]

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, 2024 by Viajero Perdido

[+niraD]

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.

[+Etherlord Clan]

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, 2024 by Etherlord Clan
clarification

[+Geoboater]

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

 

 

[+Etherlord Clan]

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!
 

[giacaches]

We've reported the issue, and the team will look into it. 

[+ChriBli]

I'm perplexed to see that this is still not fixed, and struggling to understand what software development methodology could allow things like this to persist for two years. When will the team look into it?

 

The way it "works" now, according to my limited testing on hint text only, is that if I format the hint using only carriage return (like one used to do it) then it displays properly both in the official app and in c:geo on Android, but there are no line breaks in Chrome on Android, Brave on Windows or Firefox on Windows. If I add a [br] in the hint text, that is properly converted to a line break in all the browsers and in c:geo, but it is printed as "[br]" in the official app. There is no way to make the hint appear as it should in all these cases, and there may be other cases as well.

 

The only reasonable way to fix this is to make hints formatted as before two years ago, that is using line breaks only, display properly on all platforms. This must be possible, because it was before and it is not the browsers that have changed. But not only that, you now have to handle a lot of [br] that have been inserted as a workaround, sometimes in combination with carriage return, sometimes not. Such a [br] must of course not be printed, and must be converted to a line break only if it is not next to a carriage return.

[+thebruce0]

Consistency and communication between development teams is paramount.