да, так и пришлось сделать, только через запрос к базе делал товар видимый.
PS> При переносе товара дропом, подкатегории открываются если свернутые, что не есть хорошо, если развернуть то не удобно скролить оч. много. Короче гемор еще тот.
И притом у линода не просто процы за 200-300 баксов как у отечественных хостеров, а покруче. Удалось мне потестировать на выходных, сейчас у них есть такая услуга — регся и 4 часа теста бесплатно. Если не ошибаюсь у них процы Intel Xeon E5-2650 или где то рядом стоимостью больше $1000. Ставил gentoo linux, на которой собрал gcc-4.6.3 за 25 мин с оперативкой 512. На впс отечественных для этого нужно 1-2 часа и желателен больший объём памяти… Да и радует готовый набор ядер, в том числе и свежих. У нашего хостера вторую неделю жду пока они с ядром разберуться, и то носом пришлось тыкать где ковырять…
Вобщем, совсем другой уровень услуг по сравнению с нашими, даже демпинговые цены которых перечеркиваются неадекватной техподдержкой…
Кстати, по 2му пункту — можно брать хэш от имени сниппета и строковых представлений имён параметров и их значений (предварительно отсортировав имена параметров по имени, например). Тогда да — мы будем однозначно идентифицировать каждый вызов каждого сниппета. Но ИМХО — это ещё одна совершенно лишняя нагрузка. Хотя идея рабочая.
> если только не прописывать работу с заголовками каждому используемому сниппету.
Именно. Но это такое не благодарное дело получится.
Но если уж заморачиваться, то логика должна быть примерно такой:
КАЖДЫЙ сниппет при КАЖДОМ своём выводе должен сверять ПРЕДЫДУЩУЮ выводимую им информацию с ТЕКУЩЕЙ выводимой им информацией. Т.е. надо завести отдельную таблицу и хранить там, к примеру, md5 от выводимых сниппетом данных и дату этих данных. И если md5 от текущих данных отличается от md5 из таблицы, то перезаписывать md5 и дату.
Потом на то же событие «OnLoadWebDocument» проверять количество сниппетов, в которых данные изменились с последнего вызова (эту переменную можно держать в сессии и каждый сниппет при необходимости инкрементирует её). И если это количество отлично от нуля, то отдавать 200. Иначе отдавать 304 (естесственно, не забыть проверять и дату последнего редактирования ресурса, как в текущем варианте).
НО:
1. Мы здесь теряем одно преимущество этого заголовка — снижение реальной нагрузки на сервер (это при достаточно годной посещаемости). Ведь фактически нагрузка увеличится! Это +1 запрос к вызову каждого сниппета и, если использовать md5, то ещё и на хэширование ресурсы тратить.
2. Как определить уникальность вызова сниппета и однозначно идентифицировать его в нашей специальной таблице?
В принципе, можно написать сниппет-обёртку (как getPage), который будет делать всю эту грязную работу. Ну и плагин доработать слегка.
Для поисковиков будет хорошо, да. Эту задачу этот сниппет+плагин будет решать.
Но со вторым «НО» из списка выше пока не понятно. Да и популярностью данное решение пользоваться не будет — оно сложно для понимания и оборачивать нужно КАЖДЫЙ вызов КАЖДОГО сниппета, что, естесственно, подавляющее большинство делать не будет.
Да и кому это вообще надо-то?))) Нафига я всё это писал? xDD
Судя по записям в логе — что то не так с ключами. Можно еще попробовать разлогиниться с сайта и почистить кэш бразуера. Настройки кэшируются в сессии, это может помешать как-то.
Всего 125 661 комментарий
Тогда нужно было их сразу вносить в нужные категории =)
PS> При переносе товара дропом, подкатегории открываются если свернутые, что не есть хорошо, если развернуть то не удобно скролить оч. много. Короче гемор еще тот.
Ну или перезалить их заново, только сразу в нужные категории.
Вобщем, совсем другой уровень услуг по сравнению с нашими, даже демпинговые цены которых перечеркиваются неадекватной техподдержкой…
Искать будет только по ТВ и стандартным полям ресурса MODX — pagetitle, longtitle и т.д.
Сделал так:
Переписывание mSearch + mFilter в планах, но пока не до того.
а можешь подсказать как мне реализовать фильтры ??? Может есть какой-то другой компонент. Без этого никак вообще. ужс
Именно. Но это такое не благодарное дело получится.
Но если уж заморачиваться, то логика должна быть примерно такой:
КАЖДЫЙ сниппет при КАЖДОМ своём выводе должен сверять ПРЕДЫДУЩУЮ выводимую им информацию с ТЕКУЩЕЙ выводимой им информацией. Т.е. надо завести отдельную таблицу и хранить там, к примеру, md5 от выводимых сниппетом данных и дату этих данных. И если md5 от текущих данных отличается от md5 из таблицы, то перезаписывать md5 и дату.
Потом на то же событие «OnLoadWebDocument» проверять количество сниппетов, в которых данные изменились с последнего вызова (эту переменную можно держать в сессии и каждый сниппет при необходимости инкрементирует её). И если это количество отлично от нуля, то отдавать 200. Иначе отдавать 304 (естесственно, не забыть проверять и дату последнего редактирования ресурса, как в текущем варианте).
НО:
1. Мы здесь теряем одно преимущество этого заголовка — снижение реальной нагрузки на сервер (это при достаточно годной посещаемости). Ведь фактически нагрузка увеличится! Это +1 запрос к вызову каждого сниппета и, если использовать md5, то ещё и на хэширование ресурсы тратить.
2. Как определить уникальность вызова сниппета и однозначно идентифицировать его в нашей специальной таблице?
В принципе, можно написать сниппет-обёртку (как getPage), который будет делать всю эту грязную работу. Ну и плагин доработать слегка.
Для поисковиков будет хорошо, да. Эту задачу этот сниппет+плагин будет решать.
Но со вторым «НО» из списка выше пока не понятно. Да и популярностью данное решение пользоваться не будет — оно сложно для понимания и оборачивать нужно КАЖДЫЙ вызов КАЖДОГО сниппета, что, естесственно, подавляющее большинство делать не будет.
Да и кому это вообще надо-то?))) Нафига я всё это писал? xDD
Судя по записям в логе — что то не так с ключами. Можно еще попробовать разлогиниться с сайта и почистить кэш бразуера. Настройки кэшируются в сессии, это может помешать как-то.