Jump to content

Log Change from HTML to Markdown


NinjaCacher!

Recommended Posts

Now it seems that {`*`FTF`*` followed by 125; whithout space lets it _look_ like {*FTF*} in the log, but nothing more.

 

That won't help because other programs look for 'real' {*FTF*}.

 

The question is where are external programs looking for the text.

 

Once the conversion of Markdown is in place, we will to able enter text into the logs, either with Markdown syntax, or try to make some attempt to escape the Markdown so that it renders FTF as a string or some variation like TFTFTF. When the log is submitted I would think that the text of the log, including the Markdown syntax will be stored as is into the GS database. If any it's transformed before persisting the log, what's going to happen when someone tries to edit their log? If I included a link to a trackable item in my log using the Markdown using something like this:

 

 

Dropped [Kansas Sunshine 2008 Geocoin](http://coord.info/TB28FY2) into the cache.

 

If the markdown is converted before it's stored, when it's read back to the "Edit your log" form it will be an HTML link. Since GPS devices won't understand Markdown syntax (but can understand HTML) when a GPX file is created, or a request of logs on a cache through the API, or when rendering a long on a cache page, the conversion would need to happen when after it *reads* the text from the database. So an external program needs to look at how the string would appear after the Markdown processor has executed.

 

 

 

 

Link to comment

Yeah in an earlier comment I speculated about how the text would be stored and displayed. Reportedly the intent is to provide human-readable plaintext which includes formattable syntax that renderers can use if they have the capability, and if not, the text will be readable just as is (otherwise where ever would it be displayed as plaintext?). I'd be surprised if they render the Markdown syntax before storing the log text in the database. That would completely defeat the purpose...

 

So if they store the plaintext in the db, then any API retrieval would, at the very least, receive the plaintext/raw version with which they can do as they please for how they wish to display log text. If I were GS I'd also provide an option to retrieve formatted log text, wherein the Markdown formatting is first rendered then sent to the app, perhaps as HTML, or richtext, etc, so it's not required to implement a Markdown rendering algorithm.

 

IF that's the case, then it may be that apps retrieving log text via the API may be able to retrieve raw log text if they wish, if they really don't like the Markdown formatting that GS provides; it means loss of formatted text display (at least per GS's Markdown implementation) in support of community they wish to appease who hate the possibility of 'garbled' logs :P

 

...in short, I think GS's worst option would be forcefully always providing formatted log text via the API, for multiple reasons. Including the fact that 3rd party apps won't be able to sense 'standard' tags like {FTF} or what have you. Provide a raw log text retrieval option, and that at least assuages some of the problems.

Edited by thebruce0
Link to comment

There a some things that ruin the text instantly by altering what is written before storing, at least at staging.geocaching.com, like trying to write ² ³ } @ on german keyboards.

 

Other things like starting a line with 2. or using ~ or writing [some text](sometext) are 'only' displayed differently on the website and should go into gpx or API like written.

 

By the way, please Groundspeak, it is completely useless to display [some text](sometext) as <a href="sometext" target="_blank">some text</a>. At least test whether there is at minimum one character followed by a dot and a top-level domain between () before interpreting it as url.

 

If you type Markdown-syntax elements they should go into gpx or API like written, as Markdown is praised for being readable also on devices that don't support Markdown :ph34r: , wouldn't make any sense do translate Markdown to html for gpx or API [at least not if not asked for].

Edited by AnnaMoritz
Link to comment

I tried the staging.geocaching.com site

It is impossible to add the standard {*FTF*} tag to a log. First the *FTF* will be FTF in italic and when the } is added the row is select and } is not added to the text.

And please don't say that FTF in not a goundspeek thing. You have made adds for premium accounts that said get premium to get notification an FTF.

 

This might not be a problem, as although it displays as italic, the underlying text in the log is still {*FTF*}, and I would guess that the API pulls down the underlying text and so Project-GC et all will still see it as an FTF tag and record it as such.

 

That is what I would assume. If you use the API to download then you'll get the raw markdown text, which is {*FTF*}. Everything should work fine.

 

If you use something that screen scrapes, then all bets are off as the formatted would have been applied.

 

That doesn't make sense to me. If the API returns the raw markdown text then in puts a burden on every client that uses the API to implement a Markdown processor. IF GSAK retrieves the most recent logs then adds the log elements that it sends to a GPS, then every "Geocaching ready" GPS would have to understand Markdown as well.

 

