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

[+The A-Team]

I just went back to check on the status of the other outstanding issues I had reported, to see if they had also been quietly fixed. It seems that there has been some progress that hasn't been reported. If anyone else has reported issues with this release, you might want to test to see if they have been resolved.

 

On 11/6/2023 at 10:04 PM, The A-Team said:

• After I drag in an image and add a caption, hitting Enter on my keyboard activates the "Rotate 90 right" button. This seems like unintended behaviour, or at least isn't what users would expect. The logical expectation for hitting Enter would be to either submit the image, or do nothing.
• After uploading an image to an existing log, it used to be that the just-uploaded image would be shown. Now, it takes you to the log view with the first image displayed. It might make more sense to display the just-uploaded image, so the uploader can confirm that things look right.

There has been no change with these.

 

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.

This has been fixed, and works more logically now.

 

On 11/15/2023 at 9:50 PM, The A-Team said:

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.

This hasn't been fixed yet. The user is still able to select a different date for OAR and RAR logs (and I noticed also Disable/Archive), even though that selection will just be ignored when the log is submitted.

 

On 11/23/2023 at 8:03 PM, The A-Team said:

...

In an attempt to work around the error above, I attempted something that Viajero Perdido mentioned: rotating the image. By doing this, it did allow the images to upload. However, I discovered that the rotate and flip functions are misleading. In the upload interface, you can click these buttons multiple times and they progressively rotate or flip the preview image, implying that you can flip/unflip or rotate 180/270/360. However, once you upload, the resulting image reflects a single action of the rotate/flip buttons. For example, if you click the "Rotate 90" button twice to rotate 180 degrees, the result will only be rotated 90 degrees and not match the preview that had been displayed. Likewise, if you click the "Flip horizontal" button twice to flip and then flip back, the result will be flipped once horizontally.

 

These functions should either be updated to perform the action multiple times according to what's being shown to the user in the preview, or be changed to toggles to indicate their "single-action" function (in which case the preview image code would also need to be updated to reflect this).

This has been fixed. Each click of these buttons now applies the action progressively, so multiple rotations can be applied, flips can be unflipped, etc.

[+Deepdiggingmole]

I think this all looks good and should make for a better logging experience - however is there yet a facility added or consideration given to one added where a dropdown window appears for new cachers who are reminded or are asked if they have signed the logsheet/logbook prior to logging the 'found' online whether via the app or from the website 

[+CynicalHipster]

