One of our clients has started using this module and has set up about 300 taxonomy terms with about 10 or so parents, and it results in about 2000 queries per page load, and slowed his site down to about 10 seconds per page.
To attempt to combat this, I've built a basic caching mechanism for the module. This could very clearly use some work, as it is completely non-configurable and may well be entirely broken in certain use cases, but it's a starting point at least.
504,511c504
< $term = (arg(0) == 'taxonomy' && arg(1) == 'term') ? arg(2) : 'root_taxonomyblocks_menu_cache';
< $cid = 'taxonomyblocks:' . $term;
< $content = cache_get($cid, 'cache');
< if (!$content) {
< $content = theme('multi_taxonomyblock', $item);
< cache_set($cid, $content, 'cache', CACHE_TEMPORARY);
< }
< $block['content'] = (is_object($content)) ? $content->data : $content;
---
> $block['content'] = theme('multi_taxonomyblock', $item);
Comments
Comment #1
jeff veit commentedThat looks like a good start, but I think there are a few potential problems:
1. If the taxonomy changes, then the cache should be invalidated
2. If the Adv Taxo Block changes, then the cache should be invalidated
3. I think that there are modules which put in place access control over taxonomies and terms. If the user is subject to some access control then they may see taxo terms or categories to which they have no permission.
Comment #2
PixelClever commentedHave you tried using the block cache alter module? This is is what I use, and it is said to be destined for core.
Comment #3
jeff veit commentedIt also occured to me that you need to handle block translations: if you are running the i18n modules then the taxonomies can have different language versions, and each needs to be stored and retrieved. I'm not sure if this is baked into cache_set and cache_get or not.
Comment #4
PixelClever commentedI really don't have time to chase this down. If you can produce a working patch against the current version that doesn't break anything then I will add it.