Use Batch API to regenerate menu
muhleder - August 3, 2009 - 20:04
| Project: | Taxonomy Menu |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
Hi guys,
not sure if this would be best as a feature request for version 2 or 3, but it would be super nice if the module could use the Batch API to run the menu rebuilds. I've been using it on a site with about 200 menu items (Product hierarchy), and have been running into timeout issues. I can use set_time_limit() to cheat the timeout using the insert hook, but it would be much better practice to use the Batch API imo.
Any thoughts on this?
Thanks,
Mark
#1
Not sure if indytechcook has used this but, I think it can be looked into.
Link to example of batch API: http://drupal.org/node/180528
#2
Yes, I've just set up an implementation using the batch API so I should be able to set up the vocab rebuilds to use it quite easily. Looks like you would send off the "//cycle through terms for the vocab" loop in this function to be processed by the batch API.
/**
* Creates new link items for the vocabulary
*
* @param $vid
*/
function _taxonomy_menu_insert_link_items($vid) {
$menu_name = variable_get('taxonomy_menu_vocab_menu_'. $vid, FALSE);
//check to see if we should had a vocab item
if (variable_get('taxonomy_menu_voc_item_'. $vid, FALSE)) {
$args = array(
'vid' => $vid,
'menu_name' => $menu_name,
);
$mlid = taxonomy_menu_handler('insert', $args);
}
//cycle through terms for the vocab
$terms = taxonomy_get_tree($vid);
foreach (taxonomy_get_tree($vid) as $term) {
$args = array(
'term' => $term,
'menu_name' => $menu_name,
);
$mlid = taxonomy_menu_handler('insert', $args);
}
}
During the menu rebuild, that's called from _taxonomy_menu_rebuild after all the menu items have been deleted, so that should take care of the rebuild case, the case for updating menu items would be different, am not familiar with that part of the code.
The only issues I can see is whether or not to display a progress bar during the rebuild (or to do it all behind the scenes), and whether it will work if the rebuild is called during a different batch process.
#3
This patch should take the menu item regeneration out to a batch process. It doesn't work if it's called from within another batch process, but I don't think there's any way a use of the batch API can do that.
Don't think you'd want to be regenerating a menu on each stage of a batch in any case, might be good to add a hook_taxonomy_menu_rebuild function to the API so that it's possible to intercept the call to batch if required.
This should fix memory limit and timeout issues you get with larger menus being regenerated. Just noticed issue http://drupal.org/node/525408 which is similar to the issues I was getting. This wouldn't work for 5.x though as the batch API is new in 6.
Since it doesn't work from within another batch process it's prob not appropriate to use the batch method to process menu updates, again not sure if that is necessary anyway.
EDIT: have a bug in this patch, the batch call is in the wrong place, will upload a corrected patch
#4
Patch with the batch call in the correct function.
#5
And again with some code specific to my project removed. Sorry about the multiple updates.
#6
Great work muhleder!
I'm not sure I totaly understand batch API. Please let me know if this logic isn't correct.
After reading the documentation, it looks like it only process per each new page request. So this means that only 10 (or what ever other number) of menu items will be updated for each page request. Would this require the page to be refreshed several times for the menu to be totally created? Or is this done via ajax?
#7
That's right, it will run through 10 changes per page request, and the batch API will keep calling the page (using ajax if js is enabled, or drupal_goto if not). The database update you run using update.php uses the same method if I remember correctly.
#8
Great. I'll do some testing. It looks like a good patch.
#9
This seems to work. I commited this. It should part of the new dev.
#10
This is part of 6.x-2.4-beta2.
#11
Automatically closed -- issue fixed for 2 weeks with no activity.