Apologies if this has already been covered (I didn't see it in the thread, but I may have missed it), but on a trackable's page, whenever you click on a cache linked from a TB log, it redirects to the page for GC0, which obviously doesn't exist.

 

Getting this using Firefox on Windows 10.

[+2Abendsegler]

Loading a photo on the edit log page immediately updates the log without me pressing the Update button.
 
I wanted to add log text and photos to a fieldlog. I have loaded a photo. Afterwards I realized it was the wrong photo. That's why I stopped processing and went back to the view log page to start again. But the photo was already there on the view log page.
 
I would expect that a loaded image is initially only available locally on the edit log page, and that I can still rotate the image and add a name and description. I would expect to be able to repeat this with multiple images and to be able to change the logtext. All without having to update the log. The log should only be updated when I press the update button. Exactly, just like adding a log.
 
Reproduce:

• Calling the view log page for a log.
• Press the “Edit log” button.
• Load an image on the edit log page.
• DO NOT press the update button. Instead, click on the “View log” link above.
• The image is available on the view log page.

 

 

Please excuse me if the topic has already been covered. I didn't keep track of all the error messages from the past few weeks, there were just too many.

[+barefootjeff]

One of the issues that was mentioned early on was not being able to edit a Reviewer Note on an unpublished and unsubmitted cache, with some speculation that this might have been intentional. I'm wondering if that's still the case, as I'm currently putting together a reasonably involved puzzle cache that has a lot of information to go into my Reviewer Note that I can do now while it's fresh in my mind, but the final stuff like photos of the cache placement I won't have until I go out tomorrow to place the cache. As a precaution in case I still can't edit, I'm writing my draft note in Word so I can copy and paste tomorrow, but that's a little cumbersome.

[+baer2006]

14 hours ago, barefootjeff said:

One of the issues that was mentioned early on was not being able to edit a Reviewer Note on an unpublished and unsubmitted cache, with some speculation that this might have been intentional. I'm wondering if that's still the case, as I'm currently putting together a reasonably involved puzzle cache that has a lot of information to go into my Reviewer Note that I can do now while it's fresh in my mind, but the final stuff like photos of the cache placement I won't have until I go out tomorrow to place the cache. As a precaution in case I still can't edit, I'm writing my draft note in Word so I can copy and paste tomorrow, but that's a little cumbersome.

I just tested it: The issue has not been fixed so far .

[+Viajero Perdido]

On 11/21/2023 at 10:54 AM, Viajero Perdido said:

What on earth is wrong with this image, that it won't upload to a cache log?  It's only 66 kB.

 

This is still a problem, today with another image, another trimmed screenshot from my phone.

 

I worked around it by importing to GIMP, then exporting.  This report from GIMP might be a clue:

 

Now I leave this to the experts, as this is right over my head. 

 

Edited December 28, 2023 by Viajero Perdido

[+Viajero Perdido]

One thing that hasn't changed, and has been a minor irritant for years:

 

On the cache page, when you click "View / Edit Log / Images", it opens the logging page in a new tab.  Why is that necessary?  If you're a perfectionist with your logs, and go through a few cycles of view-proofread-edit-repeat, you end up with a handful of extra tabs you need to close.  (The obvious answer of proofread on this page, not that page is not a very good answer.)  Thank you.

 

Minor x years x millions adds up.

[+CCFwasG]

On 12/27/2023 at 10:03 PM, barefootjeff said:

One of the issues that was mentioned early on was not being able to edit a Reviewer Note on an unpublished and unsubmitted cache, with some speculation that this might have been intentional. I'm wondering if that's still the case, as I'm currently putting together a reasonably involved puzzle cache that has a lot of information to go into my Reviewer Note that I can do now while it's fresh in my mind, but the final stuff like photos of the cache placement I won't have until I go out tomorrow to place the cache. As a precaution in case I still can't edit, I'm writing my draft note in Word so I can copy and paste tomorrow, but that's a little cumbersome.

FWIW you can always add another reviewer note, that's what I just did. Better than nothing?

[+CCFwasG]

On 12/16/2023 at 12:42 PM, CynicalHipster said:

Apologies if this has already been covered (I didn't see it in the thread, but I may have missed it), but on a trackable's page, whenever you click on a cache linked from a TB log, it redirects to the page for GC0, which obviously doesn't exist.

 

Getting this using Firefox on Windows 10.

 

Known issue, this from my other thread:

 

[+Viajero Perdido]

In addition to the Reviewer Note, you also can't edit the text of an Update Coordinates log.

 

Also...  If you're impatient when the write-log page comes up, and click "Select option" before it's ready (eg still loading its javascript for the first time today), you can click it all you want, and/or wait a long time, and it'll never become enabled.  Clicking elsewhere, eg the text field, then back again, un-breaks this.  (Current Firefox on Linux, with NoScript enabled but with exceptions that enable gc.com to work smoothly elsewhere.)

 

Edited January 2 by Viajero Perdido
++info;

[+Viajero Perdido]

This particular cache log page renders quite oddly.  Most of the text is off-screen to the left, and you can't scroll to it.  Also, the last bit is in a monospace font, which seems odd too.

 

https://www.geocaching.com/live/log/GLMBMHWJ

 

This is on my Linux Mint PC with current Firefox, my big Android tablet with current Brave (portrait, landscape), but works normally on my Android phone also with Brave.  Other logs by myself or others act normally.

 

I have ginormous horizontal resolution on the first two devices; maybe that's a clue.  I don't use all that width on the PC, and the tablet is set for desktop mode (another clue?) because I dislike mobile layout on big screens.

 

Edited January 7 by Viajero Perdido
info += 2;

[+MartyBartfast]

3 hours ago, Viajero Perdido said:

This particular cache log page renders quite oddly.  Most of the text is off-screen to the left, and you can't scroll to it.  Also, the last bit is in a monospace font, which seems odd too.

It renders OK for me at normal zoom levels, but if I zoom in on the page then the text disappears off the left and as you say I can't scroll to it, but can scroll to the right.
I also see the monospaced text which I had assumed was chosen when the log was written but as it's your log I guess not.

Firefox on Fedora Linux.

[+janrei_]

In the linked log, there are three consecutive tildes before the last paragraph. They are considered the beginning of a code block which usually are rendered in a monospace font and without line breaks. Code blocks might not be really useful in geocaching logs and they are not mentioned in the formatting guide, but the Markdown processor understands them.

 

If you want to fix this yourself, you can edit the log and use a different separator (an easy fix would be to remove a tilde).

[+Viajero Perdido]

Three tildes are how I visually separate sections.  Now three tildes have magic?

 

This isn't about fixing the log.  It's a bug report.  The page layout is broken.

 

PS, the "How to format" popup makes no mention of tildes.  Thus, I did nothing wrong.

 

PPS, while on that subject, I just noticed the clown code changed from [:o)] to [:O)], now using capital O, breaking all old logs using the original, including 259 of mine.  Not the first time old logs have gotten uglier without being touched.  Bit decay.

 

