Release Notes (Website: New geocache and trackable logging flow) - November 2, 2023

[+brendan714]

A couple comments:

- I like the new image upload feature.  After I click on "add details" for an image, it would be nice if the image preview was larger.  It's a bit small to see what's going on in the image.  If I zoom in the webpage, it looks like it's a high quality preview of the image, it's just that the size is really small. 

- I wish there was a 2nd "post" button at the top or somewhere easily clickable so I don't have to scroll down to then find the post button.  It would be a nice quality of life improvement when logging dozens of caches in one sitting. 

[+arisoft]

Now I had opportunity to use the new logging flow. I noticed something that was not expected behavior. I had an image in a Virtual Draft and wanted to check that it is ok. I clicked the image with the right mouse button and selected it to open in a new tab. Instead of seeing the image the browser showed me an empty tab. It too me a while to notice that the image was downloaded instead of being shown to me. Maybe it had wrong MIME type. (Firefox with Windows 10)

Edited November 12, 2023 by arisoft

[+little-leggs]

My first impression of the new layout was good I like it.

until I attempted to log a TB Discovery.

 

Log preview

See a preview of your log including any formatting and markup.

 

I like to use # ,###, *, **, and *** in my logs along with the odd [8d]

 

I found that the PREVIEW is not what gets posted ?

 

for bold type , # Littel-leggs show in the preview as BOLD , but when you view the actual log is not , its what you have typed in # Little-leggs

you still need to type # Little-leggs #

etc

 

I'd like the PREWIEW  re-gigged  

[MZCacheHunter]

On 11/9/2023 at 10:28 PM, ari54321 said:

If you wish to correct the dates of already-uploaded images, you can delete the images and re-upload them through the edit log page.

@ari54321 I understand that this was a suggested workaround for the "current date" bug when uploading an image to an older found.
But wouldn't it be much easier to reactivate the manual date setting in the "edit image" dialog, as was previously the case?

[+DaddyKool]

On 11/11/2023 at 7:11 PM, kunarion said:

 

I downloaded a utility called "Fotosizer" which is free to use, and after I make any edits (such as blotting out a Tracking Code), I drop all photos from both my phone and DSLR camera into that software, and it re-sizes them all perfectly to 800x600.  It can be set to most any size, but that size has worked just fine for years.  All I need to do next is choose which photos to use in which logs.  It is of course done at home, and after I've submitted most of the logs.  But it sure beats waiting for a fancy "resizing feature" on the web site, which I likely would never use.  I'd see the many logs about how it doesn't work, while I'm uploading nicely sized photos as I've always done without issue.

 

There are also re-sizing Apps for phones, if you're into that sort of thing.  I got some decent ones when they were free for a day.

 

 

image resizing has been an automated part of uploading images up until now. It hasn't been an additional "feature" utilised by geocachers. For me it has worked seamlessly for all the 7424 images that I have uploaded since I started geocaching in 2009. With the latest "logging flow" I can't do it without taking several additional and cumbersome steps. I cannot regard the newly introduced image handling as an improvement. On the contrary, it's a giant leap backwards. 

[+Rikitan]

Great job, I'm loving new logging interface.

Reporting one minor bug:

In Log Preview, uploaded Image is titled by Image Description, instead of Image Name.
However, it's correctly titled by Image Name after log is posted. It's only Log Preview, which has it wrong.

Kudos to development team!

 

[+Viajero Perdido]

May I suggest a Loading spinner?

 

First time I saw the new interface was when I edited a log.  It had to load a pile of JavaScript etc, but I didn't realize it was still loading.  I just saw "Visit another geocache" and thought, is this broken?

 

Overall I like it.  Good job.

 

... except for the possible side effect of breaking old search bookmarks.

[+ari54321]

On 11/11/2023 at 7:40 AM, Boomshanka said:

It looks like this page has been binned as part of the upgrade. I used to like seeing when caches I've found have been found recently... can it be reinstated?

https://www.geocaching.com/seek/nearest.aspx?ul=Boomshanka

 

Thank you for reporting this. This is an unrelated bug; we are not retiring the old ("seek/nearest") search results as part of this release. The team is looking into a fix.

