As first pointed out in #229825: backport "$_COOKIE['has_js'] must die" patch to 7.x, the Batch API falls back to using a meta-refresh tag when Javascript is disabled.

Some browsers (lynx) do not support this tag at all, and some (Opera?) allow it to be disabled.

The Batch API, and any other code that uses a meta refresh element, must print a visible message on the page that informs the user they are waiting to be redirected, and provide a link to manually follow the redirect.

This is common fallback behavior; see SourceForge download links and the 404 message at for two examples.


keith.smith’s picture

This may be a duplicate, or at least a closely-related cousin, of

Robin Monks’s picture

In reply to #1:
I believe this bug is better suited to handle the issue, since is much "vaguer".


cburschka’s picture

Note: The proposed fix of adding a visible link will fix the issue for text-only browsers, but will of course not work for non-interactive user-agents (such as cron).

We will need to rethink this problem eventually, even if we do it only in D7. The batch API is a fine piece of work, but it relies completely on interactive interfaces, which is not always useful. Historically, batch jobs are processed non-interactively on most systems. That makes this problem somewhat ironic.

Chris Johnson’s picture

Perhaps this comment does not add much value to the conversation, but it just struck me: how can it be called a batch API if it requires interactive usage? The two terms are essentially exclusive opposites by definition.

Robin Monks’s picture

Version:6.x-dev» 7.x-dev
Component:base system» documentation

Yeah, yeah, I know.

So shoot me ;)


cburschka’s picture

How exactly is this a documentation issue? User interface text, at best, but documentation?

Robin Monks’s picture

Component:documentation» base system

Weird, I didn't change that select :-/


mikeytown2’s picture

This is an example of code that calls it's self until it is done. Only works on linux boxes & you need to set it up according to your server configuration. If you could detect the location of the php interpreter on the system, then that would make life simpler.
It runs completely independent of Drupal, but in the future I will have it use the Drupal DB to keep track of it's self instead of a temp file.

mikeytown2’s picture

made said code work on all systems now... there's enough there to make this work now.

nod_’s picture

Version:7.x-dev» 8.x-dev
mikeytown2’s picture

This issue can be fixed if this issue gets in #1447736: Adopt Guzzle library to replace drupal_http_request()

effulgentsia’s picture

My read of this issue is that the server-side portion of BatchAPI should be fixed to output a link for interactive browsers. Is that correct? If so, I don't see how Guzzle is related. Or, is this issue about making simpletest or some other non-interactive core http client support meta refresh? In which case, yes, a better http client library would help, but if that's what this issue is about, can the title and summary be updated accordingly?

mikeytown2’s picture

Batch API uses the browser to start up PHP multiple times. Guzzle can do a non blocking request to it's self; this allows for the batch to be done without a browser window by emulating what a browser would normally do (request the page again once processing is done for that run). Guzzle allows us to redefine what we think of when we say Batch API. Currently we think it requires a browser window to always be open in order to preform the batch operation. With Guzzle we could fire off a batch operation and have a currently running jobs dashboard, allowing one to see ALL currently running batch operations and things like that. All of this requires a complex HTTP client like Guzzle.