It looks to me like when a GPX file is created from a PQ that it escapes all HTML (it would need to because the html is within an XML element). In other words, it converts a greater than/less than symbols to > and < (html entities). There are lots of libraries which have "escape html" and "unescape HTML" so it's fairly easy to convert escaped html into something that can render. However, if the raw markdown was put into a GPX file or returned via the API, and a client wants to render it as HTML, not only do they need a Markdown processor but they need to use one that understands the Groundspeak specific Markdown (there isn't a *standard* Markdown syntax).

 

As an aside, the element for a log in a GPX file looks like this:

 

<Groundspeak:text encoded="False">Woo Hoo!  FTF</Groundspeak:text>

 

If someone chooses to encrypt their log it's going to look like this:

 

<Groundspeak:text encoded="True">[Woo Hoo!  FTF! Hint: it is under the big rock]</Groundspeak:text>

 

Note that the log text starts and ends with bracket characters, immediatedly followed by a less-than sign. Is that going to parse as a link?

Edited by NYPaddleCacher
Link to comment

That doesn't make sense to me. If the API returns the raw markdown text then in puts a burden on every client that uses the API to implement a Markdown processor. IF GSAK retrieves the most recent logs then adds the log elements that it sends to a GPS, then every "Geocaching ready" GPS would have to understand Markdown as well.

 

Actually no, they don't have to understand markdown. The intent with Markdown is that it degrades nicely. That is, it displays in a readable format on web pages, mobile, and hand held devices. They don't need to understand markdown.

 

If they do understand markdown, then it's a bonus and you get the extra formatting.

Link to comment

What is highly needed in my opinion is a switch that allows to switch off markdown and the annoying editor and allow pure text logs (like pure text cache descriptions are possible) also for those who log via the website.

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.

Link to comment

And please Groundspeak, give correct detailed information, what and what combined with what will be taken really as Markdown so that users can remove/avoid everything they otherwise feel their logs are save from formatting and are not save although the editor suggests 'it's only italics, bold, heading, links, quote, lists that you have to avoid if you don't like it'.

 

With html you know: no <, no html, no danger. No ...., no characters that might or might not display correctly. Also with ubb/bbc: no [], no problem, also [] with anything else than known bbc/ubb inside - no problem.

 

If you know that in our old logs there is no < and no [valid bbc], you are finished with html and bbc, done and clean.

 

With Markdown (and the current implementation) the danger of not foreseeable results might lurk around every corner, also only using an US-keyboard, as blanks, #, _, *, ., [], (), etc. trigger Markdown to react.

 

For future logs you will see it instantly, but if you want old logs be shown like you wrote them initially, looking at every single old log whether something happened to it seems really heavy-going.

 

Easy for them who only write TFTC or who know for sure they never used #*_()[] and never started a line with anything else than [a-z][A-Z].

Link to comment

For future logs you will see it instantly, but if you want old logs be shown like you wrote them initially, looking at every single old log whether something happened to it seems really heavy-going.

I'd consider it a major fail if they don't provide us with a tool that identifies our existing logs that contain HTML or BBCode. We've been told we need to fix our own logs, so do they seriously expect us to go through our logs one at a time? An automated solution wouldn't be difficult to create (look for <...> or [...]) and would save loads of time on the part of the users. EDIT: I guess that wouldn't help with some of the unwanted Markdown rendering; not sure what can be done about that.

 

Again, Groundspeak, this is something YOU have chosen to do, not the users. Please don't break things and cause the users loads of work, and then simply wash your hands of it and walk away. You're causing the extra workload, so you should be providing the tools to minimize or streamline that workload.

 

I hope the Lackeys in charge of manning the support portals are prepared for the onslaught after this is rolled out! They better be trained to the point of being SMEs with Groundspeak Markdown before they need to start providing the support for it, because I can guarantee they're going to get a lot of requests from people whose logs aren't displaying correctly. If they thought they were getting a lot of questions about the "distinct finds" count... :o

Edited by The A-Team
Link to comment

I see it as a great thing that Groundspeak are taking this initiative and cleaning up their system. I have no issue with Markdown and look forward to using it in the future.

 

What infuriates me though is the lack of willingness to invest time and resources updating the old BB code logs. Yes, it may be a big job and it would take up time and resources. But many thousands of people all over the world have spent a large amount of hours, over many years, writing up these high quality logs. These are paying customers of Groundspeak who have invested their own time to write up great looking logs that help make the page on the Groundspeak listing more presentable.

 