[+Boomshanka]

28 minutes ago, ari54321 said:

 

Thank you for reporting this. This is an unrelated bug; we are not retiring the old ("seek/nearest") search results as part of this release. The team is looking into a fix.

Excellent, that would be great and many thanks for the update.

[+dadoskawina]

I've got today notification of my log removal. It looks as follow:

i

Quote

Your log was removed from Drewniane rzeźby Brzezin by Tropisiec for the following reason: Poprawione As a reminder, all logs must adhere to our Terms of Use. Happy geocaching, Geocaching HQ

 

Regarding the information provided in this mail:

 

1. There is no link to deleted log (previously it was always attached). I cannot check the deleted log content. I cannot even check the deleted log type.

2. What should I do if I claim that the log should not be deleted? As I do not know the deleted log content, I cannot argue with CO, I cannot post this log again, I also cannot report problem to HQ.

3. I suppose that my deleted log was Needs Maintenance type. Why are you allowing such log deletions?

4. It is a good improvement that the reason is now provided, but IMO the reason should clearly state which point from geocaching rules was broken here. For my case, the reason is "corrected". So, which point of "Terms of Use" was broken?

[+thebruce0]

40 minutes ago, dadoskawina said:

3. I suppose that my deleted log was Needs Maintenance type. Why are you allowing such log deletions?

Good points. To this one, NM logs could always be deleted; just remember that when you post a NM, it enables the "Needs Maintenance" attribute on the listing. If the NM log is deleted, the attribute is not deleted. So the CO may be able to 'clean up' the log history, but the fact that the listing Needs Maintenance remains until the owner performs an Owner Maintenance.

Nonetheless, your other points I think are good.

[+baer2006]

1 hour ago, dadoskawina said:

1. There is no link to deleted log (previously it was always attached). I cannot check the deleted log content. I cannot even check the deleted log type.

I reported this bug on 19 October:

 

 

[Nylimb]

Does anyone know what the system requirements are for the new logging flow?  I have an old computer, running Mac OS X 10.11 and Firefox version 78.15.0esr (64-bit), and when I try to log anything I get a blank window.  If I knew what version of Firefox the new logging flow requires then maybe I could check to see if my hardware is capable of running it.

[+Boomshanka]

4 hours ago, ari54321 said:

 

Thank you for reporting this. This is an unrelated bug; we are not retiring the old ("seek/nearest") search results as part of this release. The team is looking into a fix.

Looks like it's back up again Many thanks

[+ChriBli]

31 minutes ago, Nylimb said:

Does anyone know what the system requirements are for the new logging flow?  I have an old computer, running Mac OS X 10.11 and Firefox version 78.15.0esr (64-bit), and when I try to log anything I get a blank window.  If I knew what version of Firefox the new logging flow requires then maybe I could check to see if my hardware is capable of running it.

It does not work with Firefox 86.0.1 either. It does work with the latest version of Brave, probably with the latest version of anything. I don't think anyone bothered to compile any system requirements.

[+CCFwasG]

On 11/8/2023 at 2:44 PM, ChriBli said:

But having to do the resizing yourself is a major issue, and something that will affect almost everyone (that uploads pictures at all). The very small fraction of cachers that post to this forum seem to have various procedures set up already to downsize or otherwise adjust their images, but I'm willing to bet that the most common case is that you snap a photo with your phone, not having decided yet whether or not this is to be uploaded with a log or used for something different, and when you decide to upload it you want to just drop it there. Not launch another program or app, do a lot of fiddling and then save the file in another location, upload from there and then have a bunch of files left on your disk.

 

So, the question is, why can not an uploaded image be automatically downsized/recompressed at least if it exceeds 5 MB? Note that this would not mess anything up for anyone that is already in the habit of doing this manually for one reason or another.

I absolutely agree. I didn't even realize they had changed this and my number one question is: if the old logging system was able to re-size an image WHY is the new one UNable to do that too?

