goodgollymsmolly

Our account has been on Annual Premium Membership that renews annually via Paypal since 2003. Each year, our membership has renewed without any problems -- until now. Yesterday, we received an email from Paypal stating that our "subscription to Groundspeak Premium Member failed because you do not currently have a back-up funding source for your instant transfer payment." This has never been an issue in the past. There are sufficient funds in the account. Also, we do have an up-to-date credit card associated with our Paypal account, but according to the Paypal email, my only option is to "choose a credit card or eCheck funding source." Simply replacing one funding source with another does not seem to address the issue of having a backk-up funding source. More importantly, we do not understand why we can no longer use 'Direct Debit' as our funding source. Nonetheless, we have changed the funding source to a credit card. The subscription says the next attempt will be August 3rd. Is our only choice to wait until then and hope that the change we've made to the subscription will be successful? Also, we are concerned as to whether our pocket queries and other premium information will be lost as a result of this lapse?

Our original suggestion was that a request to move a bug into someone's hands could only be actioned by a reviewer at geocaching.com, which limits the potential for abuse. This wouldn't be a common occurence and would only be used when there was physical written evidence of the bug's holder.

Whenever our team visits a cache listing a travel bug but finds that the bug has been physically retrieved but not yet logged out of the cache page, we send a note to the cacher who retrieved the TB (with a copy to the TB owner). However, these often go unanswered and the bug remains listed on the cache page. When there is no response, is there any way that geocaching.com administrators can action the correct retrieval log, rather than just marking the bug as 'unknown location' (or leaving the bug incorrectly listed in the cache.) It would be preferable for the bug to be shown as being in the hands of the retriever, especially in situations like this, when the holder of the bug is known. An example of this situation can been seen on this page: TB Skinny Minnie

Presently, you can conveniently remove a cache from your watchlist, by clicking on a link in the upper right corner of the cache page. It would be nice if the same link existed on a travel bug's page, rather than having to go look it up on your account page.

Travel Bug pages with numerous log entries are split up into multiple pages, starting with the most recent entries, followed by older entries. However the page numbers run counter to this -- page 1 contains the most recent entries, as opposed to the oldest entries. It seems that the oldest entries should be on page 1 and the newest entries on the highest page number. This way, a log entry will stay on a fixed page number, rather than shifting around as they do now. For example, if I post a TB log entry today, it will appear on page 1. In a few weeks time, if there has been a lot of activity for this bug, my log entry will have shifted to page 2 or perhaps 3, and this shift will continue for the life of the bug. If you reverse the page numbering, the log entries will stay put, making them easier to find again later.

Please consider adding an option to the Travel Bug page that would allow a user to view all log entries on the same page. (In other words, adding a link to "View them all on one page," such as currently exists for cache pages.) When following a bug's progress, it is more user friendly and enjoyable to be able to scroll through all the entries, rather than clicking for each previous page. We had this option before, and recognize the reasoning for going to a page-by-page format, but a big drawback to not being able to see all logs at once is when searching for specific text. If there are 20 pages for a bug, it now requires 20 individual searches, rather than performing just one if a full bug log history display were possible.

We love this new feature. We've often thought to ourselves that it would be a great idea, and now here it is! We'd like to suggest an enhancement to this: We know of a number of very worthwhile caches where the owner is obviously absent and unresponsive. If the 'needs maintenance" log entry is ignored by the owner after a certain timeframe, perhaps the cache could then be referred to a reviewer. The reviewer could have the option to mark the cache as "available for adoption" and invite local cachers to apply. On our visits to Hawaii, we have enjoyed some wonderful (albeit orphaned) caches which would obviously benefit from the adoptive care of a local owner.

We would prefer the travel bug page to have the same option as a cache page when viewing the log history -- the ability to choose to "View them all on one page." When following a bug's progress, it is more user friendly and enjoyable to be able to scroll through all the entries, rather than clicking for each subsequent page. Also, the biggest drawback to the recent change is searching for specific text. If there are 20 pages for a bug, it now requires 20 individual searches, rather than performing just one if a full bug log history display were possible.

I agree that the cache page should display the log entry text the same way it does when you view a log separately. The UBB code (especially for hyperlinks) should display properly on the cache page, as it previously did. Has anyone at geocaching.com acknowledged this problem? Is it on their TO DO list? It is a feature I would like to see restored.

Thanks for pointing this out. We often use links in our logs to make them more interesting or informative. We agree that it is very important for the reader to be aware that there is a link contained within the text.