nykkole

This will affect content hidden in images for puzzles going forward. Any existing puzzles will not be impacted and COs will continue to be able to edit them as necessary without running into issues.

For the question about bonus caches - Keystone, Blue Rajah, and Frau Potter have already said this, and quoted the Help Center, but in case anyone would like to read more, here's the link to the bonus cache article. Any bonus cache that is not a Mystery Cache does not follow the current guidelines. According to these guidelines, the new attribute is only available for Mystery Caches.

Some attributes don't count towards the 15 attribute limit. e.g. "Wheelchair accessible", "Needs maintenance", or "Geocaching.com solution checker". So, if a Mystery Cache owner adds 15 attributes manually, then sets the T rating to 1 and adds the solution checker - the cache will have 17 attributes. If the CO then doesn't maintain their cache, they might get an 18th attribute for "Needs maintenance" ;P

Today, we deployed a fix to award the missing Memory Lane points for Adventure Lab logs on June 1. If you've logged Adventure Labs on June 1 after the Memory Lane promo started but did not receive the points towards Memory Lane, they should now be awarded on your Memory Lane gameboard.

Thanks for reporting this. We have discovered that Adventure Lab logs that were logged before noon local time today did not count towards the Memory Lane score. We will look into a fix and award those missing points retroactively!

Today, we have updated the cookie scanning and blocking service to no longer run on the description of Mystery Cache pages and profile pages. We have updated our cookie consent tool and Privacy Policy to reflect this change.

The reason the image is not updating is because it's being pulled from the browser cache instead of retrieving the updated version from the server. The image proxy will preserve the cache-control headers from the source image. If there is no cache-control header specified at all, the image proxy adds one. The way to fix this would be for the hosting server to send a "Cache-Control: no-cache" response header.

It looks like this reply was due to a misunderstanding. Images that are hosted on 3rd party websites are all run through the image proxy server. This can result in unexpected behavior that leads to issues with the image being displayed. I will look into the content-type header to see if this is something that can be addressed.

Sur ce site: https://www.geocaching.com/account/documents/cookies vous pouvez refuser tous les cookies (à l'exception des cookies nécessaires). Vous pouvez plus en discuter dans le forum lié à cette mise à jour:

I have checked with the engineers and we are actually not caching images at all. What might be happening is that you expect a different image depending on the circumstances (e.g. language in client's browser). But since we are accessing the image via the proxy server without revealing any information about the user who is viewing the image on Geocaching.com, the hosting server will receive the same information from the proxy server every time the image is accessed.

@funkymunkyzone Can you let us know the GC codes of the caches that have broken images (either in this forum thread, or in an email to contact@geocaching.com )? This will allow us to investigate what the issue might be.

Thanks for reporting this. We will investigate what the cause is and see if we can fix it.

This was related the the proxy image server release. We have fixed the reason that was causing the images not to show and they should now display as expected.

Thank you for posting reports about broken images due to this release. We have a couple of updates: Fixed issues We have been working on identifying and fixing the bugs that have been reported here. The following updates have been made, which provide a fix for the majority of the reported issues. Size of images - we increased the possible size of images that go through the proxy server Google Drive and Dropbox support - images hosted on Google Drive and Dropbox should now display as expected User agent - accessing images via the proxy server can result in unexpected responses from the hosting server. Of the reported issues, we have fixed those that were connected to this behavior. Workarounds for issue we can’t fix For some issues we will not be able to provide a solution. In such cases, consider either Providing a text hyperlink to the website that hosts your image. This way other geocachers can choose to visit the external website to see the image. Hosting your image on Geocaching.com, Google Drive, or Dropbox. Why This change was necessary to comply with changes in privacy law in the U.S. (California) and Europe. We do not plan to roll this update back again. However, we are actively working on identifying which of the surfacing issues we can fix. If you are aware of any other broken images that might be connected to this release, please let us know in this thread which page (e.g. GC code) is affected.

Thanks for reporting this issue. We have found the bug and released a fix. You should now be able to upload this picture as a background image without any further issues.

Thanks for all the posts identifying bugs and concerns. Please note that this thread is about the release of the changes to the background image. If you have any questions, concerns or bug reports concerning images in the cache description, please post in this thread: Release Notes (Website: Reverse Image proxy). Thank you!

Thank you for reporting the broken images in the cache description. This is not related to the background image feature, but rather to another project to improve security. As some of you have noted, the images were routed through a proxy server to strip them of 3rd party cookies. The expected behavior was for all images to continue to be displayed. We have rolled this update back so that we can investigate the cause for the unintended broken images.

Thanks for all the questions. We appreciate the desire to know more about the reasons behind this release. Here are the main ones: Security - Allowing a background image to be inserted via an external URL can result (intentionally or not) in third-party cookies on the computers of those who view the cache page. This is a security risk that we were able to close with this release for all caches going forward. Easier for non tech savvy - As some mentioned in this thread, not every player knows how to or has a server to store their own images. This type of image uploading functionality is standard on many websites and cache owners have asked us for this functionality. Issues with broken images in the past - When an image hosting service becomes unavailable, cache owners don’t always notice this. This causes the image to disappear and some puzzles become unsolvable. While we wanted to ensure that these three points are addressed going forward, we also wanted to make sure that existing cache pages are not affected. If you have a existing puzzle that relies on the background image, the puzzle is not affected by the changes. The behavior for caches with existing background image is that the edit page will show a thumbnail of the image. Behind the scenes, this is still the URL you entered. You can make changes to your cache page without impacting the background image. But if you delete the existing background image, then the new upload functionality is your only option for a new background image.

We have deployed a fix. The buttons for the numbered and bullet point lists should now work as expected.

Thank you for reporting this. I can reproduce the bug of the list icons. The heading 4 is working as expected for me, though. Can you give more details of the behavior you see and what you would expect instead?

It looks like you had issues with your page a couple of hours before the release of the editor. It might be possible that some of the HTML you are using in the cache description is causing this unexpected behavior. Do you still have this issue?

A fix went out today that resolves the DST issue when adding an event to the calendar from a cache page. Using the Add to Calendar function will now create an event in the correct time slot on the calendar.

Thank you for reporting this. Our engineers are aware of the issue and are working on a fix.

Thanks for reporting this. We are aware of the issue and will work on a fix. Meanwhile, as a workaround, the CO can go to the edit page and click save - this will fix the date display.

We have released a fix for GPX files from PQs: GPX files downloaded from PQs no longer show the incorrect time (and date) for Event Caches. Instead they are showing the time entered by the CO without a specified time zone.