There:  three bug reports in one.  Do with them what you will.

 

Edited January 7 by Viajero Perdido
Fine-tuning for clarity

[Keystone]

Questions and comments should be limited to the subject of the current Release Notes.  Refer to the opening post for scope guidance.

[+thebruce0]

I'm wondering if there has been ANY movement on this:

 

On 11/22/2023 at 1:26 PM, thebruce0 said:

  

There is another annoying formatting bug with the new log page.

The preview indicates that "- line text here" is being converted to a bullet list, but that is not in the instructions.  I saved a log, and in the cache listing log view, it appears as expected. But when viewing the log entry directly it formats like the 'new' preview as a bullet item. That's not nice. =/

 

Here's how it looks.

What I'd like, as I've been doing for my logs is this format:

Quote

- This is a line of text

This is a second line of text

 

However while the same template text in the log is displaying correctly in the listing logs, the log view and preview block display the above as this:

Quote

• This is a line of text This is a second line of text

Yes, even losing the line break.

 

Hyphen shouldn't convert to a bullet. And I'm guessing that conversion to a bullet list may be the cause of the loss of the line break.

Would love to have this formatting return to what it was.

 

I still see the visual preview and format from the new flow as different than the display of logs on the cache listing, and in 3rd party apps. Why is the "updated" markdown (which isn't backwards compatible) still inconsistent with the prior logging display?  And the actual markdown functionality not in line with the help/instructions about what code does what?

 

There seems to be a lot of editing of live display features that aren't applied universally, likely due to fragmented codebases or different development teams, but mainly in markdown for log display.  It can lead to very annoying discrepancies. It could lead to people just not using any formatting code just to avoid these differences (although in many cases standard text characters lead to unexpected visuals as well) - typically one might expect to see a toggle for "use markdown" or "plain text" (just like cache descriptions with HTML or not)

 

 

Could that be added as an option? Whether to format log text with markdown formatting or just leave it untouched just as we type and want it displayed?

[+Forest-Ghost]

Bug report - everytime I try and post a write note on my newly adopted cache GC8EC9V I get the following error: Log failed to post

Something went wrong. Stay on this page to keep your log text and try to post it later.

[+CaracalShan]

I have the same when trying to log a 'Found it': I often get an error saying something went wrong. When I refresh the page and try again, it works again.

[+Forest-Ghost]

@ari54321 the logging flow is still broken. Write note, found it, reviewer note, and maintenance log all result in the same error I posted above. Its been three months - you guys need to fix this. I am using google chrome with an windows computer and safari with iphone 15--the bug displays on both devices. 

Edited February 11 by Forest-Ghost

[Oceansazul]

We have been working to resolve the issues reported in this channel. Thank you to all who have reported and are passionate about supporting the logging flow, we appreciate your reports. Many of the reported issues have been resolved at this point.    

 

 

@Forest-Ghost, in your previous post, the error was related to the 'write note' log type on your adopted cache. It seems the scope of your logging issues has increased since that post to include multiple log types, including Found it logs. Is that accurate? This indicates the issues you are seeing are not only on caches you own or have adopted but, I would like to verify that. Can you provide any additional repro steps to help us isolate this issue: Is it only the adopted cache where logging isn't working, or is it all caches? Do any log types work for you or do all of them fail? Is this intermittent or consistent? Is this on the initial post (only) or on editing a log? Thanks for sharing your devices. We aren't receiving other reports about this error so any additional info you can share is helpful. 

[+Forest-Ghost]

24 minutes ago, Oceansazul said:

 

 

 

@Forest-Ghost, in your previous post, the error was related to the 'write note' log type on your adopted cache. It seems the scope of your logging issues has increased since that post to include multiple log types, including Found it logs. Is that accurate? This indicates the issues you are seeing are not only on caches you own or have adopted but, I would like to verify that. Can you provide any additional repro steps to help us isolate this issue: Is it only the adopted cache where logging isn't working, or is it all caches? Do any log types work for you or do all of them fail? Is this intermittent or consistent? Is this on the initial post (only) or on editing a log? Thanks for sharing your devices. We aren't receiving other reports about this error so any additional info you can share is helpful. 

 

Hi Oceansazul, thanks for your response and for looking into the problem. The issue is not consistent unfortunately. The issue has been on different caches some owned by me and some owned by other players. For the last week of January I found caches almost every day and every time I tried to post a found it log from my computer I got an error message which I could only fix by copying the link to the cache page and then re-opening it.

 

Saturday night 2/10 I posted a reviewer note to the cache page of my un-published cache and got the error the first time I published a reviewer note. Then I did not get the error on subsequent reviewer notes - I may have reopened the page here as well. 

 

Today I posted a DNF and Write Note to GC7ZCX9 and got the error message. I closed the link to the cache page, re-opened it and now the error is gone - I can now post any type of log without problems. All these examples are from windows/google chrome. Separately, I was having the same error log from when I opened a cache in the safari browser on my phone to post a maintenance log to a geocache. I tried doing this today and was able to log from safari without issues. 

 

To clarify- it seems the issue is always resolved (on my caches and others) whenever I reload the page so there is something that is preventing the log from posting correctly when I goto submit the log the first time. Two other cachers have reported this same issue to me within the past couple weeks.

Edited February 12 by Forest-Ghost

[Oceansazul]

Thanks for those details @Forest-Ghost, we are investigating. 

[+The A-Team]

Occasionally, when trying to add a photo to a log (after it has been submitted), the upload will just hang. The spinning indicator will just keep going forever (I've left it for as long as 10 minutes before). I can click the X to seemingly cancel the upload, but reloading the log page will show that the image successfully uploaded, albeit without the "Image name" I had entered. I'll then have to edit it to add the Image name again.

 

This may be a tricky one to troubleshoot, because it's intermittent. I haven't noticed any patterns for which ones work or fail. If I had to estimate, I'm seeing it roughly once every 20 images. Just now, I had a failure as per above, but then accidentally uploaded the same image again. It worked fine the second time, so it doesn't seem to be an issue with the files themselves. I'm using Firefox 122.01 on Win 11.