And as of early February, how are they repaid for these many hours spent doing this?

With absolutely nothing. These colourful, presentable logs will be reduced to nothing more than long lines of code unless people spend further hours (of their own resources) on fixing each and every one of them up. I reject the notion that these logs will just sink to the bottom and not get read any more. Not everyone lives in New York. Many great caches only get found once or twice a year (if that) and a high quality log on one of these will remain and be read by many, over and over again.

 

This is all because of a lack of willingness by Groundspeak to spend resources on anything that doesn’t involve the precious app! Well thanks for nothing, I guess the TFTC logs don’t really worry them as long as people keep buying the premium membership and tracking codes.

Link to comment

I hope the silence from HiddenGnome is an indication that they're busily working away at addressing or mitigating the impacts of the problems being presented here, but I fear our concerns are being dismissed like with past changes.

 

Groundspeak, you have learned from past mistakes that we do have a good track record of pointing out valid problems, right? You're getting free UAT and design assistance. It would behoove you to heed some of our warnings/advice.

Link to comment

I will convert zero of my old logs, any industry that destroys 15 years of working one way without a fully tested migration path is headed down a very long dark avenue. I would also wish to have some indicator that informs whether a log is markdown or not. It is no coincidence that files with markdown have a .md suffix to distinguish formatted files from their humbler brethren.

Link to comment

I'd be surprised if they render the Markdown syntax before storing the log text in the database. That would completely defeat the purpose...

 

So if they store the plaintext in the db, then any API retrieval would, at the very least, receive the plaintext/raw version with which they can do as they please for how they wish to display log text.

 

I had a play on the staging site, and having entered a log with {*FTF*} it rendered as {FTF} on the page, but subsequently editing the log still showed the underlying {*FTF*}, so they're storing the plaintext in the DB. It would make sense to me for them to serve up the plaintext to any API call, and it's then up to the device displaying it whether or not it can/will handle MarkDown syntax, and if not then it will still look reasonable -which is the point of MarkDown.

Link to comment

GSAK has already implemented Markdown, and I would like to quote the release notes:

Logs on or before 2nd February 2016, will also support (but MarkDown will be applied first) BBCode. Logs after 2nd February will only support Markdown. I understand this might be slightly at odds with some people as old logs will then not show exactly the same a they will when viewed on the Groundspeak web site. I am of the opinion that it will be clearer for GSAK users if these old logs still show as they were intended by correctly rendering the BBcode. However, I have also allowed this to be changed via ConfigOther.txt

 

Not only are old logs respected, but you as a user can tweak it the way you want!

 

Why is it so difficult for Groundspeak to respect paying customers and their data?

 

It's been pointed out several times already, thousands (millions?) of people have used thousands of hours to write logs, in the format they have been told they should write in. And suddenly, that format is changed. Not only will the old formatting look ugly, the logs may also change meaning if they happen to contain Markdown markup. So it's not only the 3% that was dumb enough to use something they were told they could use, that gets their old logs destroyed. Its everyone that was dumb enough to write something that Groundspeak's Markdown implementation will treat as markup.

 

Groundspeak, please respect your paying customers.

 

I guess it won't take long before 3rd party tools offer better ways to read logs, that respect old data, or before someone makes a user script to fix this. But that won't help the thousands of people that don't know how to use user scripts.

Link to comment
many thousands of people all over the world have spent a large amount of hours, over many years, writing up these high quality logs.

Presents a good question. The announcement quoted 3.5% of logs using BBcode. But if the numbers were weighted by length of log, what would the % be? Certainly far higher than 3.5%, since the longer the log, the more likely that it uses BBcode. For example, 3/4 of my logs use BBcode, and IIRC, my average log length is over 900 characters. I don't have time to try to analyze a broader sample at the moment, but to make the gc.com analysis honest, they should give us this number.

 

Edward

Link to comment
many thousands of people all over the world have spent a large amount of hours, over many years, writing up these high quality logs.

Presents a good question. The announcement quoted 3.5% of logs using BBcode. But if the numbers were weighted by length of log, what would the % be? Certainly far higher than 3.5%, since the longer the log, the more likely that it uses BBcode. For example, 3/4 of my logs use BBcode, and IIRC, my average log length is over 900 characters. I don't have time to try to analyze a broader sample at the moment, but to make the gc.com analysis honest, they should give us this number.

 

