Batch API support for Drupal 6 version
| Project: | User Import |
| Version: | 6.x-1.2 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Hi there,
I've created a small patch for user_import to support the new Batch API (http://api.drupal.org/api/group/batch). This means when processing via the web UI, instead of having "Import" and then "Continue" links in a loop, doing either will drop you into a Drupal batch monitor and will continuously import until the import is complete. This is safe because the batch API takes care of avoiding PHP timeout issues by resuming the batch via AJAX if required.
During import, the user is kept up-to-date on how many users have been imported, with a progress bar to show progress. Because user_import doesn't count the number of users beforehand, the progress bar is based on the current byte position and the file size, which should be accurate.
Of course this doesn't affect the ability to process from cron, although there's no way with batch API to have a "cancel" or "pause" button so the user could stop monitoring the process and let it run in the background on cron. If the user navigates away from the batch page, the batch will stop calling and the import will resume from cron though.
Hope this is useful! It certainly works nicely for me on large imports, so I don't have to keep clicking the continue button or wait for cron...
Thanks :)
| Attachment | Size |
|---|---|
| user_import.module.batchapi.patch | 4.83 KB |
#1
Loved the patch, but needed to configure how many per overall batch and individual batch call, so edited it a bit
Known issues is that the batch progress bar is wrong whenever file lines < max total.
Patch against 6 1.2 verision of user import
Forgot an important part, in install need an update function that does this or
<?php
db_query("ALTER TABLE {user_import} ADD current_processed int(11) NOT NULL DEFAULT 0; ");
OR
function user_import_update_61<Num><Num>() {
$ret = array();
db_add_field($ret, 'user_import', 'current_processed', array('type' => 'int', 'not null' => TRUE,'default'=>0));
return $ret;
}
?>
Or however adds that field in.
#2
Probably an issue with both patches, since the import can take significantly longer than usual CRON can start and try to hijack the import, causing issues. (Could happen to any import, but most imports are shorter and don't encounter this issue).
I've added an option to manually configuration page to disable cron, I'll make a patch if desired.