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

[+kunarion]

3 hours ago, kamla said:

I don't have any issue with a size limit - but I wonder about the way it's implemented. Instead of enforcing a size limit and forcing the user to resize the image to be below the 5MB limit why don't you resize the image on upload? This can easily be done on the client with a few lines of javascript (keyword canvas) and is what's commonly used.

That'd be the most user-friendly solution as the user can use 'any' input and would allow GC to still enforce its limits.

 

It would be good if The App offered to shrink the selected files, like what happens when you send an email attachment.

 

I don't know if I'd use it all the time, because I crop and adjust my pictures to death, then size them myself.  But maybe once in a while...

 

Edited November 8, 2023 by kunarion

[+arisoft]

1 hour ago, kamla said:

I don't have any issue with a size limit - but I wonder about the way it's implemented

 

It's not a problem for me either, because I've installed a separate camera app for these photos, which can take photos of the appropriate size. I would still see a clear area for improvement in the way images that are too large are handled. At worst, the image just disappears without any explanation.

[+ChriBli]

3 hours ago, kamla said:

I don't have any issue with a size limit - but I wonder about the way it's implemented. Instead of enforcing a size limit and forcing the user to resize the image to be below the 5MB limit why don't you resize the image on upload? This can easily be done on the client with a few lines of javascript (keyword canvas) and is what's commonly used.

That'd be the most user-friendly solution as the user can use 'any' input and would allow GC to still enforce its limits.

To me, this is a no-brainer. If I were to decide how to implement a limit, I would not even consider another approach unless there were any really difficult technical problems with resizing images - and we know there isn't since there is a 640 x 480 px copy made already today. As I mentioned before, until recently I thought that this was all that remained of an uploaded picture, and I was fine (sort of) with that. I suspect the vast majority of cachers never look at the hi-res version of any log photos. Imagine the storage that could be saved! A 640 x 480 picture is maybe 150 kB.

 

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.

[+HCompleto]

Hey all,

 

With this new update, as a CO, how can I encrypt a log that contains spoilers?

I can't seem to find a way to do it nor do I remember the URL to the old logging experience...

 

Thanks for your help

[+baer2006]

10 minutes ago, HCompleto said:

With this new update, as a CO, how can I encrypt a log that contains spoilers?

I can't seem to find a way to do it nor do I remember the URL to the old logging experience...

The functionality has been removed.

 

To quote from the OP:

Quote

We have removed the ability to encrypt logs on cache logs and trackable logs moving forward. Cache logs and trackable logs were not encrypted on the mobile app and very few users used the encryption feature. We have decided to streamline this functionality.

 

And TBH, the functionality didn't make a lot of sense anyway. Whoever was interested in spoilers, could decrypt an encrypted log with very little effort.

[+Eric van Graveheart]

Hi,

I am an active and premium paying geocacher since 2010... sometimes I do much more caches than I am able to log, at least well detailed logs or concerning fotos... so I upload one foto when I am on site (most likely a selfie as a proof of visit) and later - sometimes weeks or month later - due to work or health issues, and as I finished to sort all my travel-fotos and then I edit my log for are more detailed log or upload some more fotos. Until today it was no problem at all: as for instance there is my found-log from this year june 21. and I select some fotos to upload today in november, all these newly uploaded fotos were finely sorted in, into my gallery with the corresponding date, which is e.g. the 23.06.21. - such my gallery keeps consistent, concerning the dates of chronology of my fotos. But now, with the recent change, these newly uploaded fotos are inserted in the gallery with the TODAY date! And I do not see any way to edit this "image detail" - namely the DATE ... Now you can maybe switch fotos horizontally or vertically or some editing features while uploading (very nice for the ones, who are not able to do these things themself befor uploading the fotos), but you can NOT set the CORRECT DATE - a feature which was available before the change all the time for many years. And such - just btw. - because it was not necessary to choose, because when I added a foto now, e.g. in novemeber, for an existing log from june, the fotos where finely insertet to the approporiate date - the possibillity to change the date of the image detail is NOT there anymore...

