13 июня 2012 в 12:17
Views 2, Drupal 6, табличное представление с раскрытыми фильтрами и сортировкой (аякс: да) с включенным кешированием (0/xx часов/минут).
Десятки ишью на странице модуля, но ни одно не решено - может быть, кому-нибудь удавалось решить данную проблему?
Только не говорите, что все работает "на ура", и я один такой несчастный.
Комментарии
Когда-то давно специально проверял... как вьюс кеширует странички с экспозед-фильтрами и сортировкой..
Идентификатор записи кеша в БД строился из строки запроса, т.е. кешировались все варианты фильтров-сортировок для каждой страницы. -)))
Правда сейчас посмотреть настройки того сайта нет возможности (друпал 6, вьюс 2)
ЗЫ..А так... народ обычно интересуется, как отключить кэш у вьюса-)))
Спасибо! Так и предполагал. Но вот почему может некорректно работать это все, вопрос в этом? Мое ишью висит уже несколько дней без ответа.
Как бы выставить кеширование в настройке вьюс в "нет", не?
Вы решили эту проблему? Как все же отключить кэширование?
Тоже сейчас столкнулся с этой гадкой проблемой. На сайте активно используется фильтр по каталогу, сделанному во Views. И безумно не хотелось отключать в нём cache...
Сходу смог придумать пока такое решение. Если заглянуть в views_plugin_cache.inc, то можно увидеть там, что при составлении ключей (cid) кеша теряется очень много информации, которая дала бы уникальность каждому выводу вьюсы. То есть, по-хорошему, нам нужно учитывать всё то, что у нас есть в $_GET.
Если посмотреть в вышеуказанном файле функции get_results_key и get_output_key, то туда GET можно засунуть, увы, через попу - только в массиве $GLOBALS['language']
Ибо он единственный, кто в обоих функциях используется, и мы туда можем что-то приписать своё. Да, я понимаю, что это некрасиво всё, массив ведь содержит настройки языка, но что делать? Думаю, лучше пусть так будет, пока разработчики вьюса не решат проблемы с кешем, чем выключить его и терять производительность сайта.
Если вы всё ещё со мной, то объясню реализацию. Например, в своём модуле в хуке hook_views_pre_view прописываем:
$cache = $view->display_handler->get_option('cache');
if ($cache['type'] == 'time') {
$GLOBALS['language']->views_key_data = $_GET;
}
}
else {
unset($GLOBALS['language']->views_key_data);
}
И таки работает. Погонял - вроде проблем не увидел. Посмотрите тоже, кому интересно. Вдруг найдёте побочные эффекты, но
по идеебыть не должно.Всем успехов!
У меня проблема роста таблиц оказалась из-за модуля Fivestar, его отключил и удалил. Теперь даже не парюсь на счет таблиц, кеш максимум 30 мб.
WebFamily, извините меня, конечно, но Вы малость не по теме уже второй пост пишете. Мы хотим ВКЛЮЧИТЬ кеш и чтобы он корректно работал. И это касаемо конкретно модуля Views. К чему Ваши сообщения - совершенно не ясно...
присоединяюсь к вопросу. Есть вьюха c exposed кол-вом товаров на странице. Если включить кеширование, то фильтр кол-ва товаров не работает. Как заставить их дружить?
Поднять глаза вверх.
Честное слово вот, извините, конечно. Но для кого я выше написал всё это?
Правильно я понял, что весь код модуля будет выглядеть так:
<?phpfunction mymodule_views_pre_view(){
if ($view->display_handler->uses_exposed()) {
$cache = $view->display_handler->get_option('cache');
if ($cache['type'] == 'time') {
$GLOBALS['language']->views_key_data = $_GET;
}
}
else {
unset($GLOBALS['language']->views_key_data);
}
}
?>
?
И почему бы не запостить ишью на орге? Там и потестят массово, думаю.
Да, всё верно.
Просто решение некрасивое... Я уверен, что они и сами знают, что делать. Вот почему не делают - это другой вопрос. Да и на скорую руку решение. Меня оно пока, в общем-то, устраивает. Работает - это главное.
А 6 ветку вьюсов не перестали ли уже развивать вовсе?
Поставил код - пару дней на тестирование, отпишусь о результатах.
Спасибо за Ваши старания в любом случае!
Да ну, рано ещё
И судя по dev-версиям - порядок.
Ага, спасибо и Вам! Ждём.
Я столкнулся с похожей проблемой, но решил, что править буду все-таки ядро, а не обертки
Что в get_reuslts_key, что в get_output_key испольузется serialize($key_data), т.е. внутренний формат массива можно менять.
В итоге, не мудрствуя лукаво, просто добавил еще один ключ 'q' => $_GET['q']в массив в get_results_key (аналогично и в get_output_key)
<?php $key_data = array('build_info' => $this->view->build_info,
'roles' => array_keys($user->roles),
'super-user' => $user->uid == 1, // special caching for super user.
'language' => $GLOBALS['language'],
'q' => $_GET['q'],
);?>
С точки зрения высоких идеалов меня может и линчуют за такую правку, с точки зрения оптимизации я вижу, что для синонимов и переадресаций на одно и то же будут разные кеши, но оно работает. И это главное для меня
Я выше привёл это же решение, только при этом сам вьюс хакать не нужно. Ибо когда Вы его обновите - забудете про свою правку и останетесь опять без кеша.
К сожалению, у меня ничего не изменилось - также остались глюки в случае раскрытых фильтров и сортировке по заголовкам таблицы вьюшной.
Странно
А у меня и по сей день всё нормально... Даже не знаю 
но лучше написать свой плагин кеширования (extends views_plugin) с более очевидной логикой
Полностью поддерживаю
Но мне лично уже это не нужно - проект ушёл на семёрку.
так и на семерке все еще нет кеша для вьюх с экспозед фильтрами
Блин, забыл написать - использую в паре с Search API
Там как раз свой плагин кэша сделан 
хм, а он с экспозед работает? у меня нет