Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The background batch module is great, but there are certain modules (or batch operations) that should not be backgrounded.
The backgrounding causes a problem with things like webform download as CSV.
The background part causes the file to not be downloaded.
(It may have been downloaded in a background process that never makes it to the client in the foreground)
It would be helpfull to blacklist such operations and have the normal drupal core foreground batch functions be called.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 2059899_ignore_batch_urls.patch | 958 bytes | zuernBernhard |
| #2 | drupal-7.x-background_batch_hack-1.patch | 1020 bytes | thekevinday |
| #2 | background_process-7.x-1.x-batch_types-1.patch | 955 bytes | thekevinday |
Comments
Comment #1
gielfeldt CreditAttribution: gielfeldt commentedInteresting. I wonder whether it would make sense to have a blacklist or a whitelist?
In regards to the file download, that _should_ happen on the finished callback AFAIR. And that particular callback is not run in the background (also AFAIR). Perhaps there's something else broken in Background Batch.
I'll look into it.
Comment #2
thekevinday CreditAttribution: thekevinday commentedFor now, I made a hack to get this to work.
For reference, here is the hack:
I altered drupal cores drupal_process_form() function:
- The batch_process() accepts a $url for its arguments, but provides no way to actually pass this!
- The hack is to define some sort of drupal variable called batch_foreground and batch_background that is an array of form ids.
- I then pass a URL path of batch_background or batch_foreground.
- This is furthermore hackish because I did an if test to see if the background_batch function exists: background_batch_menu_alter().
The next step was to hack background_batch:
- Added a batch_background menu.
- Added a batch_foreground menu via the background_batch_menu_alter() function that is a copy of the original 'batch' menu before background_batch alters it.
This allowed me to do what I need to do for the time being while waiting for you to come up with a more proper solution to the bug/feature.
I attached my patches for reference.
Comment #3
karibou-mtl CreditAttribution: karibou-mtl commentedThis patch don't work for me.
Comment #4
rviner CreditAttribution: rviner commentedIn order to get the patch to work I had to include the name of the form in the empty array:
$foreground = variable_get('batch_foreground', array());
$background = variable_get('batch_background', array());
change to:
$foreground = variable_get('batch_foreground', array('webform_results_download_form'));
$background = variable_get('batch_background', array('webform_results_download_form'));
It would be nice not to hack core though.
Comment #5
Elijah LynnI am thinking it would be better to have a whitelist. Generally it is only for certain batches you sought out the background_batch module in the first place. I would like to see a whitelist feature. Just add an option to your batch like
$batch['background_batch'] = TRUEand now it gets run by background_batch.We can still keep most other things the same. Maybe just check for this in background_batch_batch_alter().
Comment #6
zuernBernhard CreditAttribution: zuernBernhard at UEBERBIT GmbH commentedAnother approach could be to not hijack the batch-URL (so that the backend webform export stays "as-is") but to start the process from a custom module in case we want to "background-process". This works very nice here if we remove the hook_menu_alter implementation.
Comment #7
jrochate CreditAttribution: jrochate commentedThanks. #6 solution made webform export working again, since I am using background_process for custom modules.