I am frustrated... changes, to makes things BETTER are fine, thank you for taking care! But changes, taking away well working features simply suck, sorry to say so!

[+JL_HSTRE]

2 hours ago, HCompleto said:

With this new update, as a CO, how can I encrypt a log that contains spoilers?

I can't seem to find a way to do it nor do I remember the URL to the old logging experience...

 

Encrypted logs and encrypted hints are a relic of two decades ago. Apps, many modern GPS units, and programs like GSAK decrypt automatically making the encryption effectively worthless. 

[+niraD]

10 minutes ago, JL_HSTRE said:

 

Encrypted logs and encrypted hints are a relic of two decades ago. Apps, many modern GPS units, and programs like GSAK decrypt automatically making the encryption effectively worthless. 

The point of ROT13 encryption has never been to make it difficult to read something. It has been used widely for decades even though automatic decryption has been available.

 

The point of ROT13 encryption has been to make it easy to avoid reading something, unless you made a conscious decision to decrypt it. That conscious decision can be to decrypt it by hand, but more often has been just to push a button to decrypt it automatically. But reading it requires a conscious decision to read it.

[+Trexzer]

Started my logging tonight and was pleasantly surprised to see I get to start using the new feature.

I think I may have located a bug.

I went to clear out the caches I found today from one of my lists, I logged them as found and confirmed the logs were correctly posted.

When I went to my list the caches are displayed with the "!" icon on the left edge, which normally indicates the cache has a pending log. Strangely my drafts are completely empty and there are no more pending logs. Prior to using the new logging experience found caches were displayed in my lists with a smiley. I don't understand why found caches in lists would now show as having pending logs when they have been posted.

I noted as well that found caches are now shown on my Search map with the pending log symbol and not the found smiley as well. They are correctly shown as smileys on my Browse map.

Images attached to help show the issue

 

Cache was found but doesn't show a found smiley, just a pending log !

Drafts are empty, there are no pending logs

Cache is found, should show a found smiley.

Search map not showing found smiley

 

Yet browse map appears to be the only thing that reflects reality, the cache is correctly shown as found.

 

[+The A-Team]

7 hours ago, Eric van Graveheart said:

...

But now, with the recent change, these newly uploaded fotos are inserted in the gallery with the TODAY date! And I do not see any way to edit this "image detail" - namely the DATE ... ...

 

I can confirm this regression. For a number of years prior to this change, images would inherit the date of the log by default, and you could go in to edit it later to change the date if necessary. It now uses the date of upload, and there's no option to change the date. At the very least, the behaviour of using the log date by default should be restored. It would also be appreciated if a date selector was added so the date can be changed after-the-fact as relevant.

 

I uploaded a number of images over the last few days for caches I found over a week ago, so they have been given the incorrect date. Since I don't know if there will be a way to correct these later, I'll delete them and save them locally for now until the issue is resolved and they can be uploaded with the correct date.

 

I would consider this issue a higher priority to resolve, since every passing day means more images mis-dated.

[+capoaira]

5 hours ago, Trexzer said:

Cache was found but doesn't show a found smiley, just a pending log !

Since the new design of some pages (Map, Bookmark, Search, ...) these actions (Found, NM, Owner maintenance) have a delay.

I wonder that the modern code has a delay and the older not. In Germany, we say "verschlimmbessern" (make something worse, when improve it)

[+terratin]

Must have gotten the update yesterday or today as I just logged a cache and got confused. Was first thinking of a browser mistake as I could not see the opt in banner anymore, and I was still able to log an owner maintenance with a meaningful text. All works I'd say. Photo upload is as fast/slow as ever and the image size straight from my phone works. So glad the automatic owner maintenance texts are gone. They were just totally rubbish, both I suppose as an owner and as a cacher who tries to figure out what's wrong. Thanks a lot GS. Looks good. Only comment: The usual whitespace 😅