I am the type of cacher mentioned, I grab photos and add to logs a lot. I especially like to add a log photo where appropriate or a scenic photo from nearby or en route. If it won't take the size my camera produces I just won't bother, I am not going to manually re-size photos which I already HATE having to do for GC messaging where it is often CRUCIAL to send someone a photo (like a maintenance issue or couldn't log for some reason etc). That drives me nuts. 

I only came here to complain about the trackable logging that changed - I now have to be sure to uncheck "visited" from my locked TBs! I never used to have to do that. So count me as one who does not like the new logging style. 

[+meltdiceburg]

Why have you limited the filesize to 5MB on photos. This is awful, most phones take photos over 5MB and you've always resized them before, and don't give me consistency as your app will accept and resize them. I don't have time to manually resize photos, so just won't add any going forward. Thanks Groundspeak for taking us back to the stone ages, as usual.

Edited November 14, 2023 by meltdiceburg

[+arisoft]

37 minutes ago, meltdiceburg said:

Why have you limited the filesize to 5MB on photos. This is awful, most phones take photos over 5MB

 

And even bigger - 50 MB for example.... there must be a rational limit for those images. Automatic resizing at the client side would be the second best option after the best option, which is to limit the size in the camera app. It is pity that some basic smartphones does not have this option.

Edited November 14, 2023 by arisoft

[+Tundra Wolf]

I really don't see the point in changing this.  I was very happy with how the "logging flow" was before since I only use the website.  But I understand that sometimes things change.  My major issue with this new "experience" is that my trackables in my inventory are no longer alphabetized.  That makes it difficult to find the trackable I want single out to visit a cache I've done.  I have to sort through them which slows my logging down (more than it already is).  

 

Can there be an option button added (like the log date pin) to change from (seemingly) random sorting of trackable inventory to an alphabetized list?

[+TJnAJ]

I am absolutely loving the majority of the changes here. They are saving me time when logging, and it is more intuitive. Everything except one thing.

 

The file size of the uploaded picture. 5mb is much too small. I am now having to resize every picture that I upload to the site (and there are quite a few). It's disappointing that the site doesn't downsize the pictures automatically like it used to do. The time saved on the other changes do not outweigh the time now needed to resize every picture.

 

And while this is just an inconvenience for me, I am wondering how many cachers will just decide not to add any pictures as they don't know how to resize their files. And I love looking at pics added to my caches, so this is definitely a sad change.

[+ChriBli]

2 hours ago, arisoft said:

 

And even bigger - 50 MB for example.... there must be a rational limit for those images. Automatic resizing at the client side would be the second best option after the best option, which is to limit the size in the camera app. It is pity that some basic smartphones does not have this option.

I don't know.. there was no (practical) limit before, was there? Storage cost x image size produced by consumer equipment should stay fairly constant, I believe. Automatic resizing was already done, but just to store an extra low-resolution copy. Why could it not be done also on the stored "original", if that is over some arbitrary limit in size? That to me would be the best option, with doing away with storing the original at all as a distant second.

 

Limiting the size in the camera app assumes that you know that all your photos are intended for this purpose, or that you are willing to sacrifice the high resolution of your expensive new phone for all your photos.

[+Fields111]

I have already used the new page for logging but only with "Founds". Now I saw the explanations of all the changes and I have some doubts.

 

1 - If I want to log a "Found" and report the cache needs maintenance, I deduce I have to choose now the "Owner attention Requested" (OAR) right? What is the result in terms of logs history? It will make two logs, one "Found" and one OAR? I know there's some issues with the dates of OAR logs, but in this case, the "Found" log will have the correct (found) date, right?

 

2 - In case there would be two logs, if the owner deletes the OAR the "Found" log remains in it's place?

 

3 - Related to question 1, if I just want to log a OAR, without a found, I would select the OAR type, but how the system knows it's just a "note" and not a "found"?

[+moravan]

I haven't used the new logging page in the past either. I was using the old one, which was accessible via the button - "Opt Out". Now after the changes on November 2, the button is not available. Can you make it available again?
The old logging system suited me perfectly, I don't need the new one.

Thanks

[+Little Adventures]

User interfaces have gotten worse over the years as minimalist elements have been employed. The new logging page was an example of this, and the new, new login page is a continuation of this. Personally I've always preferred a page with more contrast and fields that are easy to see. Now as I get older, those preference are now needed accessibility features. I do not like the new logging page. I do not like that the opt out button is missing. It's not really the button I'm missing, it's a well designed and useful page I'm missing; like the original logging page.

[+crystaloops]

It's slightly frustrating they took away the edit image date option. Sometimes I don't log the find during the trip until a day or couple days later due to wifi availability or just simply how tire I am. You can change the date of the log, but the image is dated as the date you upload it, and there's no way to change it to the date of the log anymore. 

[+MrARC]

Is it normal that I can't delete a "Write Note" from prior to publication with the new release?

 

I don't see a trash can or a delete log anywhere on the edit screen now.

[Keystone]

2 hours ago, crystaloops said:

It's slightly frustrating they took away the edit image date option. Sometimes I don't log the find during the trip until a day or couple days later due to wifi availability or just simply how tire I am. You can change the date of the log, but the image is dated as the date you upload it, and there's no way to change it to the date of the log anymore. 

 

This bug was acknowledged earlier in the thread, and HQ is working to fix it.

[+The A-Team]

8 hours ago, Fields111 said:

I have already used the new page for logging but only with "Founds". Now I saw the explanations of all the changes and I have some doubts.

 

1 - If I want to log a "Found" and report the cache needs maintenance, I deduce I have to choose now the "Owner attention Requested" (OAR) right? What is the result in terms of logs history? It will make two logs, one "Found" and one OAR? I know there's some issues with the dates of OAR logs, but in this case, the "Found" log will have the correct (found) date, right?

 

2 - In case there would be two logs, if the owner deletes the OAR the "Found" log remains in it's place?

 

3 - Related to question 1, if I just want to log a OAR, without a found, I would select the OAR type, but how the system knows it's just a "note" and not a "found"?

 

"Owner attention requested" is just a renamed "Needs maintenance" log. It isn't tied to any other logs, so it can be logged/edited/deleted/whatever without affecting any other logs like finds. Likewise, "Reviewer attention requested" is a renamed "Needs archived" log.

[+The A-Team]

I found another bug. I selected the date for a log first (3 days in the past) and then selected the log type, and it reset the date back to today. By testing, it appears that any change of the log type (either from one type to another, or from blank to a log type) sets the date to today. It should only do this for the OAR or RAR log types. When setting to the other log types, there's no reason for the interface to change the date from what has been selected by the user.

[+GochDdraig]

I do like the new logging set up but my using my iPad I cannot select the log type option i.e found, not found etc as it will not drop down to let me chose.

Anyone else having this problem?

[+CaracalShan]

I really like the new interface, but the resizing of the pictures is not good... I am someone who loves to add pictures to logs, but if you have to manually resize them, I will only add pictures when necessary in the future (i.e. for Virtuals and Earths). It just takes too much time to go through each picture and resize it.

[MZCacheHunter]

On 11/12/2023 at 9:45 AM, MZCacheHunter said:

But wouldn't it be much easier to reactivate the manual date setting in the "edit image" dialog, as was previously the case?

 

9 hours ago, Keystone said:

This bug was acknowledged earlier in the thread, and HQ is working to fix it.

@ari54321@Keystone - is there any update to resolving the bug that images are always uploaded with the current date instead with the correct log date?
Additionally, is it planned to reactivate the manual date setting in the "edit image" dialog, as was previously the case?
 

[+Fields111]

6 hours ago, The A-Team said:

 

"Owner attention requested" is just a renamed "Needs maintenance" log. It isn't tied to any other logs, so it can be logged/edited/deleted/whatever without affecting any other logs like finds. Likewise, "Reviewer attention requested" is a renamed "Needs archived" log.

I understood that, but before that was an option you could add to a normal log (Found, DNF, Note). It means now you must do a separate OAR or RAR. I think many people will not do it. It's a drawback, from a simple and easy feature to something that requires more "work" and time (and not thinking that it might be forgotten).

[+arisoft]

1 hour ago, Fields111 said:

I understood that, but before that was an option you could add to a normal log (Found, DNF, Note). It means now you must do a separate OAR or RAR. I think many people will not do it. It's a drawback, from a simple and easy feature to something that requires more "work" and time (and not thinking that it might be forgotten).

 

This option which requires posting another log to post "a canned need maintenance log" was available only a short time and was not so welcomed as one could think. My opinion about this matter is opposite at almost every aspect you mentioned. Renaming these logs to represent the real meaning of them was a huge improvement.

Edited November 15, 2023 by arisoft

[+thebruce0]

The OAR and RAR logs are heftier logs that, IMO, should require more work to add, as they affect more than merely a visible log history. They have a function and importance beyond recording a visit. As arisoft said, the change to a 'toggle' saying a cache needed attention was fairly recent. That change introduced a number of general headaches only really discovered once it was rolled out. Rolling back to the way it was could be perhaps considered "the lesser of two evils", as it were. But I do think it's better. It may mean fewer OAR logs, but at least if it does result in an OAR, it's a much more intentional OAR.

[+dadoskawina]

On 11/13/2023 at 9:43 PM, baer2006 said:

I reported this bug on 19 October:

 

 

Thanks for this.

I see it was a month ago. @HQ, any estimates when it could be solved?

Edited November 15, 2023 by dadoskawina

[+CCFwasG]

On 11/14/2023 at 12:43 PM, Tundra Wolf said:

I really don't see the point in changing this.  I was very happy with how the "logging flow" was before since I only use the website.  But I understand that sometimes things change.  My major issue with this new "experience" is that my trackables in my inventory are no longer alphabetized.  That makes it difficult to find the trackable I want single out to visit a cache I've done.  I have to sort through them which slows my logging down (more than it already is).  

 

Can there be an option button added (like the log date pin) to change from (seemingly) random sorting of trackable inventory to an alphabetized list?

I might be the only other one who has complained about the new logging re: TBs but I hadn't noticed this change too. I'm really frustrated that TBs I locked (for good reason) are once again showing up and selecting visit all means I now have to uncheck them, whereas it never checked them before! They need to fix the TB inventory back to how it was. (I'm an "ain't broke, don't fix it" person for things like this 100%.)
 

[+Fields111]

12 hours ago, arisoft said:

This option which requires posting another log to post "a canned need maintenance log" was available only a short time and was not so welcomed as one could think. My opinion about this matter is opposite at almost every aspect you mentioned. Renaming these logs to represent the real meaning of them was a huge improvement.

I don't know if I have explained myself well. Until last week the interface to make the logs (from drafts) had a pull down option to select the type of log (Found, DNF and Note). There was another pull down option, in the same page of the log, to report a problem. By selecting one of this and after the log was sent, the system generated a normal log (Found, DNF or Note) on the date chosen and another separate log, on the date the log was sent, reporting the problem. That is, one had to do only one log, with or without reporting a problem with the cache, it was the system that automatically created the "problem" log, if selected. I had used this interface for several months, maybe more than a year ago or even more. Note that this was already a "new" interface, that was in a kind of experimental phase and I have chosen to use it, almost since it was implemented.

 

So, my concern now is not about renaming the logs reporting problems, but about the need to make two separate logs... one with my Found, DNF or Note and another to report a problem with the cache. I don't see this as an advantage to the "players", on the contrary. And for owners and reviewers... they end up receiving the separate logs with the problems, as before, the only difference may be the quantity... fewer problem records, as many people will avoid, or forget to do them.

[+barefootjeff]

39 minutes ago, Fields111 said:

And for owners and reviewers... they end up receiving the separate logs with the problems, as before, the only difference may be the quantity... fewer problem records, as many people will avoid, or forget to do them.

 

As a CO, I'd prefer to get a separate NM describing the problem, with the find or DNF log just about the player's experience along the way. With the "Report a Problem" system, the NM log just said "A player has reported a problem with this cache", not helpful if their other log also didn't say much either. A bit like all those error messages that just say "something went wrong".

 

Edit to add: Are you really reporting problems that often that the extra step of composing a detailed NM log is too much? From 1749 finds and 182 DNFs over nearly 11 years, I've logged 29 NMs (OARs) and 11 NAs (RARs), an average of about 4 NM/NA a year.

Edited November 16, 2023 by barefootjeff

[+The A-Team]

51 minutes ago, Fields111 said:

So, my concern now is not about renaming the logs reporting problems, but about the need to make two separate logs... one with my Found, DNF or Note and another to report a problem with the cache. I don't see this as an advantage to the "players", on the contrary. And for owners and reviewers... they end up receiving the separate logs with the problems, as before, the only difference may be the quantity... fewer problem records, as many people will avoid, or forget to do them.

 

The owners were already receiving separate logs, so nothing changes there. The "Report a problem" was simply a shortcut in the logging interface. On the other end, everything acted the same as it did before that feature existed, and how it works now. There wasn't anything magical about the feature.

 

As has been mentioned by others, the logs that come from the new method are much more meaningful and useful, rather than simply the pre-canned "something is wrong". I see it as a positive change.

[+The A-Team]

On 11/14/2023 at 9:33 PM, The A-Team said:

I found another bug. I selected the date for a log first (3 days in the past) and then selected the log type, and it reset the date back to today. By testing, it appears that any change of the log type (either from one type to another, or from blank to a log type) sets the date to today. It should only do this for the OAR or RAR log types. When setting to the other log types, there's no reason for the interface to change the date from what has been selected by the user.

 

Related to this, the date isn't being forced to the current date for the OAR and RAR log types like it's supposed to. The date is set to the current one after the log is submitted, but the user is misleadingly allowed to change the date in the interface, even though that will ultimately have no effect. The date should be locked to the current date when these log types are selected, similar to how it works when you log an Attended on an Event.

[+Maxipimpf]

Unfortunately a lot of things have been changed for the worse, where is the old log form?

 

- The date of the last log is no longer suggested, you have to set the date permanently manually when logging on

- Poor performance

- The upload of pictures hangs again and again

- If you want to mark all trackables as "visited" when logging, it is slow and time-consuming: display all TBs - mark all as visited - scroll down endlessly to log.

[+Pleu]

18 hours ago, Fields111 said:

 

So, my concern now is not about renaming the logs reporting problems, but about the need to make two separate logs... one with my Found, DNF or Note and another to report a problem with the cache. I don't see this as an advantage to the "players", on the contrary. And for owners and reviewers... they end up receiving the separate logs with the problems, as before, the only difference may be the quantity... fewer problem records, as many people will avoid, or forget to do them.

These were two separate logs for many, many years before the "all in one"-solution that you like was introduced. As a CO I hate the automatic NM-log in the players language so much because it's a standard log that tells me nothing about the issue and half the time it's in a language I don't even understand since some of my caches are in tourist-y locations. Forcing the player to write a OAR-log that actually makes sense is a big improvement. Specially since one of the standard options was often read by newbies as "this makes sense to click anytime I can't find a cache" which actually caused a lot of extra work for COs for no reason.

[Keystone]

2 hours ago, Pleu said:

caused a lot of extra work for COs

 

This was a terrific post, @Pleu - thank you.  I would like to add that the recently retired method also created a lot of extra work for Reviewers.  Imagine sitting down on a Monday morning and looking at a queue of "Needs Archived" logs, most of which contained just the generic language.  The Reviewer needs to click through to each log in that queue, to see if any of the requests were urgent ("the landowner threatened me at gunpoint") and which ones weren't urgent ("I can't find the cache, so it must be missing").  And, when looking at the queue of caches with Low Health Scores, Reviewers needed to read not only the specially flagged "Needs Maintenance" log, but also the "Found It" or "DNF" log that told the real story.  The new logging flow is much easier for Reviewers as well.

[+ChriBli]

2 hours ago, Pleu said:

These were two separate logs for many, many years before the "all in one"-solution that you like was introduced. As a CO I hate the automatic NM-log in the players language so much because it's a standard log that tells me nothing about the issue and half the time it's in a language I don't even understand since some of my caches are in tourist-y locations. Forcing the player to write a OAR-log that actually makes sense is a big improvement. Specially since one of the standard options was often read by newbies as "this makes sense to click anytime I can't find a cache" which actually caused a lot of extra work for COs for no reason.

Hmmm, I wrote a reply without being logged in and it went poof. Not sure if it will be posted after approval. Anyway, the point of it was: How could this force anyone to write OAR/RAR logs that make sense, or to do it in English? What's to stop anyone from leaving that field blank?

[+Pleu]

21 minutes ago, ChriBli said:

Hmmm, I wrote a reply without being logged in and it went poof. Not sure if it will be posted after approval. Anyway, the point of it was: How could this force anyone to write OAR/RAR logs that make sense, or to do it in English? What's to stop anyone from leaving that field blank?

 

If people bother to make a separate OAR/RAR-log they usually bother to include the reason of the log. It worked perfectly fine for years before the automatic versions were introduced.

[+Wulfman_Do]

I found two other BUGs in the new Logging Page , markdown Code formating.

 

1.

 

See my Anouncemt here: https://coord.info/GCAF30T  /   https://coord.info/GL1B43HGQ

In the log window  i wrote  "Tischtennisplatte"   then i marked it with the mouse and clicked on B for bold and the system add the two stars ** for b  in 

"**Tischtennisplatte**"

 

the Logpreview window showed:   "Tischtennisplatte"

 

after hit submit and see the Anouncement Text in the Log seection it showed:

 

"**Tischtennisplatte**" 

 in the formated  Log and not  "Tischtennisplatte"

 

After i hit the  View / Edit Log / Images  Link   https://coord.info/GL1B43HGQ    the View geocache log   page shows the correct formated text.

 

2.

I am confussed,   but Ok i hit  "edit Log"  to change the spelling  and to try an other typing like 

**"Tischtennisplatte"**

 

I have no chance to type anything in the edit Text Field,  i only can hit the submit button and submit an unedit log.

 

 

------

 

to get to the short URL https://coord.info/GL1B43HGQ  ( before it was shown directly in the top right ( like the Listing GC Code Link in Lisitngpages)  now i have to hit share and copy or share with Plattform  X xx xx     The Share function OK, when someone link it, ok, but why not show the  Link ( GL Code )  directly.  ??

 

----

 

Log Submit Button,   Please add a second Botton to the Top. it is very awful  everytime loginn to complete scroll down  past the  preview windows, the TB list, to submit a log.

 

 

----

 

 

 

 

 

[+ChriBli]

20 hours ago, Pleu said:

If people bother to make a separate OAR/RAR-log they usually bother to include the reason of the log. It worked perfectly fine for years before the automatic versions were introduced.

Well illustrates the consequences of changing things that work perfectly fine. But OK, then I understand. The reason for going back to the old way is to stop people who don't want to write something that makes sense in a known language from posting OAR/RAR at all.

[+Pleu]

4 hours ago, ChriBli said:

Well illustrates the consequences of changing things that work perfectly fine. But OK, then I understand. The reason for going back to the old way is to stop people who don't want to write something that makes sense in a known language from posting OAR/RAR at all.

I'm glad that you're consistent with misinterpreting my words across all forums and languages but I'll be leaving this discussion here. Cheers! 

Edited November 18, 2023 by Pleu
Spelling

[+baer2006]

20 hours ago, Wulfman_Do said:

1.

 

See my Anouncemt here: https://coord.info/GCAF30T  /   https://coord.info/GL1B43HGQ

In the log window  i wrote  "Tischtennisplatte"   then i marked it with the mouse and clicked on B for bold and the system add the two stars ** for b  in 

"**Tischtennisplatte**"

 

the Logpreview window showed:   "Tischtennisplatte"

 

after hit submit and see the Anouncement Text in the Log seection it showed:

 

"**Tischtennisplatte**" 

 in the formated  Log and not  "Tischtennisplatte"

 

After i hit the  View / Edit Log / Images  Link   https://coord.info/GL1B43HGQ    the View geocache log   page shows the correct formated text.

I can confirm this bug, and it's quite annoying. The whole point of the preview window is to see, if your formatting really does, what you think it does - especially in situations, where punctuation might get in the way of "markdown" symbols.