Можно, главное чтобы в разных словарях не было одинаковых терминов, но даже и этот случай можно обойти заведя правило

Там где определяете аргумент-s для view сделайте свою обработку аргументов %/%/% на php
в вашу функцию прилетит этот урл, от него отгрызете аргументы, поищете каждый аргумент среди терминов словарей, а если вспомнить что в словаре у каждого термина может быть еще и алиас, то и среди русских и не русских алиасов терминов, найдете искомый термин, подставите его id как аргумент для view

корзина замечательно и с кэшем работает через ajax

Возможно это тоже поможет?
http://xermit.blogspot.com/2011/01/jquery-ui-drupal.html

Да, вы правы, без join-ов не обошлось :(. Причем именно как вы описали, чем больше фильтров по терминам, тем во столько раз больше left join-ов будет использоваться для построения перекрестной таблицы.

Не надо, на самом деле можно без аргументов обойтись совсем, по крайне мере, когда я исследовал этот вопрос у меня получилось обойтись исключительно фильтрами.
Таким образом я легко могу найти все товары, у которых указано оба термина таксономии, как из одного словаря так и из разных, а аргументы мне нужны были только лишь из-за того, что у меня параметры exposed фильтров передаются в виде чистых ссылок.
Тогда и проблем с ограничением на количество join-ов не будет, так как все условия фильтров уйдут в секцию where.

Вообще то странно, так как должно работать итак, у меня работает. У меня сложнее в url аргументы передаются.

Может не работать! из-за неверно настроенной view, которая называется taxonomy_term, я из-за этой неверной настройки целый год думал что 1,3,5 в друпал не работают.

А на самом деле надо было пинать view с названием taxonomy_term, у меня сейчас у этой view следующие настройки и все работает, ищет только то, что принадлежит обоим терминам сразу.

Единственное я так и не понял у вас аргументы по таксономии или еще по чему то?

страницу, view может выбрать и не указывая тип материала, и по любому другому параметру, который вы не знаете и предусмотреть все не сможете. Задача не решаемая, даже если заставить все view по очереди отработать а потом проверить в каких из них ваша страница отобразилась, даже в этом случае нет никакой гарантии, так как выбрать она может страницу например если пользователь указал другйо параметр в динамическом фильтре view. Это не решаемая задача, а зачем вам такое знание?

если вы не сделали фильтр как как exposed (у меня нет drupal 7), то фильтр не будет воспринимать какие либо параметры на фильтрацию переданные каким либо образом в view. он будет фильтровать так как вы указали один раз при настройках в view, возьмите в настроках вашего филтра сразу укажите что выводить только мишлен и вместо всех вы всегда будете видеть только шины мишлен, чтобы вы не выбрали в левом меню.

Вообще то это один из стандартных способов темизации в drupal всего и вся, и вообще не огорчаться, а радоваться надо, что они в друпале есть и их несколько, так как в других системах и один то поищешь.

А фильтр у вас exposed? вы указали, что для фильтра по терминам таксономии пользователь может выбирать сам термины, иначе фильтр не воспримет параметры переданные в составе url-а.

Могу объяснить почему не визуальное решение во много раз лучше любого визуального редактора.

Использую решение на основе модуля linodef + nodepicker
Пример:

Зашел поглядел на сайт, покажите скриншоты настроек фильтров, у меня к примеру все работает.
Опишите точную последовательность действий и суть ошибки. Я вижу, что на сайте, при выборе мишлен, отображаются шины именно мишлен, точнее один тип шины, при выборе другого бренда отображается единственная шина выбранного производителя.

Я вот ленивый так модуль отдельный и не сделал

А зачем такие сложности с jquery 1.7 что пришлось переименовать $ на f.
Достаточно было загрузить jqueryui сразу после jquery-1.7, а потом noconflict скрипт, и все.
Читали тут? Подружить последний jquery ui и drupal

Мне больше другая технология нравится http://ru.wikipedia.org/wiki/Colinux

извините не углядел мой вариант был для убера на 6-м друпале

print($node->content['add_to_cart']['#value']);

А в прометее по видео касту так и не понял require_once для модуля все равно выполняется? Неужели нельзя отложить загрузку ровно до того момент когда класс реально понадобится?

Если переписать часть ядреных модулей друпала через контроллеры это ведь увеличит производительность? Так как не позволит php в пустую лопатить код который при данном конкретном запросе вызван не будет, а если понадобится так его менеджер запросов загрузит по требованию, как это делает Yii.

называется rss

делайте редирект на tovari/all?identifier_filter=жигули

drupal_set_message(print_r(menu_tree_all_data(), 1));

долгого листания

Точно также файрбагом делал, но свой tpl.php тоже помогает

ну скажем так, так как вьюха у вас в режиме вывода полей стоит скорей всего, тогда добавьте поле кнопка 'добавить в корзину', но скройте его, а в custom_field выводите то скрытое поле когда надо, там кажется можно добраться до поля другого.