Report GCA Site issues here [closed]

[caughtatwork]

Hmmm. I logged in as you (using a spoofed password, don't panic I have no idea what it is). I changed your home co-ords by 0.001 and it seems to have set the alerts distance correctly. I changed it back and it has again changed them correctly. Let's see what happens.

[Swampy]

I logged a couple of movables today (1/1/13) but on the cache listing, it shows I found them on 1/1/12. A whole year ago.
They show up in January 2013 when viewed as My, Logs
I only twigged to this as I was looking at the dashboard for Tas and wondered why there werent any stats yet.....

[caughtatwork]

I logged a couple of movables today (1/1/13) but on the cache listing, it shows I found them on 1/1/12. A whole year ago.
They show up in January 2013 when viewed as My, Logs
I only twigged to this as I was looking at the dashboard for Tas and wondered why there werent any stats yet.....

Which ones?
http://geocaching.com.au/cache/ga3528 This one you have found on 1/1/12 AND moved 1/1/13. You don't get a find credit for a moved only log so it wouldn't show up on the dashboard.

[Swampy]

DUH!

[quiet1_au]

Problem with cache type from GPX query of found caches.

I seem to have an issue when it comes to importing certain found caches into my GSAK finds database. Every Burke & Wills (B&W) cache comes in as "? Other" regardless of cache type on the GCA website (ie. virtual, traditional, etc) so I have to manually override them each time if I am to get updated statuses etc.

This does not happen with any other GCA caches though - traditional will be traditional, multi will be multi, etc - with the exceptional of movables (but as there is no "Moveable" type in GSAK, "Other" is an appropriate substitute)

Any reason why the Burke and Wills caches might be different to other GCA caches in this regard?


The only other exception is the FedCam webcam cache - but as that's a GC.com cache it's not your problem! (In fact, the GA3186 webcam cache comes across the correct cache type just fine!)


Thanks -

[caughtatwork]

B&W caches are a special type. They are indistinguishable from each other in terms of whether they are virtual, traditional, etc, etc. The only way to know is to look at the cache name to determine what you are looking for.

[quiet1_au]

B&W caches are a special type. They are indistinguishable from each other in terms of whether they are virtual, traditional, etc, etc. The only way to know is to look at the cache name to determine what you are looking for.

Ah - that would explain it - I'll just keep tweaking the entries in GSAK then

Thanks

[mark_rattigan]

Just a heads up after trying to look at finds/logs on my cacher page (http://geocaching.com.au/cacher/mark_rattigan/finds and http://geocaching.com.au/cacher/mark_rattigan/logs). Site header/banner loads fine, however the db queries seem to be non-responsive. Probably needs a kick.

Thanks as always.

Edit: Had a shower, came back and the pages had loaded, however still quite slow.

[caughtatwork]

Performance is, on occasion, spotty.
We're looking to a new machine this year (about $8K to $10K investment) which should sort most of these sorts of problems out.

[mark_rattigan]

Performance is, on occasion, spotty.
We're looking to a new machine this year (about $8K to $10K investment) which should sort most of these sorts of problems out.

No problem - wasn't sure if it may be something out of the ordinary requiring attention. Thanks.

[GammaPiSigma]

I've been experiencing errors with the "Gmap (Native)" link on the cache pages.

1. http://maps.google.com/maps?q=-34.07337 ... eaven)&t=v takes me to London when it should be Campbelltown. When I removed the "Stairway To Heaven" bit it worked fine.
2. http://maps.google.com/maps?q=-33.61068 ... %20#1)&t=v seems to fall over as there is a # in the parenthesis part of the url. If I just use: "-33.610683 150.696733 (Yarramundi Reserve)" it works.

I tried a few others and experienced problems with some of them but the rest seem fine. Then again it could just be me.

Cheers,
Michael.

[mark_rattigan]

1] Looks like "to" is triggering directions mode - "Heaven )" being the location in London, with "-34.07337 150.81686 (Stairway" as the origin being unrecognised. Can be worked around by double-quoting within the brackets.

2] '#' should be escaped in the URL with '%23'.

[caughtatwork]

Thanks for the report GammaPiSigma. Thanks also to mark_rattigan for the encoding tip.

A few weird things going on. The word to when it appears seems to trigger Google Maps to try and find directions from A to B. So now the entire cache name is surrounded by "". If the name already had "" then they get doubled. Looks weird, but what are you going to do.

I also found that () and <> will not work, even if encoded, so I now strip those out before using the name. Talk about weird.

Anyway, should be working now.

[Persian Princess #1]

Hello

I have just joined
My username is Persian Princess #1.
I have logged 2 trigs in GCA
and imported 5 finds from GC
and I can't see them

When I look at the screen for my finds, it drops off the #1 from my name
Does this cause a problem

Thanks for your help

[caughtatwork]

Regrettably, the # in your name is causing the issue. See the reasoning below.

http://www.blooberry.com/indexdot/html/ ... coding.htm

'Pound' character ("#") This is used in URLs to indicate where a fragment identifier (bookmarks/anchors in HTML) begins

Geocaching Australia uses the geocacher name to link cache finds together, so I'm afraid you will need to change your name to something without the #.
You should probably align your geocaching.com name too.

Sorry, but we're stuck behind the "rules of the internet" with regards to the use of the # in your name.