Edward

I've written many long logs, but I could probably count the number of logs with BBCode or HTML on my two hands (maybe with a foot too). Length doesn't necessarily imply the use of formatting.

 

A number I'd find far more interesting than the 3.5% would be the percentage of logs that will be affected by unwanted Markdown rendering. That number plus the 3.5% is the total number of logs that will be broken.

Link to comment

A number I'd find far more interesting than the 3.5% would be the percentage of logs that will be affected by unwanted Markdown rendering.

 

In case that in the future they only offer their WYSWYG editor for logs they should in particular try to estimate the percentage of cachers affected by using non US keyboard layouts. This is a number they should really get frightened about if the system works like on the staging site.

Link to comment

I have 5734 found logs plus 808 logs of other types, and I use UBB Code in practically all of them: example.

 

Probably, it would be too risky for Groundspeak to try to automatically convert large masses of free form text. However, some mechanism could be supplied to allow the user to process offline all their logs. It would be nice to have a mechanism like the following:

 

- An operation to schedule the export of all the logs of the user. The format of the file could be this:

 

--- guid ---
text of the log
--- guid ---
text of the log
--- guid ---
text of the log
...

- In my case, I would process each of my 6542 logs using this simple JavaScript function:

 

function ubb2markdown(str) {
 str = str.replace(/\[b\](.*)\[\/b\]/igm, '**$1**');
 str = str.replace(/\[i\](.*)\[\/i\]/igm, '*$1*');
 str = str.replace(/\[url=([^\]]*)\](.*)\[\/url\]/igm,'[$2]($1)');
 return str;
}

- Finally, an operation to upload and to schedule the update of all the user logs.

 

This mechanism would keep invariant the guid, the date and the type of each log. Only the text contents would be updated.

Edited by geo-amd
Link to comment

Probably been asked and answered here, so sorry if it's being asked again.

 

I just attended the Mega Event in Yuma, Arizona, put on by the "S*W*A*G" group. If the "*" (asterisk) symbol is being used in the Markdown language to distinguish bold, italic, etc. -- what do I type in my logs (or in GSAK) to get an asterisk to look like an asterisk, without it being interpreted as Markdown code?? How do I get S*W*A*G to look like S*W*A*G? Thanks to whomever replies...

Link to comment
How do I get S*W*A*G to look like S*W*A*G?

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

Edited by EngPhil
Link to comment
How do I get S*W*A*G to look like S*W*A*G?

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

 

That's why I'm guessing/hoping that the API will provide options to retrieve the raw log text or the pre-formatted text using GS's Markdown implementation.

Then, the only way Markdown would be interpreted incorrectly would be if a 3rd party's algorithm differs from GS's yet they specifically request the Raw log text and format it themselves.

Link to comment
How do I get S*W*A*G to look like S*W*A*G?

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

 

That's why I'm guessing/hoping that the API will provide options to retrieve the raw log text or the pre-formatted text using GS's Markdown implementation.

Then, the only way Markdown would be interpreted incorrectly would be if a 3rd party's algorithm differs from GS's yet they specifically request the Raw log text and format it themselves.

 

I would think that it would be necessary to retrieve the raw text if GS is going to continue to support editing of a log that has been submitted. If someone adds a link to their log using Markdown syntax, then edits the log, they should not have to convert HTML back to Markdown to re-submit the log. If the API supported a function that would accept a parameter which indicated whether or not to transform the Markdown to HTML or provided two functions (e.g. getLog and getRawLog) the 3rd party clients would have the choice on which function to use. The GS site would use the getRawLog function for returning a log for editing and getLog for returning transformed Markdown for rendering as logs on a cache page (and elsewhere on the site).

 

 

Link to comment

I would think that it would be necessary to retrieve the raw text if GS is going to continue to support editing of a log that has been submitted.

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)

Link to comment

That's why I'm guessing/hoping that the API will provide options to retrieve the raw log text or the pre-formatted text using GS's Markdown implementation.

Then, the only way Markdown would be interpreted incorrectly would be if a 3rd party's algorithm differs from GS's yet they specifically request the Raw log text and format it themselves.

 

I would think that it would be necessary to retrieve the raw text if GS is going to continue to support editing of a log that has been submitted. If someone adds a link to their log using Markdown syntax, then edits the log, they should not have to convert HTML back to Markdown to re-submit the log. If the API supported a function that would accept a parameter which indicated whether or not to transform the Markdown to HTML or provided two functions (e.g. getLog and getRawLog) the 3rd party clients would have the choice on which function to use. The GS site would use the getRawLog function for returning a log for editing and getLog for returning transformed Markdown for rendering as logs on a cache page (and elsewhere on the site).

 

