По тегам нет наверное, но мне это и не надо ;) Чтоб по тегам искать, это мне кажется проще свое написать.

Тэги товара лежат в отдельных таблицах, по ним поиска не будет. Как и по другим полям товара, ибо компонент не поддерживает MS2.

Искать будет только по ТВ и стандартным полям ресурса MODX — pagetitle, longtitle и т.д.

А по тегам minishop2, SimpleSearch умеет искать?

добавил, все равно по тегам не ищет (
Сделал так:

[[!mSearch? &indexer=`1` &includeTVs=`1` &includeTVList=`new,color,tags` &limit=`0`]]

Если кто-то уже написал фильтры для miniShop2, который вышел 20 дней назад — то я не в курсе.

Переписывание mSearch + mFilter в планах, но пока не до того.

Он с ним не работает ?)
а можешь подсказать как мне реализовать фильтры ??? Может есть какой-то другой компонент. Без этого никак вообще. ужс

Посмотрел в код исходного шаблона, там содержимое page_about заранее есть. У вас на странице оно есть, или как вы собираетесь подгружать контент?

Заглянул и побежал серв проверять :) на 512 7 ядер стоит… Спасибо за статю.

Нет.

Кстати, по 2му пункту — можно брать хэш от имени сниппета и строковых представлений имён параметров и их значений (предварительно отсортировав имена параметров по имени, например). Тогда да — мы будем однозначно идентифицировать каждый вызов каждого сниппета. Но ИМХО — это ещё одна совершенно лишняя нагрузка. Хотя идея рабочая.

modx.pro/help/395/

> если только не прописывать работу с заголовками каждому используемому сниппету.
Именно. Но это такое не благодарное дело получится.
Но если уж заморачиваться, то логика должна быть примерно такой:
КАЖДЫЙ сниппет при КАЖДОМ своём выводе должен сверять ПРЕДЫДУЩУЮ выводимую им информацию с ТЕКУЩЕЙ выводимой им информацией. Т.е. надо завести отдельную таблицу и хранить там, к примеру, md5 от выводимых сниппетом данных и дату этих данных. И если md5 от текущих данных отличается от md5 из таблицы, то перезаписывать md5 и дату.
Потом на то же событие «OnLoadWebDocument» проверять количество сниппетов, в которых данные изменились с последнего вызова (эту переменную можно держать в сессии и каждый сниппет при необходимости инкрементирует её). И если это количество отлично от нуля, то отдавать 200. Иначе отдавать 304 (естесственно, не забыть проверять и дату последнего редактирования ресурса, как в текущем варианте).

НО:
1. Мы здесь теряем одно преимущество этого заголовка — снижение реальной нагрузки на сервер (это при достаточно годной посещаемости). Ведь фактически нагрузка увеличится! Это +1 запрос к вызову каждого сниппета и, если использовать md5, то ещё и на хэширование ресурсы тратить.
2. Как определить уникальность вызова сниппета и однозначно идентифицировать его в нашей специальной таблице?

В принципе, можно написать сниппет-обёртку (как getPage), который будет делать всю эту грязную работу. Ну и плагин доработать слегка.
Для поисковиков будет хорошо, да. Эту задачу этот сниппет+плагин будет решать.

Но со вторым «НО» из списка выше пока не понятно. Да и популярностью данное решение пользоваться не будет — оно сложно для понимания и оборачивать нужно КАЖДЫЙ вызов КАЖДОГО сниппета, что, естесственно, подавляющее большинство делать не будет.

Да и кому это вообще надо-то?))) Нафига я всё это писал? xDD

Примерно вот так:

<form class="" method="get" action="[[~[[*id]]]]">

<select name="query" value="[[+mse.query]]">

[[!GetResources?

&tpl=`select-tpl`

&parents=`50`

&depth=`0`

&includeTVs=`1`

&processTVs=`1`

&tvPrefix=``

&sortby=``

&sortdir=``

&sortbyTV=``

&sortdirTV=``

&showHidden=`1`

&hideContainers=`0`

]]

<input type="submit"  value="Подобрать">

</form>

<div id="mItems" ></div>

<p>[[$mFilter]]</p>

Не знаю, не подключал.

Судя по записям в логе — что то не так с ключами. Можно еще попробовать разлогиниться с сайта и почистить кэш бразуера. Настройки кэшируются в сессии, это может помешать как-то.

Правильно, ничего удивительного, я бы на твоем месте еще реже отвечал.

Это оттого, что нужно — &includeTVs=`1`

Ну и еще бы &limit=`0` добавить, чтобы индексировались не 10, а все товары.

Нужно еще учитывать, что Василий работает часов 10 — 12, а потом отвечает на вопросы, в свободное время.

Нет ничего удивительного, что на неинтересные вопросы отвечать не интересно.

Я не имел ввиду, не справедливость ))) просто очень часто встречал вопросы за которые — получи «нагоняй», по сути правильно, но в грубых формах и без ссылок на доки, да, очень много спецов которые хотят получить все готовое и т.д…
Общая суть — этот сайт так или иначе поддерживает уровень не дилетантов и такие вопросы как — «Можно пошаговую инструкцию по применению данного снипета.» почти всегда игнорируются.
Василий пойми правильно — я за такие методы. )))

Глюк корзины может быть только от глюка сессии.

А глюк сессии может быть либо от php-apc, либо оттого, что браузер ориентируясь на заголовки что-то не грузит.

Я одно время интересовался этой темой и пришел к выводу, что она не перспективна. Время и силы лучше потратить на оптимизацию сервера и скриптов, чем на глючное кэширование.

Давайте объясню как я делаю, наверное сразу будет ясно в чем соль.

1) качаю, ставлю mSearch из репозитория

2) на одной из страниц сайта пишу в контент документа:

[[!mSearch?&indexer=`1`&includeTV=`1`&includeTVList=`new,color,tags`]]

3) захожу на страницу, вижу:

Indexed: 10 resources from 10, time: 0.0653119087219

4) создаю страницу — поиск. в нее добавляю вызов сниппета:

[[!mSearch]]

5) добавляю на страницу поиск форму:

<form action="[[~[[*id]]]]" method="post"><input type="text" name="query" value="[[+mse.query]]" /> <input class="btn btn-success" type="submit" value="Искать!" /></form>

Дак вот, если post меняю на get — редиректит на главную страницу.

Соль в том, что сейчас поиск заработал ) еще раз все повторил. НО вопрос актуален.У меня не проиндексировались поля color,tags (из minShop2). Хотя я вызвал индексирование же с правильными параметрами или как?