daRAMA

I'm still experiencing extreme page load times in the evening hours (CEST). Good old http (no SSL): [20:20:43.605] GET http://www.geocaching.com/images/wpttypes/sm/3.gif [HTTP/1.1 304 Not Modified 312ms] [20:22:56.807] missing name after . operator @ http://www.geocaching.com/js/jquery_plugins/jquery.countable.js:63 [20:22:57.078] GET http://www.geocaching.com/images/logo_print_bw.png [HTTP/1.1 304 Not Modified 484ms] Kind regards

It still takes literally ages to log a find in the early evening hours (CEST). Firefox Web Console log: [18:14:53.360] GET http://www.geocaching.com/js/jquery_plugins/jquery.countable.js [HTTP/1.1 200 OK 130328ms] [18:17:03.676] missing ) after condition @ http://www.geocaching.com/js/jquery_plugins/jquery.countable.js:63 [18:17:04.075] GET http://ads.Groundspeak.com/a.aspx?ZoneID=9&Task=Get&SiteID=1&X=%2706a40f967aed46c6b5e6b874fc86575a%27 [HTTP/1.1 200 OK 578ms] Kind regards

Logging a single cache currently takes about 10 minutes - just as it did yesterday. And http://status.geocaching.com/ tells me everything is "operating normally" Kind regards

Wow - you are quicker in fixing things than I am in filing bug reports... A left over is the pre/post site update logs issue. New logs use much more whitespace than old ones above and below the log. I guess it's because the WYSIWYG editor inserts <p> instead of <br />. BTW: Please consider having the WYSIWYG editor as an option and not the default. For the normal two or three line log without fancy markup the old editor was a lot more convenient. Kind regards