Hello.
Got a problem with fottermap module (v. 6-1.5), installed in Drupal 6.14 with l18n.
A block with sitemap outputs all available menu items of Primary links of all languages regardless of the language currently selected by user.
How to fix it? It might be simple, i think.

Comments

mradcliffe’s picture

Version: 6.x-1.5 » 6.x-1.x-dev
Assigned: Unassigned » mradcliffe
Category: support » feature

I'm sorry I haven't responded to this yet I've been pretty busy the last week and this week as well.

Footermap doesn't currently take into account language settings. I think it would be a good feature to use a user's language setting or the default language for an anonymous user.

Thank you.

mradcliffe’s picture

Actually, on second thought, there's no way that this can work in the scope of footermap.

Footermap is generally best used when cached. It caches data globally, not per user. I guess it could cache a copy per language.

I would need to rework how things are rendered and the associative array that contains menu tree that I generate.

dhtml2’s picture

I also let you know about very important thing. I used footermap at my dev installation, with 479 l18n pages. It made output of 479 links, that was okay, but only at localhost. When I moved it to remote server vith common configuration, MySQL daemon gone do death on every page load. So I've installed Devel and then checked queries generated by Footermap without cache. There were more 3000(!) of 'em, mostly on permission check. Going with this ahead, there were more than 6-7 queries for each item render.

I think you should carefully revise the core architecture of module, 'coz it really unuseful on huge sites despite of really very good and nessesary idea.

Good luck!

mradcliffe’s picture

Priority: Critical » Normal
Status: Active » Closed (works as designed)

You need to be using the caching method available if you have this many items.

True, with the recent addition of a feature request to add more access control the number of queries increased. It may be necessary to roll back this feature due to performance concerns when refreshing the cache.