Hello!
I`ve created a module (called util) with blocks loading via ajax as in authcache_example module. It worked fine on a clear installation of drupal. But on production site it did not work: no errors were shown, but in firebug you could see that GET request was made (http://mysite.com/?util=1257857606&max_age=3600) and wrong response was send (returning ' ', like if is_page_authcahe was TRUE) and my custom js function _authcache_util was not called. After some research I found out that there was a "parsererror" in Authcache.ajaxRequest function (authcache.js) - I had to alert parameters in Authcache.ajaxError to understand it - debug was not working probably because it thought that "Ajax request was not sent", so #authcachedebug was not even shown (I suggest this is also a separate bug).
I began switching off modules and short time after found out that this error vanished after I`ve disabled og_user_roles module (it`s version was old - 1.2.x). Due that ogur module was essential for my site to work I`ve upgraded it and a bunch of other modules to higher versions and everything began working fine...
...until today when this parser error suddenly came back!
The response (with error, so my js callback was not called):

{"util":"[ \" \", \" \" ]"}
<!-- Authcache Footer JSON -->
<script language="JavaScript">
var authcacheFooter = { "info": { "page_render": 558.01, "cache_render": "-1", "cache_uid": "21074", "cache_inc": "cacherouter.inc (db)", "cache_time": 1257857836 }, "ajax": { "q": "frontpage" } };
</script>

Authcache debug once again told me: "Ajax request not sent."
After some crazy brainstorm I`ve commented a line "drupal_bootstrap(DRUPAL_BOOTSTRAP_PATH);" in my php function _authcache_util($vars) in authcache_custom.php, so now it looks like:

function _authcache_util($vars) 
{		
  	//drupal_bootstrap(DRUPAL_BOOTSTRAP_PATH); // Use FULL if needed for additional functions
  	include_once './includes/common.inc';
  	include_once dirname(drupal_get_filename('module', 'util')) . '/util.module';
  	return drupal_to_js(array(util_display_block_0(), util_display_block_2()));     	 
}

And everything began woking fine one more time. No significant code changes were made in the period between crashes.
Can you please provide workflow logic and also some explanation of using drupal_bootstrap and why it could cause such errors?
Thanks.

Comments

Alexzander’s picture

I found out what cause part of the problems described above.

I`m using JSON object containing html for different areas (it is inserted where nedded by javascrpit called on authcache ajax callback). For some complex html creation I used to call some method with lot`s of dependencies, so I have decided to call drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

The incorrenct workflow was as follows:
1. _drupal_bootstrap_full() calls module_invoke_all('init'); - so Authcache is also initialized.
2. Function _authcache_shutdown_save_page() registred as shutdown to cache the ajax response and is called after response is built.
3. There it checks if non html content is cached - but exclusion of JS footer is done only for XML, so it is appended to my JSON.
4. jQuery`s ajax method expects parsererror, cause JSON object with JS footer appended to it is not valid. Js ajax callback is not called.

So it is an authcache bug, I suppose.

To make everything work and cache response, one can append some condition on line 228 (authcache.helpers.inc), so that $is_cached_nonhtml value would change to TRUE, or use a function, idential to _drupal_bootstrap_full(), but without invoking authcache_init() (line module_invoke_all('init'), note that response won`t be cached this case).

Jonah Ellison’s picture

Assigned: Unassigned » Jonah Ellison
Status: Active » Fixed

Ah, yeah, the Ajax callback is being called for the example module, but it wasn't showing up in the Authcahce debug window. This is fixed now in RC2. There's also an additional check to try to prevent Authcache from initializing if an Ajax request is made and the Drupal bootstrap run.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.