[+99celing]

The new format of the logging page is a big improvement. It brings it more in line with the "edit log" page, which has *long* had the same text-formatting tools as well as the feature where the actual appearance of the new log is reflected in an area below the typing section.

 

Meanwhile, I was about to lament a couple things on images. It might be my imagination, but it looked like the jpeg compression of a graphic I uploaded on Monday was really amped up. I know it always has been re-compressed, but this seemed more so than before. Might be my imagination. However, it's a definite downgrade of image descriptions to 125 characters, previously limited to 500 characters. I saw this limitation when I logged some new finds on Monday, and was a little sad.

 

But now I see the release notes, and that the main log itself is upgraded from 4000 characters to a 5000 character limit. Woohoo! New personal record for longest log entry is surely imminent. If that's the tradeoff for image descriptions, that's a win for me.

[+Pontiac_CZ]

As to the image part of a log: I am just writing my first log in the new logging flow. I have entered image name and omitted the description (not needed). After clicking "Update" and getting back to the log form there is still "Add details" under the image. (?)

 

Only if I write anything in the decription it changes to "Edit details".

 

So I think that in my case there should as well be "Edit details" as there IS already something to edit (the image name).

[+ari54321]

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

I can confirm this regression. For a number of years prior to this change, images would inherit the date of the log by default, and you could go in to edit it later to change the date if necessary. It now uses the date of upload, and there's no option to change the date. At the very least, the behaviour of using the log date by default should be restored. It would also be appreciated if a date selector was added so the date can be changed after-the-fact as relevant.

 

 

On 11/8/2023 at 12:56 PM, Eric van Graveheart said:

But now, with the recent change, these newly uploaded fotos are inserted in the gallery with the TODAY date! And I do not see any way to edit this "image detail" - namely the DATE ...