Yep, exactly.

One for raw log retrieval (best for editing and saving) and one for formatted Markdown (to display the log using Groundspeak's implementation of Markdown which may differ from other 3rd parties).

One step further as I mentioned in a previous comment may be to provide a parameter for what formatting syntax to retrieve the log - HTML, Richtext, etc. It could even be just one API call where 'raw' is the default format. Who knows.

 

But serving both the raw and the formatted text is in their best interest if this is the way they're moving forward.

Link to comment

First, I admit my lack of knowledge of this language-saftey issue. It would seem to me that plain text would be the safest language to use in logs.

 

As a paid member of Project-GC, I received the following in the Newsletter earlier today...

Markdown

 

As some of you know, Geocaching.com is switching from a mix of bbcode and html to Markdown in logtexts. The switch is happening sometime today.

 

We have been asked to be able to assist in converting logs from the old format into the new. This is not possible. The Geocaching.com LIVE API does not support editing or deleting logs, therefore we can not assist in changing them.

 

What we could do, is to list those logs needing a conversion, and suggesting a new format for them. But we doubt it's really worth the effort. It seems quite hard to convert from bbcode/html into Markdown, there will be errors and issues. We also assume that Groundspeak has tried it, but realized it wasn't worth the effort.

 

What we have done though, is that we are helping some of our Challenge checkers. The example log returned by the script now has some of the tags automatically converted.

 

  • BBCode: code, url, b, i
  • HTML: pre, a href, b, i href

 

Maybe there will be some solution for those affected by this change.

 

Now that this is done, can the developers get back to work on the Search page? We are still waiting for the ability to make lists or PQ from search results!!

Link to comment

How do I get S*W*A*G to look like S*W*A*G? Thanks to whomever replies...

 

Emphasis marks "*" and "**" will only be interpreted if they surround the word. S*W*A*G will render exactly as written. *S*W*A*G* will render as S*W*A*G (or **S*W*A*G** as S*W*A*G)

Am I missing something, then? Because when I'm in the latest version of GSAK (851B64) and enter S*W*A*G into a log and do a preview, I see SWA*G as a result. The "W" is italic, the rest are not, and only one asterisk appears between the A and G. Is it GSAK that's having problems rendering the text? I know Clyde just started adopting the Markdown language into GSAK, but am I doing something wrong? It took me a while in the beginning (years ago) to figure out how to insert HTML code into my logs to get bold, italic, colored text, and make links work correctly. Now I see Markdown doesn't support colors -- and GS isn't supporting HTML. And text isn't appearing as I would expect it to. I'm confused...

Link to comment

Am I missing something, then? Because when I'm in the latest version of GSAK (851B64) and enter S*W*A*G into a log and do a preview, I see SWA*G as a result.

 

The API is providing the RAW text so renderings outside of geocaching.com are partner specific. By default, the Markdown specification allows the ability to add bold and italics in the middle of words so the example that you provided would be expected. However, the rendering on geocaching.com has been modified to only support bold and italics surrounding a word in order to avoid unexpected behavior with "*" and "_", especially in the case of events and usernames.

Link to comment

Am I missing something, then? Because when I'm in the latest version of GSAK (851B64) and enter S*W*A*G into a log and do a preview, I see SWA*G as a result.

 

The API is providing the RAW text so renderings outside of geocaching.com are partner specific. By default, the Markdown specification allows the ability to add bold and italics in the middle of words so the example that you provided would be expected. However, the rendering on geocaching.com has been modified to only support bold and italics surrounding a word in order to avoid unexpected behavior with "*" and "_", especially in the case of events and usernames.

 

So... does that mean the only reliable display of log content is on the web at geocaching.com where the Markdown is properly parsed? If the API won't be providing formatted versions of the log text, then will GS be providing their official implementation of Markdown so 3rd parties can render log texts the same as on GC.com? (else recommend all 3rd parties to just display raw text?) ...this seems like a big consistency problem...

Edited by thebruce0
Link to comment

So... does that mean the only reliable display of log content is on the web at geocaching.com where the Markdown is properly parsed? If the API won't be providing formatted versions of the log text, then will GS be providing their official implementation of Markdown so 3rd parties can render log texts the same as on GC.com? (else recommend all 3rd parties to just display raw text?) ...this seems like a big consistency problem...

I would say the only reliable display is a 3rd party tool that respects both old and new logs, like GSAK.

Link to comment

I would say the only reliable display is a 3rd party tool that respects both old and new logs, like GSAK.

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

Link to comment

Great the change to markdown change the look and counting für Event, MEGA, GIGA Events.

 

Normally you write your WA with text text *2* Persons see you there text text

 

With *2* (or *1* for one perosn) the eventowner can filter or search by *xx* and count all xx up.

 

Now with markdown all logs show only 2 in italic. so nothing to filter and count up.

 

Hard to get the number of people that want to come, now you have manually go to 1000's logs an cound by hand. :(

Link to comment

From the Markdown Guide: under How to Format at th ePost a Log page

 

line break: Select ENTER on your keyboard

 

I tried but I only get one Line Break

 

Old Log / style:

 

Go out find......nice cache, had a good trip.


Thanks for the cache.

Greetings
Wulfman_Do

 

but now i get only:

 

Go out find......nice cache, had a good trip.

Thanks for the cache.

Greetings
Wulfman_Do

 

How can i get the two line breaks between "...good trip." and "Thanks..." ?

 

I also use it for a better overview in anouncements to separate different points or informations.

 

Thanks

Link to comment

Okay, I hadn't heard about this problem until I made an entry in the field today and then went back in to update it later. What the heck happened?? I couldn't believe what I saw, but thought it was a bug brought on by a mishap during a software upgrade and would soon be remidied. Not so, and now I find over 2200 of my 2674 finds look [bad] on screen. And they expect me to edit all of the entries? You've got to be kidding! I can't imagine what kind of a cluster their site is going to look like now....

 

Surely there's a better solution.

Edited by Keystone
flushed potty language
Link to comment

We often get emails thanking us for logs of more than an acronym on even the most basic/simple hides.

After looking at logs and only changing one (just removed the italics), not gonna repair the rest that didn't really have any issue before this mess.

If this markdown thing doesn't work out, what's next?

Would everything revert back with the same issue all over again?

Guess I can write plain, dull (or TFTC) logs as many today too...

Link to comment

I started to fix my old caches with BB code or HTML in the and found with som regular expressions and GSAK that i had 120 logs with that formatting most was href links. That was as many as I expected 2.2% of my finds.

The only problem i could not fix was that links are not possible in preformated text so some challenge logs of mine have lost som links

 

But the I found the most common markdown error i my logs and that is that some text is renders as header 2 and is quite large on the cache page.

The reson in that one or more - along on a row tags the line above as header 2.

if there are more then three - you get a horizontal rule as described in the markdown guide in the editor but only if the line above is blank or just spaces else the line above is formated as header 2

With som more regexp i found that i had 818 log that will be incorrect formated and that is 15% of my logs

There was more logs on the caches that got strange formating because of -----

 

If someone is interested to look at their own logs ans uses gsak the the sql query that i used is. Replace Target. with your nic

 

select name, parent,ltype,ltext from (select b.lparent as parent,ltype,ltext from (select llogid,lparent,ltype from logs where lby="Target.") as a inner join LogMemo as b on a.llogid=b.llogid and a.lparent=b.lparent where ltext regexp "\r\n.+\r\n(\-)+\r" ) inner join caches on code=parent

 

I often when i am on a caching trip write a short suffix about the trip separated with ---- and a unique text for that cache above it now the last line on the unique text is quite large.

If there is a empty row above the --- a nice horizontal rule i displayed.

 

the online editor on the log page is from http://www.toptensoftware.com/markdowndeep/dingus and on that format more markdown is included then in the log edit how to format The Setext-style format is not listed on gc.com only the atx-styles

 

Setext-style:

 

Header 1

========

 

Header 2

--------

 

atx-style (closing #'s are optional):

 

# Header 1 #

 

## Header 2 ##

 

###### Header 6

 

I have seen stats that 3.5% of 560 million logs used HTML an BB code and will be incorrect. But are there any stats on how old logs have unintentional markdown included? Logs with unintentional markdown that results in much more unreadable log pages the missing html/BB code formatering

 

I also noticed that ending # is required on gc.com markdown but is optional inte other markdown. If that was not the case i would have 2073 logs that had a heading 1 on the first row. It will be interesting to se if when mobile apps renders markdown if that i impemented

Link to comment

I also noticed that ending # is required on gc.com markdown but is optional inte other markdown. If that was not the case i would have 2073 logs that had a heading 1 on the first row.

That requirement was added as a result of feedback during testing. Lots of geocachers begin their logs with a number counter, like "#3738" for the user's 3738th overall cache find, or "#5 of 32 cache finds today." Thanks for noticing!

Edited by Keystone
Link to comment

HAS CHANGE TO MARKDOWN DESTROYED TAGGED LOGS WHEN YOU ACHIEVE FIRST-TO-FIND?

 

On the advice of Groundspeak's own stats website "MyGeocachingProfile" and the major stats site "Project-GC", I chose from years ago to tag my first-to-find caches with **FTF**, which now is showing as 'bolded' FTF (i.e. FTF).

 

I will be furious if these two stats sites are no longer able to pick-up my FTFs - I have around 2730 FTFs and FTF hunting forms one of my main pleasures when caching. I appreciated Groundspeak do not acknowledge or care about this sidegame, but a lot of us paying members do enjoy this aspect and wish to have the ability to count them.

 

So, although **FTF** is still showing when editing tagged logs, it is displayed on cache pages as FTF - is this another case of HQ implementing major changes without seeing through all the consequences for the paying membership!!!

 

I am not amused!!!!

Link to comment

On the advice of Groundspeak's own stats website "MyGeocachingProfile" and the major stats site "Project-GC", I chose from years ago to tag my first-to-find caches with **FTF**, which now is showing as 'bolded' FTF (i.e. FTF).

Project-GC uses the API, and will get your logs unformatted. Project-GC will still read **FTF**.

MyGeocachingProfile requires you to upload your "My Finds" PQ, which also contains unformatted logs. MyGeocachingProfile will still read **FTF**.

Link to comment

On the advice of Groundspeak's own stats website "MyGeocachingProfile" and the major stats site "Project-GC", I chose from years ago to tag my first-to-find caches with **FTF**, which now is showing as 'bolded' FTF (i.e. FTF).

Project-GC uses the API, and will get your logs unformatted. Project-GC will still read **FTF**.

MyGeocachingProfile requires you to upload your "My Finds" PQ, which also contains unformatted logs. MyGeocachingProfile will still read **FTF**.

 

Thanks thromfre - that is great news and thanks for quickly putting my mind at rest!! Phew!!

Edited by PlasmaWave
Link to comment

We often get emails thanking us for logs of more than an acronym on even the most basic/simple hides.

After looking at logs and only changing one (just removed the italics), not gonna repair the rest that didn't really have any issue before this mess.

If this markdown thing doesn't work out, what's next?

Would everything revert back with the same issue all over again?

Guess I can write plain, dull (or TFTC) logs as many today too...

 

I can understand being concerned about existing logs using legacy markup and how they render. A switch to render the old way if last modification date was older than yesterday.

 

But I don't understand your comment about plain/dull logs. Why would the removal of html/bbcode impact your ability to write longer logs?

Link to comment

If the API won't be providing formatted versions of the log text, then will GS be providing their official implementation of Markdown so 3rd parties can render log texts the same as on GC.com? (else recommend all 3rd parties to just display raw text?) ...this seems like a big consistency problem...

 

Their implementation is likely some sort of .NET implementation. The 3rd parties out there likely use a combination of java, php, node.js, C#/.NET. There is no implementation that would work with everybody, and their implementation probably has geocaching.com specific ties into back end services that they wouldn't want to expose.

 

The nice thing about markdown is that it degrades nicely. On a device (such as a GPS), I'd much rather see "I'm so great, I was *FTF* on the cache" than "I'm so great, I was <i>FTF</i> on the cache".

 

So getting the "raw" logs is the best way of handling this, as the 3rd party software stack is likely to be completely different than geocaching.com's.

Link to comment

The nice thing about markdown is that it degrades nicely. On a device (such as a GPS), I'd much rather see "I'm so great, I was *FTF* on the cache" than "I'm so great, I was <i>FTF</i> on the cache".

 

So getting the "raw" logs is the best way of handling this, as the 3rd party software stack is likely to be completely different than geocaching.com's.

This is what I don't get. HTML is a standard, and renders perfectly well both in GSAK and on my GPSr (Garmin). It also used to render well on geocaching.com.

Markdown however, only renders fully on geocaching.com. I don't understand how that is being consistent.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...