RGB

filterpro.min.js найдите $(".pagination .links a").live("click", (function () { var a = $(this).attr("href"); var b = a.match(/page=(d+)/); $("#filterpro_page").val(b[1]); doFilter(false); return false })); и измените его на $(".pagination .links a").live("click", (function () { var a = $(this).attr("href"); var b = a.match(/page=(d+)/); $("#filterpro_page").val(b[1]); doFilter(false); $('html, body').scrollTop(0); return false })); Насчет сортировки - так сортируются атрибуты, а не группы атрибутов. Изменения в шаблон для вывода ОТ .... До ... следовало бы внести так: <table> <tr> <td>От</td> <td><input class="price_limit" type="text" name="min_price" value="-1" id="min_price"/></td> <td>до</td> <td><input class="price_limit" type="text" name="max_price" value="-1" id="max_price"/><?php if($symbol_left){ echo $symbol_left;} else {echo "<td>".$symbol_right."</td>";}?></td> </tr> </table>

Если кому еще пригодится (вообще мне кажется это стоит добавить в релиз):

А почему при использовании пагинации (переключаемся с 1-й на 2-ю страницу например) окно не прокручивается вверх и показывает низ 2-й страницы? Точнее я понимаю почему, но можно это как-то исправить?

Оставь надежду, всяк сюда входящий :) Лучше обратитесь к этому модулю.

А какая тогда логика работы фильтра в демке? Я выбирают в блоке Radio атрибут Medium (1), при этом в блоке выше в No. of Cores скрываются (становятся неактивными) атрибуты выше Все ясно, выборка учитывается при фильтрации по опциям, а не по атрибутам.

К вышенаписанному моему сообщению - может я чего-то не понимаю, но в демке фильтра уже сейчас учитывается выборка :huh: Это я неправильно что-то делаю у себя, или прямо в данный момент идет внедрение это супер-полезной фичи?

Такой вопрос (или скорее предложение) по логике фильтрации. При выборе метода фильтрации атрибутов "И" вместо "ИЛИ" - можно ли как то скрывать те атрибуты, товаров с которыми нет в текущей выборке? По аналогии с фильтрацией по цене - когда пользователь выбирает диапазон от 100 до 110 долларов например, все атрибуты, товары с которыми не вписываются в этот диапазон, недоступны для выбора (чекбоксы неактивны). Можно ли как-то реализовать такой же механизм не только для ценовой сортировки, но и для всех остальных сортировок? Сейчас, если выбрать что-то, фильтр не учитывает выборку и выводит все вот так: А хотелось бы, чтобы выбор пользователя учитывался и все выводилось вот так (92, 96 и 96.5 Дб неактивны, поскольку товаров с выбранным частотным диапазоном и с таким давлением нет в базе):

А планируется ли как-то реализовать диапазоны фильтрации для цифровых значений? В этой теме уже поднимался такой вопрос. Чтобы было не так: А так: Или в идеальном случае, слайдером, как с ценами.

Бинго :-)

Видимо, остальным эту тайну доверить нельзя было? :-) Что-то не помогло, все равно такая картина:

Спасибо, действительно все гениальное - просто :-)

Ну а зачем его устанавливать при том, что это можно автоматизировать использованием функции natsort, если сортировка реализуется через пхп? Мне кажется было бы проще использовать человеческую сортировку, а не машинную.

Спасибо за оперативные исправления, а как дела с естественной сортировкой? Ведь человеку привычнее видеть результат выборки не такой: А такой:

Итак, путем проб и ошибок было обнаружено, что убрать нелогичный подсчет товаров, который не учитывает выбранных фильтров, можно следующим образом. В файле filterpro.min.js нужно закомментировать цикл проверки условия if (g.totals_data), строки 58-134. Вроде бы способ безболезненный. Но следует отдать должное товарищу freelancer, который, как истинный партизан, очень хитро запрятал этот подсчет внутрь яваскрипта, видимо чтобы враги не сразу догадались, как его убрать :) Но вопросы насчет ненужного вывода блока фильтра в пустых категориях (или в родительских, которые содержат много дочерних с товарами, но сами по себе пустые) и вывода валюты рядом с полями ввода ценового диапазона остаются открытыми.

Та зачем мне его скрывать везде? Я просто хочу, чтобы он не путал покупателей, не портил дизайн и не вводил их в состояние недоумения: "Зачем это владельцы магазина выводят тут нолики с каким-то фильтром?" Товарищ freelancer, пожалуйста, отреагируйте на мой вопрос - неужели не очевидно, что такая картинка выглядит как минимум странно?

