Detect cache status from the client-side

This looks promising! Thanks, mondrake.

+++ b/better_statistics.moduleundefined
@@ -495,3 +495,21 @@ function better_statistics_add_js_api() {
+
+function better_statistics_boot() {

Naturally, we'll need a doc block here; more importantly, we'll need hook_update_N() function to mark Better Statistics as a bootstrap module in the system table. Without it, only fresh installs of the module will fire the hook_boot implementation. Sorry, nevermind. Forgot that hook_exit implementors are also automatically marked as boostrap modules (though the doc block comment still applies).

+++ b/better_statistics.moduleundefined
@@ -495,3 +495,21 @@ function better_statistics_add_js_api() {
+    if (array_search('X-Drupal-Cache: HIT', $headers) !== FALSE) {
+      setcookie('Drupal.cache.status', 'HIT', time() + 60);

Regarding cookie persistence, perhaps we want to set the cookie time to time() or REQUEST_TIME without any additional time? If we can set it with minimum time, we'll still be able to access it on the client side, but it won't be sent with subsequent requests. That would be ideal.

+++ b/js/fields/custom.jsundefined
@@ -1,7 +1,22 @@
+function getCookieVal(key) {

Since we're not using this anywhere else, we may just want to throw it in the event listener callback; perhaps even as a closure.

+++ b/js/fields/custom.jsundefined
@@ -1,7 +1,22 @@
+  if (cacheStatus == 'void' || cacheStatus == null) {
+    event.data.cache = '';

I believe we still want to pass this in as the literal string "NULL," which is how it's currently handled.

Thanks for the work, mondrake. Couple of smaller points in #1 and #2 below. #3 may merit a little more discussion.

+++ b/better_statistics.moduleundefined
@@ -97,6 +101,42 @@ function better_statistics_ctools_plugin_api_hook_name() {
+
+  // Is Better Statistics enabled to track cached pages.
+  $bs_cache_logging = variable_get('statistics_access_log_restrictions_cache', TRUE);

1. Instead of checking if cached page logging is enabled, we may want to just check that the "cache status" stats field is enabled in the accesslog. It's possible someone wants to track cache status of MISS vs. NULL only (no HITs; disabled on cached pages). More importantly, we do not want to set a cookie if the cache status stats field isn't even enabled and collecting data.

2. Re "NULL": Yes, we should set event.data.cache = 'NULL' rather than event.data.cache = '' to remain consistent with how it's stored currently (which is the literal string "NULL" rather than an implied "null" value in the DB).

3. Another potential problem: the Statistics AJAX callback itself (and actually, any AJAX callback, or even broken/404 image; anything that will bootstrap the same Drupal instance) will set the Drupal.cache.status cookie. In the case of an AJAX callback, it will always be MISS. In the case of a broken image, it could be HIT or MISS. If they happen to load/fire before the statistics.accesslog event is triggered, you'd get bad data.

Not sure how we can handle that. We could definitely exclude our own AJAX callback, and perhaps the System and Views AJAX callbacks. Don't think we can do much else, though.

#8: better_statistics-js_cache_status_detction-2019937-8.patch queued for re-testing.

Triggered a re-test of #8 and it appears to still apply to dev; not sure why you're unable to apply the patch, @socialnicheguru.

By the way, I'd really love to try and resolve this before I tag a 7.x-1.4 release. My concerns would be best allayed if someone did end-to-end testing on a free dev instance of vanilla D7 on Pantheon (which would give you that Varnish layer).