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 http://www.wikipedia.org/Article for two examples.
Comments
Comment #1
keith.smith commentedThis may be a duplicate, or at least a closely-related cousin, of http://drupal.org/node/204374.
Comment #2
robin monks commentedIn reply to #1:
I believe this bug is better suited to handle the issue, since http://drupal.org/node/204374 is much "vaguer".
Robin
Comment #3
cburschkaNote: 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.
Comment #4
Chris Johnson commentedPerhaps 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.
Comment #5
robin monks commentedYeah, yeah, I know.
So shoot me ;)
Robin
Comment #6
cburschkaHow exactly is this a documentation issue? User interface text, at best, but documentation?
Comment #7
robin monks commentedWeird, I didn't change that select :-/
Robin
Comment #8
mikeytown2 commentedThis 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.
http://drupal.org/node/363077#comment-1790536
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.
Comment #9
mikeytown2 commentedmade said code work on all systems now... there's enough there to make this work now.
http://drupal.org/node/363077#comment-1834282
Comment #10
nod_Comment #11
mikeytown2 commentedThis issue can be fixed if this issue gets in #1447736: Adopt Guzzle library to replace drupal_http_request()
Comment #12
effulgentsia commentedMy 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?
Comment #13
mikeytown2 commentedBatch 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.
Comment #14
nod_Guzzle is in so what's the status of this?
Comment #23
catchThis is closely related to #1189464: Add an 'instant' queue runner although the proposed implementation is different. In both cases it's trying to move some batch operations to non-blocking.
Comment #29
smustgrave commented@catch since #1189464: Add an 'instant' queue runner is closer then this should this one be closed?
Comment #30
catchThat issue starts giving us more options to process queues but it doesn't do anything to convert or fix batch API. For genuinely very long running tasks that need to be completed in a short time (installing and uninstalling modules etc.) it won't help at all.
For the lynx case where there's an interactive browser that supports neither javascript nor meta refresh, the original idea of outputting a link for the user to click makes sense - the usual 'Click this link if you are not automatically redirected' sort of thing.
For everything else we have more recent, but still old, issues like #1797526: Make batch a wrapper around the queue system
Comment #31
longwaveGiven the age of this issue and the lack of +1s from anyone affected by this bug, can we safely assume that anyone who wants to use Batch API either has JS enabled or uses a browser that supports meta refresh? Is there really anyone still using Drupal in Lynx? I assume there is no modern browser that allows meta refresh to be disabled either.
The issue I can see with 'Click this link if you are not automatically redirected' is that people might click it anyway if they see a link, which I think risks breaking the batch process more than if they just left it alone, which is the correct thing to do in 99.9% of cases.
Overall, I vote this is closed as won't fix.
Comment #32
catch#31 makes sense, let's do that. Anyone that was trying to administer a Drupal site using lynx is already able to do everything they want via the command line.