А на мой вопрос ответ будет? Как убрать подсчет товаров? И как убрать ползунок цен в категориях без товаров? Не понимаю, почему это никого не волновало за столько времени существования фильтра.

http://forum.opencart.com/viewtopic.php?f=20&t=71244&p=316437

Аналогичный вопрос - зачем выводить слайдер цен в категориях, где нет товаров? И еще пожелание - добавить текущую валюту рядом с полями, а то сортировка от 100 до 10000 ЧЕГО? Попугаев?) Килограмм? Долларов? А может рублей?И еще - можно как-то безболезненно убрать подсчет количества товаров? Но не из шаблона, а вообще чтобы эта операция не выполнялась и не расходовала ресурсы? Объясню почему - без динамического обновления эти цифры бесполезны, если покупатель выбрал галочку в одной группе атрибутов, то цифры в другой группе по логике вещей должны измениться с учетом того, что уже выбрано ранее, а поскольку они в текущей версии не меняется, то хочется их вообще убрать, чтобы на них не тратились ресурсы и чтобы они не вызывали у покупателя когнитивный диссонанс. Возможно как-то описать процесс правильного удаления этой функции?

Так что мешает поднять в настройках модуля блок покупателя над блоком доставки? Чтобы было как-то так:{left_column}{shipping}{customer}{/left_column}Дублировать ничего не надо! Вы и так нарушаете один из главных принципов юзабилити - не удивительно, что до всех слабо доходит. Человек воспринимает информацию сверху вниз и слева направо, а у вас можно голову сломать, пока поймешь что и как)

К сожалению это неизбежная ситуация на опенсорс-проектах, всегда найдутся недовольные любители теорий заговора)

Как только - так сразу :)Просветите, а что принципиально нового и необходимого вы видите в версии 1.5.4.1, чего нет в более старых версиях?

А вы точно из OC Team? :)Уже эта тема обсосана и разжевана многократно. Как вариант (возможно не лучший, но меня устраивает): В файле system/library/response.php, метод output(), в самом начале метода добавить строку if (!defined('HTTP_CATALOG')) $this->output = str_replace('index.php?route=common/home', '', $this->output);и index.php?route=common/home будет вырезан везде.

Уважаемый ingenerks, не могли бы вы ответить, подписывали ли вы договор с автором модуля насчет моментальных исправлений обнаруженных у вас несовместимостей в работе с другими модулями? Или быть может товарищ freelancer поклялся на библии насчет точных сроков выхода версии фильтра без аякса, после чего скрепил клятву своей кровью? И еще одна просьба - не могли бы вы не "тыкать" в общении со мной? Думаю, объяснять причины моей просьбы к вам не нужно, ведь вы человек, без сомнения, культурный, и элементарные нормы приличия в общении с незнакомыми людьми вам наверняка знакомы?

Все очень просто - хотите моментальный фикс под вашу связку модулей? Платите 1К $. Хотите недельку ждать - цена вопроса уже 100$, и так далее. Мне почему-то кажется, что freelancer не сидит все это время в баре, попивая пивко и посмеиваясь про себя из-за того, какие у вас проблемы вызывает его модуль, у него наверняка есть другие занятия и работа, помимо поддержки своих модулей. Вы заключали договор на моментальное обслуживание? У вас юридически правильный контракт на поддержку 24х7? Нет? Какие могут быть претензии тогда? Пользуйтесь другими модулями или ждите, когда до вас дойдет очередь в обслуживании. Толковый разработчик побольше вас заинтересован в том, чтобы о его работе были положительные отзывы, поэтому не в его интересах вас подводить или портить вам жизнь, т.е. если есть задержка в исправлениях, значит на то есть причины.

Вы простите, что вклиниваюсь, но мне кажется разумным для всех разработчиков применять следующий подход - цена на модуль с поддержкой и апдейтами должна быть выше раза в 2-3, чем цена за модуль без дальнейшей поддержки (по сути это как с реальными товарами, когда некоторые магазины за продленную гарантию требуют дополнительную плату). Это освободит время разработчикам и позволит совершенствовать модули, а не исправлять десятки неизбежных косяков, возникающих из-за несовместимости с другими модулями. У меня вот например все модули (пока что) сразу работали, соответственно на меня разработчики не потратили ни секунды времени, а у некоторых юзеров (я не лично о вас, ingenerks, а вообще) ошибки возникают постоянно и на их исправление уходит куча времени авторов модулей (если автор конечно не морозиться постоянно), но при этом мы платим одну и ту же небольшую сумму. Разве это справедливо по отношению к разработчикам?