Thank you for reporting this issue of incorrect gallery dates. It appears this issue only affects images uploaded from the view log page. For now, there is a workaround: if you upload image(s) on the edit log page (open your log, select "Edit log", then drag and drop or select photos to upload), these images will have the correct date (log date, not today's date).

 

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. We are looking into a fix for the image upload dates. 

Edited November 10, 2023 by ari54321
Updating

[+Stachey Pete]

Regarding the automated emails when a log or image is deleted, was this not already the case previously? Or am I thinking of just for deleting an image? I do like that if a log is deleted that the log author is notified.

[+Max and 99]

48 minutes ago, Stachey Pete said:

Regarding the automated emails when a log or image is deleted, was this not already the case previously? Or am I thinking of just for deleting an image? I do like that if a log is deleted that the log author is notified.

If I remember correctly, email notifications were sent when it happened, but the CO was not required to provide a reason. Now they are.

[+99celing]

1 hour ago, ari54321 said:

Thank you for reporting this issue of incorrect gallery dates. It appears this issue only affects images uploaded from the view log page. For now, there is a workaround: if you upload image(s) on the edit log page (open your log, select "Edit log", then drag and drop or select photos to upload), these images will have the correct date (log date, not today's date).

 

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. We are looking into a fix for the upload button on the view log page. 

 

I'm glad to hear this is a bug and not a deliberate change. Thanks!

 

I note that the workaround described doesn't seem to work for me. I still get the same issue uploading an image, whether via the "view log" page or via the "edit log" page. Either way, my upload tests right now are bringing the images in with today's date rather than the log entry's date. More crucially, on the "edit image details" interface, the ability to edit (or even see) the date of the image has been removed. Now, only can edit the name and description (and rotate/flip the image, which is a nice enough feature).

 

I'll look forward to when this gallery-date bug is fixed, and will just hold off on uploading any new images for the moment. Not in a huge hurry.

Edited November 9, 2023 by 99celing
removing extra carriage returns

[+barefootjeff]

1 hour ago, Max and 99 said:

If I remember correctly, email notifications were sent when it happened, but the CO was not required to provide a reason. Now they are.

 

Yes, but also the CO couldn't provide a reason even if they wanted to. This is a long overdue improvement!

[+Trexzer]

17 hours ago, capoaira said:

Since the new design of some pages (Map, Bookmark, Search, ...) these actions (Found, NM, Owner maintenance) have a delay.

I wonder that the modern code has a delay and the older not. In Germany, we say "verschlimmbessern" (make something worse, when improve it)

Do we know how long this delay is? I'm noting 24+ hours later that the icon hasn't change to a found smiley?

[+The A-Team]

6 hours ago, ari54321 said:

Thank you for reporting this issue of incorrect gallery dates. It appears this issue only affects images uploaded from the view log page. For now, there is a workaround: if you upload image(s) on the edit log page (open your log, select "Edit log", then drag and drop or select photos to upload), these images will have the correct date (log date, not today's date).

 

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. We are looking into a fix for the upload button on the view log page. 

 

Thanks for the suggestion of a workaround, but I get the same result as 99celing, in that it still uses the current date rather than the log date. It looks like both upload methods have the same issue.

 

As long as I know it will be fixed, I'm fine to wait.

[+Eric van Graveheart]

Thanks @ ari54321 for taking care,

but I am sorry to confirm, that the workaround via the edit log page does also NOT work for me, I get the same result as 99celing and The A-Team already reported, it still uses the current date rather than the log date. But I'm am also glad to hear this is a bug and not a deliberate change. So I will wait for a solution - I still have to log some 40 Earthcaches from last holidays with some fotos from beautiful locations... 

[+nanertak]

On 11/3/2023 at 11:38 PM, Numanoid said:

Unfortunately I already have to endure the new logging "experience". Can we please have the "Opt out" button back?

Same here, I would also like to use the previous ui.

[+terratin]

Ok, so yesterday I was able to upload a photo, and today I'm not. Not good.

[+ari54321]

Thank you @Eric van Graveheart @99celing and @The A-Team for letting us know. Indeed that workaround appears not to work; I have updated my previous post. The team is looking into a fix for this issue. Thank you for your patience! 

[+seedcorp]

Accordig to

 Date is sticking now, but the type of log does not. So the problem continues. I dont undersnad on what you were working for 6 months, see how long is that thred acitve. And no change to be working... Please, fix it!!!! Make stick date AND type of log, defaultly on fount it.

 

[+capoaira]

7 minutes ago, seedcorp said:

Make stick date AND type of log, defaultly on fount it.

Please not. I'm happy that mistakes with logtypes are now prevented again. 

[MZCacheHunter]

12 hours ago, ari54321 said:

The team is looking into a fix for this issue. Thank you for your patience! 

@ari54321 - In fact, I also noticed this error with the wrong date for the pictures when logging with the new ui and I looked here in the blog to report it. Glad to see that you're already aware of it and thank you for working on fixing this bug.

In addition, it used to be possible to change the date of an image yourself. I hope that this feature will also be made available again in the "edit picture" dialogue, right?

Edited November 11, 2023 by MZCacheHunter

[+barefootjeff]

58 minutes ago, seedcorp said:

type of log, defaultly on fount it

 

Please no. There were way too many intended DNFs and WNs being posted as Finds because the logger forgot to change the default type. I got caught out a few times when intending to post a note on a cache I was planning to attempt, only to be focused on what I was writing and realising a second after posting it that I forgot to change the log type from the default.

[+ChriBli]

1 hour ago, barefootjeff said:

 

Please no. There were way too many intended DNFs and WNs being posted as Finds because the logger forgot to change the default type. I got caught out a few times when intending to post a note on a cache I was planning to attempt, only to be focused on what I was writing and realising a second after posting it that I forgot to change the log type from the default.

I've seen people asking for this, but the reason is usually to prevent newbies from posting found when they didn't find. As if that would matter much. Personally I log at least twenty found between each DNF or WN and it is of course tedious to have to select it for every log. Forgetting to change to DNF has happened to me too, as has choosing the wrong date, but if you realize your mistake you just have to correct it.

 

But all of these little issues pale in comparison to the fact that there is no reasonable way to upload log photos as taken with a modern phone or camera anymore, for the first time in two decades. That is a showstopper.

[+Geokid12]

I also think having the ability to pin log type could be helpful (or at least a setting toggle to default to found it, that was one thing I liked about the new one vs the old one).

[+Animatronio]

Hello,

I am uploading pictures to some of my founded geocaches (new ones and also old ones). And in the new logging window there is no possibility to change a date, when the pictures was taken. So all pictures are with date when I uploaded them. In my gallery is a big mess. All pictures have a same date, some of them are taken in summer and some of them are taken in winter. It is possible to add a way how to change a date of uploaded pictures? Or it is possible to make a change, so the pictures will have automaticaly the same date as log where they are uploaded?

 

Thank you

Animatronio

[+DaddyKool]

In my opinion there is an urgent need to address and fix the issue of image sizing. Any necessary resizing should be part of the automated uploading process and not be additional tedious steps that each and every user should take before uploading images. When geocachers compose and design geocache descriptions uploaded images are automatically resized according to the needs and and specifications of the website. Resizing has also been done previously for log images, at least for the ones that opted out from the previous change of the logging process. So, please, fix this with a bit of code. Thanks in advance! 

[+capoaira]

I usually use Drafts for logging, so the logtype is mostly correct. So when I log directly from the logform, than I log a note. For example, if I don't have time for an event. If I log this on the same day as the event, I often forgot to change the log type. Yes I can change that when I recognise the mistake. But that was more difficult when I logged accidentally an attend instead of a note for an event in which my TB was lost. I got a Region Souvenir because I haven't visit the Region before. So I had to write the Help Center to remove the it. 

 

I'm caching since 9 years so it is not only to prevent newbies from posting the wrong log. Also cacher like me, who usually use Drafts where the logtype is set correctly. 

 

A simple workaround for all cacher who's annoyed from choosing the logtype: Use Drafts. You can use it from every app and also from Garmins.

[+seedcorp]

16 hours ago, barefootjeff said:

 

Please no. There were way too many intended DNFs and WNs being posted as Finds because the logger forgot to change the default type. I got caught out a few times when intending to post a note on a cache I was planning to attempt, only to be focused on what I was writing and realising a second after posting it that I forgot to change the log type from the default.

 

If i wrote it maybe badly, so:  I will like to have an pin to set if i want to remember type of log. same as now by the date. Ok?

[+Boomshanka]

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

[+mikkopit]

45 minutes ago, 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

 

I second this one !! I really would like to have this list to see what I have logged recently and its a good tool to check if you have missed any logs while caching with friends by looking at their recent finds.

[+ChriBli]

54 minutes ago, 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

It's not called "binned" anymore. It's called "streamlined".

[+CoolR]

I agree with everyone requesting automatic resizing of images to fit the new requirements. For me it is by far too tedious to resize the images manually before every upload, and if this problem is not fixed, I (and probably many others as well) will stop uploading pictures at all, which would definitely not make the game as fun as it was. Please solve this! Meanwhile I will keep my images for myself.

Edited November 13, 2023 by CoolR

[+kunarion]

42 minutes ago, CoolR said:

I agree with everyone requesting automatic resizing of images to fit the new requirements. For me it is by far too tedious to resize the images manually before every upgrade, and if this problem is not fixed, I (and probably many others as well) will stop uploading pictures at all, which would definitely not make the game as fun as it was. Please solve this!

 

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.

 

Edited November 11, 2023 by kunarion

[+monsterbox]

On 11/5/2023 at 2:43 AM, ChriBli said:

After painstakingly selecting, installing and configuring a parallel browser of more recent version, just to be able to log my geocaches, I notice the new max limit for number of images per log (20). I am predictably disappointed.

 

Simply add as many notes as you need. That's an easy to overcome limitation, isn't it?

[+monsterbox]

On 11/7/2023 at 6:31 PM, Keystone said:

 

This isn't a bug, and carries forward existing functionality in the old logging flow.  Defaulting the date to today prevents abuse (backdating a key action like Owner Attention Needed, Owner Maintenance, Reviewer Attention Requested, Disable, Enable and Archive logs).

 

Sorry, for me it's definitely a bug, not a feature :-( It's a total pain in the *** and just led to the need to edit a few logs as I just mentioned it at about the 3rd log I wrote. Plus, it is changing back to today, when I first change the date and then the log type.

Please bring it back to what it was before. It's so much easier to stay with the last date when it comes to multiple logs on the website.

[+ChriBli]

11 minutes ago, monsterbox said:

 

Simply add as many notes as you need. That's an easy to overcome limitation, isn't it?

So what is the limitation good for, then?

[Keystone]

9 minutes ago, monsterbox said:

Please bring it back to what it was before.

As I said in my post that you quoted, the functionality hasn't changed.  "Status" logs have always defaulted to the current date (Owner Attention Requested, Reviewer Attention Requested, Owner Maintenance, Enable Listing, Disable Listing, Archive Listing and Retract Listing).

[+monsterbox]

1 minute ago, Keystone said:

As I said in my post that you quoted, the functionality hasn't changed.  "Status" logs have always defaulted to the current date (Owner Attention Requested, Reviewer Attention Requested, Owner Maintenance, Enable Listing, Disable Listing, Archive Listing and Retract Listing).

 

Ok, I never used the "new" log style as I totally disliked it. But at least now it also doesn't get stuck to my last date when it comes to find/atteneded/DNF logs and sorry, that simply isn't cool at all :-(

I don't care much about the status logs, but I just logged some stuff from yesterday and needed to check the date for every single log. Sometimes even twice, as you need to first choose the type, THEN the date...

[Keystone]

10 minutes ago, monsterbox said:

I just logged some stuff from yesterday and needed to check the date for every single log. Sometimes even twice, as you need to first choose the type, THEN the date...

 

Please re-read the instructions in the Opening Post on how to "pin" the date to a date of your choice.

[+monsterbox]

11 minutes ago, Keystone said:

 

Please re-read the instructions in the Opening Post on how to "pin" the date to a date of your choice.

 

Ok, I see. Too late already :-( RTFM error on my side, sorry that for!

[+ChriBli]

7 hours ago, 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

I see now that this is the link that you could use to see the full find history, including archived, for yourself or someone else. Something akin to a basic human right and necessary for many puzzles, if nothing else. This link was thrown around to quench most of the critcism of the decision to limit this history to 1,000 finds (the reason for which was never revealed) - look, you can still see your finds using this link. Well, now you can't.

[+Team Libra]

9 hours ago, 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

I wholeheartedly agree!  Please bring this page view back.  It's a handy way to compare my find date to the last found date.  I really like to see this information at a glance so I can check for other cachers' recent experiences on my finds.  I can't see that information in the newer finds results list and am very disappointed this view has been done away with.

[+tomturtle]

5 hours ago, ChriBli said:

I see now that this is the link that you could use to see the full find history, including archived, for yourself or someone else. Something akin to a basic human right and necessary for many puzzles, if nothing else. This link was thrown around to quench most of the critcism of the decision to limit this history to 1,000 finds (the reason for which was never revealed) - look, you can still see your finds using this link. Well, now you can't.

It would be nice if this page could be reinstated. It is one that I find very useful.  Also in general, it would be better to make all the transactions unlimited as far as data is concerned.  We want more data, not less.  Less is a step in the wrong direction.