Batch API does not use ajax

[Nathan Rambeck]

When running code in Pressflow using Drupal's Batch API, I notice that it refuses to run each batch as an ajax call in the background. Instead it does an entire page refresh on each new batch. After some investigation, it seems the Batch API code is looking for a cookie called has_js which was is set in drupal.js in Drupal, but has been removed from Pressflow. The cookie should either be set, or the batch.inc file modified to use javascript regardless of the cookie being set.

Here is the code in drupal.js that is missing from Pressflow:

  // 'js enabled' cookie
  document.cookie = 'has_js=1; path=/';

You can find the code that looks for this cookie in the includes/batch.inc file inside the _batch_start() function.

[David Strauss (davidstrauss)]

We dropped it intentionally, but there are probably better solutions in general to support downstream caching proxies.

[Tomáš Fülöpp (vacilando)]

This has caused me a headache for several days. Also opened an issue at d.o., see http://drupal.org/node/830094

Note that has_js is there and it is set to "1" (see in the above issue) but it is not taken into account and Batch API sets itself to "op=do_nojs"

I trust Pressflow has good reasons to disable AJAX in Batch API, but it would be good to be able to have a switch for that, either in settings.php or in the interface, because without JS it is virtually impossible to rebuild perms or sitemaps etc. on larger sites.

[NecLimDul (neclimdul)]

More than likely you've followed one of the Varnish configuration examples that strips this cookie. I've removed the code that strips it from my Varnish config since we don't send it. That way I can manually add the cookie and Batch API starts working again. Pretty hacky but it works for the power user until we get a better solution.

[Tomáš Fülöpp (vacilando)]

Hi NecLimDul, thanks for your comment.

I have simply used the current Mercury 1.1 (ami-6d3c1619).
(One of the main reasons for upgrading from Mercury 1.0 (ami-11b79c65) was that Batch API did not work. I thought the upgrade would help.)

Any idea how to enable the Batch API in existing install of Mercury 1.1?
I also tried with the Drupal Varnish module disabled but that did not help.

[Josh Koenig (joshkoenig)]

On the pantheon side, we need to remove the VCL that's stripping the has_js cookie. This could cause other problems with more advanced AJAX features as well, and I don't think we take much of a hit in terms of cache performance since 99% of people have js.

[Greg Coit (gregcoit)]

removed has_js cookie stripping from Pantheon's varnish vcl file.

[Kevin Miller (kemiller)]

To allow Varnish to remove the has_js cookie for logged-in users, therefore allowing stuff like ctools and batchapi to work, we just wrote the following into a 'tweaks' module. This puts the has_js javascript into the header, but then removes any has_js cookies on logout.

<code>
/**
* Add the has_js cookie to the user's JS entry
*/
function site_tweaks_init() {
 global $user;
 if($user->uid > 0) {
  drupal_add_js('document.cookie = "has_js=1; path=/";', 'inline');
 }
}

/**
* Adds a 'has_js' cookie for only logged-in users
*/
function site_tweaks_user($op, &$edit, $account) {
 if($op == 'logout') {
  setcookie('has_js', '', time() - 3600);
 }
}
</code>

[Kurt Gray (kurtgray)]

On Acquia Hosting we rearranged the VCL so that we check for the SESS cookie and pass *before* normalizing the Cookie (removing the has_js, etc, etc) which allows Drupal to see the entire original Cookie for at least logged-in users.

[Josh Koenig (joshkoenig)]

The most recent "suggested start VCL" for Pressflow also passes the has_js
cookie, since this could be a legitimate reason to uniquely cache pages:

https://wiki.fourkitchens.com/display/PF/Configure+Varnish+for+Pressflow

<https://wiki.fourkitchens.com/display/PF/Configure+Varnish+for+Pressflow>This
should be included in the most recent releases of the Pantheon AMIs.

-j

On Thu, Oct 28, 2010 at 12:44 PM, Kurt Gray <email address hidden>wrote:

> On Acquia Hosting we rearranged the VCL so that we check for the SESS
> cookie and pass *before* normalizing the Cookie (removing the has_js,
> etc, etc) which allows Drupal to see the entire original Cookie for at
> least logged-in users.
>
> --
> Batch API does not use ajax
> https://bugs.launchpad.net/bugs/529252
> You received this bug notification because you are a member of PANTHEON
> Developers, which is subscribed to Pantheon.
>
> Status in Pantheon - open-source system configuration for enterprise
> Drupal: Triaged
> Status in Pressflow: Triaged
>
> Bug description:
> When running code in Pressflow using Drupal's Batch API, I notice that it
> refuses to run each batch as an ajax call in the background. Instead it does
> an entire page refresh on each new batch. After some investigation, it seems
> the Batch API code is looking for a cookie called has_js which was is set in
> drupal.js in Drupal, but has been removed from Pressflow. The cookie should
> either be set, or the batch.inc file modified to use javascript regardless
> of the cookie being set.
>
> Here is the code in drupal.js that is missing from Pressflow:
>
> // 'js enabled' cookie
> document.cookie = 'has_js=1; path=/';
>
> You can find the code that looks for this cookie in the includes/batch.inc
> file inside the _batch_start() function.
>
>
>

[Andrew Berry (andrewberry)]

I'm not sure if there were notifications for my merge request, but I'm using this branch along with Varnish and the Batch API works as expected: https://code.launchpad.net/~andrewberry/pressflow/529252-has-js-cookie/+merge/69900

[pwolanin (pwolanin)]

The latest pressflow is still not setting the has_js cookie

[Cyberpunk (cyberpank)]

+1 still no has_js cookie.