[EVO] evoSearch - поиск по сайту с учетом морфологии и релевантности

Компонент evoSearch — поиск по сайту с учетом морфологии (словоформы на основе словарей phpMorphy и некоторых идей по реализации самого полнотекстового поиска).

Скачать можно тут, там же инструкция по установке, использованию и реквизиты для доната для желающих :))

Состоит из 2 взаимосвязанных элементов:
— плагин — индексирует ресурсы (в том числе прямо заданные ТВ параметры), преобразует их в базовую форму
— сниппет — предназначен для вывода результатов поиска на основе словоформ слов из поисковой фразы и возможностей полнотекстового поиска MySQL с учетом релевантности.

Работает в связке с DocLister (рекомендуется) либо Ditto (не особо тестировал, но должно почти все работать, кроме доп.поиска в случае пустого результат для fulltext-search) для вывода результатов поиска.

131 комментарий

avatar
Насколько целесообразно расширять site_content?
может как вариант вынести в отдельную таблицу? все равно на сколько понял создаем специальный текст для поиска?
avatar
Не очень целесообразно, целесообразнее даже наверно сделать отдельную таблицу :)
Хочется просто для начала какого-то теста от пары человек насколько это вообще нужно и насколько это быстро работает хотя бы на паре тысяч документов
avatar
есть проект на 17 000 документов
сейчас там поиск на базе DocLister

Обрабатываем слова что б убить окончания
foreach($tmp as $word){
    $len = mb_strlen($word, 'UTF-8');
    switch(true){
        case ($len > 3 && $len <= 6):{
            $query[] = mb_substr($word, 0, -1, 'UTF-8')."*";
            break;
        }
        case ($len > 6 && $len <= 9):{
            $query[] = mb_substr($word, 0, -2, 'UTF-8')."*";
            break;
        }
        case ($len > 9):{
            $query[] = mb_substr($word, 0, -3, 'UTF-8')."*";
            break;
        }
        default:{
			break;
        }
    }
}


Собственно настройка параметров DocLister
'selectFields' => "c.*, (
	    (10 * MATCH (c.introtext) AGAINST ('".$qQeury."' IN BOOLEAN MODE)) +
		(9 * MATCH (c.pagetitle) AGAINST ('".$qQeury."' IN BOOLEAN MODE)) +
		(8 * MATCH (c.longtitle) AGAINST ('".$qQeury."' IN BOOLEAN MODE)) +
		(7 * MATCH (c.content) AGAINST ('".$qQeury."' IN BOOLEAN MODE))
	) as relevant,
		(CASE
			WHEN MATCH (c.introtext) AGAINST ('".$qQeury."' IN BOOLEAN MODE) THEN 'introtext'
			WHEN MATCH (c.pagetitle) AGAINST ('".$qQeury."' IN BOOLEAN MODE) THEN 'pagetitle'
			WHEN MATCH (c.longtitle) AGAINST ('".$qQeury."' IN BOOLEAN MODE) THEN 'longtitle'
			WHEN MATCH (c.content) AGAINST ('".$qQeury."' IN BOOLEAN MODE) THEN 'content'
			ELSE ''
		END) as field",
	'addWhereList' => "(
		MATCH (c.introtext, c.pagetitle, c.longtitle, c.content) AGAINST ('".$qQeury."'  IN BOOLEAN MODE)
	) AND c.searchable = 1",
avatar
Тогда уж лучше не произвольно отсекать несколько букв с конца в зависимости от слов, а пользоваться стеммером для извлечения корней :)
Да и в вызов Доклистера добавить сортировку по общей релевантности.

С другой стороны хотя полнотекстовый поиск и так использует стемминг, то и особого смысла в отсекании окончаний особо нет.
В phpMorphy же ищется в том числе по разным словоформам и вроде как точнее результат по отзывам (тот же mSearch его использует :)))

п.с. я бы кстати попробовал убрать IN BOOLEAN MODE, т.к. в этом случае сама релевантность, которая рассчитывается MySQL сбрасывается в 0 или 1 и не учитывается. Это конечно ускоряет, но релевантность нарушает, т.к. в этом случае не отдается ее расчетное значение, а просто отдается 1 или 0 (есть или нет релевантность).
Комментарий отредактирован 2014-07-11 17:34:35 пользователем webber
avatar
«поиск на базе DocLister»
Dmi3yy а купить это решение у вас можно? ;) очень нужно.
Комментарий отредактирован 2014-07-13 14:14:03 пользователем diosmedia
avatar
Дык evoSearch тоже в связке с DocLister работает. В чем сложность использовать данное решение?
avatar
Так же поддерживаю лучше уже использовать evoSearch
avatar
Вот и я думаю, не сильно ли раздуется таблица site_content
avatar
От двух дополнительных полей да еще и являющихся fulltext-индексом — не думаю что «сильно раздуется». Хотя если будут данные объектные что «раздувается», то можно без труда вынести эти два поля и в отдельную таблицу :)
avatar
Дописал экстрактор с подсветкой. Алгоритм вырезания нужного куска конечно достаточно самопальный и местами не сильно близкий к совершенству, но результат получается следующий (вполне себе приличный, по крайней мере на опробованных нескольких десятках запросов):



ссылка на большую картинку
Комментарий отредактирован 2014-07-12 10:32:42 пользователем webber
avatar
Собирался я помочь с тестированием, да не получается — поэтому решил помочь донатом (:
avatar
Потестировал и решил перенести условия выборки прямо в DocLister (так быстрее, чем промежуточная выборка id).
В общем результаты тестов примерно следующие (тестил сразу на огромном по меркам MODx сайте с настройками, когда в AliasListing заносятся только папки).

Итак исходные данные:

количество ресурсов — 329,974шт — 616.0 MiB
ТВ — 659,886 шт — 336.1 MiB, в том числе anons (reachtext) — 329,931штук и почти весь объем, т.к. остальные строки или чекбоксы.

ыборка из категории 50 000 штук размером
Постраничный вывод на 10 штук DocLister (без всяких условий) —
<!--  Mem : 6.25 mb, MySQL: 0.9688 s, 49 request(s), PHP: 0.1406 s, total: 1.1094 s, document from database. --> первая страница
<!--  Mem : 6 mb, MySQL: 0.6719 s, 47 request(s), PHP: 0.1406 s, total: 0.8125 s, document from database. --> вторая страница
<!--  Mem : 6 mb, MySQL: 0.9062 s, 20 request(s), PHP: 0.0781 s, total: 0.9844 s, document from database. --> последняя страница
<!--  Mem : 2 mb, MySQL: 0.0156 s, 0 request(s), PHP: 0.0156 s, total: 0.0312 s, document from cache. --> первая страница


Проиндексировано 25,560 ресурсов вместе с ТВ анонс (есть у каждого ресурса) — медленное это дело, но это делается один раз, потом индексируется каждый документ отдельно при сохранении
размер таблицы site_content практически не изменился, даже стал меньше (611.8 MiB, было 616.0 MiB) — хотя возможно это связано с однотипными записями

По запросу прямые накладные профили найдено всего 25560. Показано 10, c 1 по 10
<!--  Mem : 16 mb, MySQL: 1.8281 s, 35 request(s), PHP: 0.1562 s, total: 1.9844 s, document from database. -->


По запросу о компании найдено всего 1. Показано 1, c 1 по 1

<!--  Mem : 16 mb, MySQL: 1.2344 s, 26 request(s), PHP: 0.1250 s, total: 1.3594 s, document from database. -->


По запросу проект освещения найдено всего 8. Показано 8, c 1 по 8

<!--  Mem : 16 mb, MySQL: 1.2500 s, 30 request(s), PHP: 0.1094 s, total: 1.3594 s, document from database. -->


ЭТо все с экстрактором, без него скорость практически не изменилась (так что отключать его смысла нет, разве что по дизайну).

В общем для такого сайта результаты очень даже хорошие. Разговоры про то, что модх тянет только 5000 документов я думаю тоже можно прекращать :)))
Комментарий отредактирован 2014-07-14 09:24:15 пользователем webber
avatar
Еще было бы интересно узнать на каком хостинг тестируешь так как скорость можно еще повысить средствами сервера
avatar
Да это денвер. Можно еще конечно каким-нибудь акселератором разогнать. Хотя тут почти все время уходит именно на запрос MySQL с полнотекстовым поиском (вернее даже на запрос количества (SELECT count(*)...) который идет сначала в DocLister).
Страницы некэшируемая, т.к. смысла кэшировать запросы нет (только место занимать).
avatar
тогда вообще изумительный результат ибо как показывает практика Денвер не самый быстрый
avatar
Ну результат в том смысле нормальный, что он не сильно критично отличается от обычной выборки без всяких условий (список товаров в категории например), хотя я и поставил глубину 10 уровней, т.к. что-то не нашел где в DocLister можно обойти необходимость ставить или parents+depth или documents :))

Опять же на мелких сайтах эта разница вообще не заметна.
Комментарий отредактирован 2014-07-14 10:36:50 пользователем webber
avatar
не нашел где в DocLister можно обойти необходимость ставить или parents+depth или documents :))
* По умолчанию depth используется для 1 уровня вложенности. Но даже если указать 10, то это не значит, что будет выполняться 10 раз запрос для получения дочерних документов, т.к. DocLister не дурак. Хотя да, в текущей версии лишних пару раз сделает декремент $depth в цикле…
* Задавать idType — хорошая практика, т.к. это придает однозначности при построении SQL запросов
* С версии 1.4.4 имеется возможность совмещать выборку parents и documents, что позволяет к результатам выдачи подмешать предопределенный список документов
Комментарий отредактирован 2014-07-17 12:51:06 пользователем Agel_Nash
avatar
Я имел в виду немного другое. В настоящий момент необходимо обязательно либо задать &documents (список id) либо &parents+&depth (родитель плюс глубина). Т.е. нет возможности просто через selectFields и addWhereList задать в обход какое-то условие (в данном случае MATCH...AGAINST).

Все равно нужно принудительно задавать в вызове DocLister дополнительно &parents=`0` &depth=`10` (к примеру) — иначе оно просто автоматом присвоит &depth=1 и &parents=0 и ничего не найдет :) Ну а это влечет за собой соответсвенно рекурсивный поиск всех парентов глубиной до 10 уроней (на производительности не особо отражается, но факт есть факт).
Комментарий отредактирован 2014-07-17 14:14:38 пользователем webber
avatar
Теперь понял. Да, была такая необходимость пару раз. Добавлю в скором времени новый параметр;-)
Комментарий отредактирован 2014-07-17 14:42:30 пользователем Agel_Nash
avatar
в документации написанно:
<code>для вывода результатов [!evoSearch? &tpl=`evoSearch`!], </code>
Но пример чанка отсутствует :)

я бы предложил его создать в папке инсталл )
так будет проще и удобней
Комментарий отредактирован 2014-07-16 14:02:45 пользователем Dmi3yy
avatar
Знать бы еще пример как оформить чтоб чанк получился :)))

Сам то чанк evoSearch (название как в примере, можно и любое другое, т.к. это просто параметр tpl для DocLister) нехитрый вроде
<div class="search_title"><a href="[+url+]">[+pagetitle+]</a></div>
<div class="search_extract">[+extract+]</div>
avatar
пример чанка можно тут глянуть:
github.com/dmi3yy/modx.evo.custom/tree/master/install/assets/chunks
avatar
avatar
Почему то не работает вывод результатов, сборка modx 1.0.14 — d6.14 c git.

Форма поиска простейшая:

<form action="[~8~]" method="post">
    <input type="text" value="" class="find" name="search" />
    <input type="submit" value="Найти" class="find-butt"/> 
</form>


evoSearch ставил из Extras, там последняя версия с git. DocLister также обновлён до последней версии. Действия с настройкой плагина полностью по инструкции.

Теперь самое интересное:

При сабмите формы почему то пропадает GET из url-а, т.е. переходит на страницу результатов site.ru/result.html, вместо
site.ru/result.html?search=поисковый запрос

Вывод результатов:
[!evoSearch? &tpl=`evoSearch`!]

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

p.s. Сделал отправку той же формы на страницу с вызовом Ditto + экстендер search, и url становится таким как надо — result.html?search=поисковый запрос

Может есть какие либо тонкости с настройкой? Или я где то туплю :)
avatar
Ну как минимум странно в «простейшей форме» задавать method=«post», а на выходе ожидать в адресной строке $_GET параметр search :)))
Внимательность — и никаких секретов и подводных камней в документации не будет :)))
avatar
Не не, извиняюсь, это я уже после на AjaxSearch переделывал, скопипастил последнюю форму сюда.

Что такое GET и POST я в курсе :))

Форма была такая:
<form action="[~8~]" method="get">

Просто с ditto get параметр появляется, а с evoSearch пропадает(
avatar
evoSearch не имеет и не может иметь абсолютно никакого отношения к этому параметру. Вы его из формы либо передали либо не передали методом get и третьего тут не дано, т.к. evoSearch сам по себе никуда ничего не редиректит, никаких REQUEST-ов не подменяет и никак с history.js не манипулирует для подмены url :)

Поэтому могу лишь повторить заезженную фразу — дайте доступ к сайту и я найду ошибку :))))
avatar
Как не пытаюсь вывести результаты поиска, получаю всегда одну и ту же фразу: «Ничего не найдено. Смягчите условия поиска». Причем условия уже мягче некуда(
avatar
А в базе все нормально? Может стоит для начала не пытаться вывести результаты, а переиндексироваться? :))

при первом запуске или необходимости переиндексации необходимо выставить параметр «Переиндексировать все» = 1, начальные строки и количество строк за сеанс устанавливаются в зависимости от возможностей вашего хостинга (например 0 и 10 000 соответственно — проиндексирует строки с 0 в количестве 10 000 штук в БД необходимо открыть и пересохранить любой документ для создания события onDocFormSave

для последующей работы установите «Переиндексировать все» = 0, «Строк за сеанс индексировать» = 1 при этом происходит переиндксация только того документа, который сохраняется
avatar
Напишу тут, может кому пригодится, у меня тип поля был text и поэтому не работал поиск. Когда сменил на search все стало отлично.

И сразу вопрос который может заинтересовать не только меня — а можно ли не исключать из поиска ресурсы, а задавать конкретного родителя котором поиск? Например в магазине надо искать только среди товаров, а там еще куча всяких ненужных выдач получится.
avatar
Не вводите людей в заблуждение каким-то мифическим типом search у текстового поля. У вас до сих пор поиск не работает по причине кривых кодировок в базе.
avatar
Именно после смены этого параметра у меня поиск начал работать, но не ищет при коротких запросах, а вот если ввести Квартира или Участок — то нормально выдает результаты, можете сами убедиться.
avatar
И кривых кодировок в базе НЕТ.
avatar
Хотя смена типа действительно не при чем. Может так совпало, но не работало до этого. Когда вернул то не изменилось — по длинным запросам ищет, по трехзначным нет.
avatar
Нормально оно бы искало, если бы на поиск слова «участки» выдавало слово «участок». А сейчас у вас просто нет русского словаря в базе, поэтому ни о какой морфологии и релевантности речи не идет. Просто находит если есть дословное упоминание этого слова.

Ну да хозяин-барин, как говорится. Считаете что у вас все хорошо при неработающих словарях и пустом поле в базе где должны быть словоформы (проиндексированный контент) — не могу же я в этом перечить :))))))
avatar
Я не говорю что оно работает нормально, оно работает ненормально. Но я поставил приложение впервые, по инструкции все сделал и оно не работает. Написал вам, вы я так понимаю не допускаете возможность ошибки самого приложения. Хотя если вы помните я их находил ранее в ваших дополнениях.
avatar
В данном конкретном случае допускать ничего не нужно. Я вижу, что по причине кривых кодировок в базе словарь phpmorphy (он кстати далеко не мой) не может создать словоформы на русском языке (проиндексировать ваш текст). Как результат — поле это у вас пустое.

Вы же вместо простого анализа фактов постоянно выдвигаете какие-то странные версии вроде «надо чтоб был тип поля search» ))))

п.с. в общем смысла продолжать изначально бессмысленную «дискуссию» не вижу.
avatar
Да почему постоянно? Я выше написал на чем основано мое предположение, после исправил. Вся база в utf-8, я вам даже написал вопрос в личку чтобы вы посмотрели сами на нее, но вы игнорируете мой вопрос и то что я пишу что кодировка везде одна и стоят там же другие базы с нормальной работой.

Я не подарки прошу, сразу указал что готов оплатить, но вам видно просто нравится показывать свою значимость.
avatar
Найдена причина пропадания параметра $_GET из строки — это Doclister версии выше 1.4.1 — он при отсутствии результатов поиска зачем то редиректит на страницу без get-параметров.
Для корректной работы необходимо использовать в данный момент DL версии 1.4.1 :)
avatar
Вот спасибо! Баг значит был всё таки, а не меня глючило :))

Надеюсь что это быстро пофиксят в DL.
avatar
Ну баг то как обычно оказался не там, где его искали — не в evoSearch. А пока похоже надо просто закомментить вот эту строчку.
avatar
Уже — 1.4.8
avatar
Спасибо за багрепорты;-)
avatar
Обращайтесь :))) Или мы сами обращаться будем :))
avatar
В общем подводя итоги дискуссии — основная проблема была в том, что на хостинге не была задана кодировка — mb_internal_encoding (в phpinfo() это выглядит как
mbstring.internal_encoding no value no value
). Без этого например Битрикс в принципе отказывается работать, но мы же не такие… мы пытаемся запустить все там, где другие даже не пробуют.
Не заданная кодировка в свою очередь вела к некорректной работы всех мультибайтных строковых функций (вроде mb_strlen, mb_strpos, mb_strtoupper, mb_strtolower) которые используются для высчитывания позиций, обрезания строк, приведения к верхнему или нижнему регистру.

С учетом довольно большой распространенности данной проблемы (не заданной на хостинге напрямую кодировке) пришлось внести дополнительные фиксы 1 и 2 и все стало на свои места :) Попутно был введен дополнительный параметр сниппета, позволяющий задать минимальную релевантность для попадания в поиск при полнотекстовом поиске mysql
Комментарий отредактирован 2014-07-28 15:37:27 пользователем webber
avatar
mb_internal_encoding("UTF-8");

не решило бы проблему?
avatar
вполне возможно, т.к. смысл тот же самый.
avatar
У меня на текущем сайте ~ 6 000 документов

Хостинг позволяет работать скрипт примерно 30 сек. что совпадает с параметром 1000 (за сеанс) — вопрос: как мне правильно сделать настройки? * в первый и последующие разы…
avatar
Первая строка переиндексации, сначала ставите 0. Строк за сеанс индексировать ставите 1000. Сохраняете настройке плагина. Открываете любой документ и нажимаете сохранить. В индекс попало первые 1000 строк с 0 по 1000. Идете опять в плагин, ставите Первая строка переиндексации 1000. Сохранить и опять идете и сохраняете любой документ. В индексе уже будет 2000 строк с 0 по 2000. Идете опять в плагин, ставите Первая строка переиндексации 2000 и продолжаете процедуру до того, пока все ресурсы не попадут в индекс.
avatar
спасибо
avatar
Подскажите, пожалуйста, как добавить в вывод [+extract+] значения тех TV-параметров, которые используются для поиска (в случае нахождения в них поискового запроса)?
avatar
Можете попробовать внести вот эту правку и вызвать сниппет evoSearch с дополнительным параметром &extract_with_tv=`1`
avatar
Есть ли возможность указать сразу все TV-поля для поиска и исключить несколько TV из общего списка? (по аналогии с &withTvs в AjaxSearch)
avatar
Можно перечислить хоть все имеющиеся TV в настройках плагина через запятую — тогда будут индексироваться (и соответственно искать) все ТВ (но это нужно далеко не всегда, т.к. поиск полнотекстовый идет обычно по тексту, а не по полям вроде картинок, multiTV и т.п.).

Если вам нужно внести какие-то изменения в используемые для поиска списки TV, то после таких изменений на рабочем сайте нужно просто переиндексировать весь сайт по новой (чтобы их учесть). О том, как это делается — написано в read.me
avatar
У меня морфологический поиск заработал только после того, как я заменил в сниппете строчку
$words = $this->makeWordsFromText($text);
на
$words = $this->makeWordsFromText(mb_strtoupper($text, 'UTF-8'));
avatar
а подскажите, как сделать чтоб он искал не только по pagetitle, но и по introtext
Спасибо заранее
avatar
Судя по вот этому должно искать в introtext по умолчанию (а также в longtitle и description). Другое дело, что этот текст не выдается в результатах поиска в «подсветке» — там участвует только content.
avatar
а как сделать чтоб выдавался в результате? не обязательно подсветка, надо чтоб просто показывал)
avatar
Не подскажите, установил EvoSearch с репозитария, сейчас выдает такую ошибку при поиску, не подскажите в чем причина?
SSMaker.ru/16ecd4a6/
avatar
Может древний DocLister какой стоит? Куда то съело кусок запроса из параметра selectFields где и было «as rel». Давно ставили?
avatar
Да, уже сделал, и вправду оказался DocLister старой версии
avatar
в параметрах плагина есть настройки:
— Исключить шаблоны
— Исключить ID ресурсов
Но они почему-то игнорируются, все равно в результатах поиска есть исключенные ресурсы.
DocLister ставил с github последний, сборка Modx 1.1b-d7.1.

Может быть нужно какие-то дополнительные действия совершить, чтобы заработало исключение? Или это у меня не работает? Пробовал ставить с нуля несколько раз

P.S. Да, еще заметил, что при выводе на странице пагинации для результатов — перестает выводиться статистика
  • nohc
  • 0
avatar
Пробовал к вызову сниппета добавлять &addWhereList=`c.template NOT IN (1,2,3,4,5,6,7,8,9)` — срабатывает,
а если в файле evoSearch.snippet.php
$eSS->params['addWhereList'] = $query['addWhereList'];

заменить на
$eSS->params['addWhereList'] = "c.template NOT IN (1,2,3,4,5,6,7,8,9)";

то все работает.
avatar
в параметрах плагина есть настройки:
— Исключить шаблоны
— Исключить ID ресурсов
Вы правильно заметили, что это параметры плагина. А плагин у нас делает индексацию. Т.е. перед самой первой индексацией надо настроить эти параметры, чтобы не индексировались данные ресурсы. Соответственно они потом и в вывод попадать не будут.

Удалив вот эту строку

$eSS->params['addWhereList'] = $query['addWhereList'];
— вы просто удалили весь поисковый запрос :)) Вам надо было как минимум делать так, чтобы подцепить этот параметр из вызова сниппета

$eSS->params['addWhereList'] = isset($eSS->params['addWhereList']) && !empty($eSS->params['addWhereList']) ? $eSS->params['addWhereList'] . ' AND ' . $query['addWhereList'] : $query['addWhereList'];
Комментарий отредактирован 2015-04-18 13:01:18 пользователем webber
avatar
А как сбросить индексацию? Не хотелось бы влазить в работу плагина
Комментарий отредактирован 2015-04-18 13:02:30 пользователем nohc
avatar
Судя по вот этому куску оно должно сбрасываться при полной переиндексации. Т.е. поставить в плагине reindex=1 («Переиндексировать все»), поставить побольше «Строк за сеанс индексировать» (несколько тысяч вполне можно) и сохранить любой ресурс. Потом вернуть все назад — reindex=0, строк за сеанс — 1. Ну и плюс попробовать добавить все-таки вот так — github.com/webber12/evoSearch/blob/master/assets/snippets/evoSearch/evoSearch.snippet.php#L46
avatar
Спасибо большое!
Преиндексация не помогла, зато заработало &addWhereList=`c.template NOT IN (1,2,3,4,5,6,7,8,9)` при вызове сниппета
avatar
Странно, что не помогла. А что пошагово вы сделали и на основании чего решили, что не помогла?
avatar
1) Открыл плагин evoSearch, в конфигурации:
— Первая строка переиндексации — 0
— Строк за сеанс индексировать — 10000
— Переиндексировать все — 1
— в «Исключить шаблоны» прописал — 1,2,3,4,5,6

Сохранил плагин

2) открыл на редактирование любой ресурс и сохранил

3) Опять открыл плагин evoSearch, в конфигурации:
— Первая строка переиндексации — 0
— Строк за сеанс индексировать — 1
— Переиндексировать все — 0
— в «Исключить шаблоны» прописал — 1,2,3,4,5,6
Еще кэш почистил на всякий случай
4) Во фронтэнде ввел слово в поиск — в результатах были ресурсы с исключенными шаблонами.

5) Тогда в шаблоне страницы результатов поиска написал так:
[+searchresult.pages+]                                                  
[!evoSearch?                                                            
&tpl=`evoSearch`                                                                
&id=`searchresult`                                                              
&addWhereList=`c.template IN (7,11,22,23,25,31,36,37)`                                                    
&paginate=`pages`                                                               
&TplNextP=`` &TplPrevP=``                                                               
&TplPage=`@CODE: <li><a href="[+link+]">[+num+]</a></li>`                                                               
&TplCurrentPage=`@CODE: <li class="active"><a title="вы сейчас на этой странице">[+num+] <span class="sr-only">(текущая)</span></a></li>`  
&TplWrapPaginate=`@CODE: <nav class="text-center"><ul class="pagination pagination-lg">[+wrap+]</ul></nav>`      
!]
[+searchresult.pages+]

После этого эти ресурсы пропали из результатов поиска
Комментарий отредактирован 2015-04-18 13:48:44 пользователем nohc
avatar
Вроде все правильно. Варианта 2:
1. либо по каким-то причинам при переиндексации не очищаются поля content_with_tv и content_with_tv_index в ресурсах с исключенными шаблонами — хотя непонятно почему, надо бы проверить эту гипотезу.
2. либо искомые слова содержатся в заголовке (pagetitle) данного ресурса — тогда, действительно либо нужно задавать дополнительные условия через addWhereList либо напрямую снимать птичку «доступен для поиска» (т.к. в выдаче должны появляться только те, в которых разрешен поиск).
avatar
Да, второе))
В pagetitle
Комментарий отредактирован 2015-04-18 17:18:38 пользователем nohc
avatar
а можно ли выводить на странице результатов картинку из тв-параметра допустим? и еще вопрос: странно работает поиск по тв артикул в моем случае. По цифровому полю все хорошо, а вот если вводить что-то типа ВС-007 то в поиске ничего не находит. Можете натолкнуть куда смотреть? Тв параметр в настройках плагина указал как и его имя — article.
avatar
по первому вопросу — выводить картинку, также как и обычным запросом doclister — в вызове &tvList=`image` (где image — имя ТВ с картинкой), в шаблоне — [+tv.image+]

по второму вопросу — т.к. используется полнотекстовый поиск mysql с использованием словарей, то по «несуществующим словам» могут быть проблемы с нахождением. Попробуйте вот эту правку.
avatar
Да, по-первому все ок, спасибо! А вот со вторым ничего не дало :(. Еще что-нибудь можете подсказать?
avatar
Попробуйте самую последнюю версию с учетом последних правок — github.com/webber12/evoSearch/commit/511501dc80cd76f019a2dc00036ba8cfa40283f4 и в вызове сниппета с параметром &addLikeSearch = `1`. Если и это не поможет — пишите в личку доступы — будем смотреть :)
avatar
В чем может быть проблема когда не обновляется индекс ресурсов для поиска?

Ситуация очень странная: у меня на компе поиск работает нормально, а у другого пользователя как будто не индексируется поиск после сохранения документа. Зайдя в документ и добавив какую нибудь фразу типа «блаблабла» и сохранив документ по идеи должен обновится индекс и выводиться в результате, но ничего не находит, хотя в документе появился текст «блаблабла». Если я открою и пересохраню документ то в поиске появляется.
Пробовали зайти с разных браузеров, но результат один и тот же.

Помогите разобраться в чем проблема?
avatar
Методом проб и ошибок выяснилось, что я сохранял документ через /manager/ а другой пользователь это делал на странице (фронтенде) с помощью «Quick Manager». Теперь вопрос как запускать плагин если сохраняется через Quick Manager?
avatar
Плагин висит на событии сохранения документа OnDocFormSave — с этим надо и разбираться. Может поменять порядок вызова плагинов.
avatar
Огромное спасибо!
Поменял порядок и сработало.
avatar
Возможен-ли поиск по id документа?
avatar
нет
avatar
А можно ли сделать, чтобы результаты выводились как каталог товаров?
avatar
Что в tpl зададите, такой результат и будет выводится :)
avatar
если в запросе есть слеш "/" (например «25/10»), то в результате не видны заголовки, а только картинки. в чем может быть причина?

мои параметры:
[!evoSearch? 
&tpl=`evoSearch` 
&paginate=`pages`
&TplPrevP=`@CODE: <a href="[+link+]" class="page ditto_prev_link">« пред.</a>`
&TplNextP=`@CODE: <a href="[+link+]" class="page ditto_next_link">след. »</a>`
&TplCurrentPage=`@CODE: <span class="ditto_currentpage">[+num+]</span>` 
&tvList=`image_prod_medium`
&parents=`5`
&addLikeSearch=`1`
&addLikeSearchLength=`2`
&addLikeSearchType=`oneword`
&hideFolders=`1`
&rel=`3`
!]
avatar
Попробуйте вот это.
avatar
Поставил DocLister 2.1.30 (через Экстра)…

проблема тажа — параметр GET пропал в урл!
Как лечить не ясно…
avatar
походу мой косяк; при дебаге через строку адреса
avatar
Странная проблема:

Выводятся результаты с пагинацией, все ок. Но по ссылке в пагинации перейти не могу по клику, ссылка такая:

/rezultat-poiska.html?search=мыло&submit=Найти&page=2
Но если нажимаю открыть в новой вкладке, то всё удачно открывается на нужной странице. Как это?
avatar
А блин, это из-за eFiltr'a и парметра ajax=`1`
avatar
при указании
&statTpl=`tpl`
выводит просто слово tpl
при указании
&statTpl=`<div class="evoSearch_info">По запросу <b>[+stat_request+]</b> найдено всего <b>[+stat_total+]</b>. Показано <b>[+stat_display+]</b>, c [+stat_from+] по [+stat_to+]</div>`
— выводит только слова, безе значений плейсхолдеров.
модх 1.2-d8.1.5
установка EvoSearch из Extras, версия 0.1
avatar
Ни разу не пользовался EvoSearch, но чисто интуитивно могу предположить.

Во 2-м вашем примере ничего работать и не должно, так как вы забыли написать слово @CODE:

&statTpl=`@CODE:<div class="evoSearch_info">По запросу <b>[+stat_request+]</b> найдено всего <b>[+stat_total+]</b>. Показано <b>[+stat_display+]</b>, c [+stat_from+] по [+stat_to+]</div>`


С 1-м примером — два предложения: а) начните название со слова @CHUNK:

&statTpl=`@CHUNK:tpl`


предложение б): если не заработает предыдущее, попробуйте назвать чанк не tpl, а как-то по-другому, типа:

&statTpl=`@CHUNK:statTplChunk`


Вот такие размышления на тему дополнения, по которому я не то что в код не смотрел, но даже и не пользовался ))
avatar
спасибо, не помогло
avatar
Да, забыл написать — при использовании @CODE: — он же выводится на странице вместе с тектом
avatar
Рекомендую использовать EvoSearch — отличный сниппет поиска!
avatar
Обязательно попробую. Но навскидку — в чем его преимущество перед, например, поиском Яндекса по сайту?
avatar
Я конечно вопрос решил изменив умолчания в коде сниппета, но все же интересно в чем дело
Комментарий отредактирован 2016-11-03 19:30:45 пользователем zloyxrom
avatar
Подскажите, а prepare для Doclister со сниппетом можно как-то использовать?
У меня не срабатывает.
avatar
Поскольку prepare в evoSearch вызывается как метод класса, то возможен только однократный вызов, так уж устроен DocLister. Ну или я просто не нашел, как можно совместить несколько вызовов prepare в данном случае :)

Как вариант — задать в вызове &extract=`0` — тогда, по логике, должны сработать ваши prepare, но перестанет работать плейсхолдер [+extract+]. Если не критично — это ваш путь
Комментарий отредактирован 2017-02-10 11:20:38 пользователем webber
avatar
parents и depth почему то не работают
на сайте 3 языковые версии
на странице поиска вызываю так
[!evoSearch? &tpl=`evoSearch` &parent=`8` &depth=`7` &tvList=`code,photo`!]

doclister установлен

но почему то при поиске выводятся товары со всех языковых версий
avatar
Правильно подмечено в самом начале — parents :)
avatar
[!evoSearch? &tpl=`evoSearch` &parents=`8` &depth=`7` &tvList=`code,photo`!]

так тоже нет изменений
avatar
Доступ к сайту, где не работает, чтобы посмотреть мне никто не дает, а у меня вроде все работает. Потому не могу ничего ответить :)
avatar
Может чем-то поможет — modx.im/blog/questions/4646.html
avatar
upd. уже было
Комментарий отредактирован 2017-08-08 13:30:56 пользователем nuclear45
avatar
Здравствуйье, использую на сайте для поиска evoSearch, при вводе в форму поиск слова ski (клиенты лыжные туры ищут) вываливается такая ошибка

http://prntscr.com/fx5s3u
Комментарий отредактирован 2017-07-18 13:56:36 пользователем aleksei_uva
avatar
Один из псевдонимов ski — SKI'd — разваливает запрос DocLister своей одиночной кавычкой :)
avatar
В документации написано: «в настоящий момент индексации по TV не производится».
Сейчас это так?
avatar
В конфиге плагина можно перечислить через запятую имена tv для индексации, а значит и поиска.
avatar
Новогоднее обновление — версия 0.2 — теперь без модификации основной таблицы site_content (индекс хранится в отдельной таблице) и с улучшенными алгоритмами поиска. Жду желающих потестить :)
avatar
привет, установил, тестю. Пока один момент — если в alt у картинки встречается искомое слово, то найденный текст в альтах тоже оборачивается в
<span class="evoSearch_highlight">...</span>
что ломает верстку. Конечно, альты и тайтлы можно не заполнять в результатах поиска, но правильно было бы в них и не искать вообще.
avatar
Да, было бы наверно неплохо, вот только как это реализовать лучше — пока непонятно ))

п.с. сейчас глянул по коду, там же везде стоит сначала $modx->stripTags, т.е. по идее теги a и img, а вместе с ними и все alt-title должны удаляться до того, как создается подсветка. Они что, проскакивают?
Комментарий отредактирован 2018-01-11 13:19:43 пользователем webber
avatar
альт проскакивает, тайтл не проверял, но могу завтра посмотреть
avatar
Проверил и alt и title и даже value у input проскакивает. Так что ищите где баг зарылся.
avatar
А можно скрин, и желательно вместе с консольным просмотром кода, чтобы понять в чем дело :)
avatar
Проблема решилась, вернее ее и не было) была попытка вставить уже подсвеченный pagetitle в alt ) Граждане, в чанках используйте e.pagetitle для атрибутов alt/title :)
avatar
Чего-то у меня не получается добиться правильного содержимого в индексе. Получается вот такая фигня:


В htaccess выставил:
AddDefaultCharset utf-8
php_value mbstring.func_overload 2
php_value mbstring.internal_encoding UTF-8


В phpinfo сейчас вот так:
avatar
Мне кажется, это лишнее и что-то из битрикса (особенно mbstring.func_overload 2)

php_value mbstring.func_overload 2
php_value mbstring.internal_encoding UTF-8


Я ничего этого никогда для модх не ставил.
avatar
Да, из битриксовского форума именно и взял директивы.

Закачал на виртуальный хостинг — там все работает нормально, индекс строится в правильной кодировке. А на локалке (OpenServer) почему-то такая фигня получается. И не понятно, где и чего настроить.
avatar
Скорее всего что-то с преобразование в верхний регистр. Попробуйте вот это.
avatar
Заменил в этой строке strtoupper на mb_strtoupper, и все стало хорошо.
avatar
В старой версии MODx 1.0.5 вообще ничего не ищет.
avatar
Она наверно слишком крута, что даже doclister не использует )) Для этих целей используйте вызов с параметром &action=`ids`, а потом уже их в Ditto )
avatar
Зря Вы так говорите. Есть и Doclister, есть и eFiler, работает и первая версия evoSearch. Обновления на более свежих версия MODx проверю чуть позже.
avatar
Хотелось бы глянуть в чем дело, можно доступ в личку? Может таблица не создалась или не переиндексировали? В старой версии создавались 2 столбца в таблице site_content, в новой отдельная таблица и надо все переиндексировать. В принципе там больше и неработать нечему. Так что я бы глянул))
avatar
Но новой версии modx — полёт нормальный, со старой версией пока не разбирался. Огромное Вам спасибо за «поиск».
avatar
Автор молодец, но поиск работает кривовато.
Установил на локалку на modx evo 1.4.0. Проиндексировал не все. Качество поиска лучше AjaxSearch, но тоже так себе. Попробовал поиграть с rel, но результат не изменился. Полез внутрь, но так и не нашел где автор получает эту переменную от пользователя, только по дефолту
$this->setDefault('rel' => '0.01')
. Изменил на 1, результат не изменился. Дальше копаться не стал.
Жаль столько лет прошло, а к modx так и не прикрутили нормальный поиск.
  • Stas
  • 0
avatar
Качество поиска соответствует качеству и возможностям полнотекстового поиска MySQL по кирилице, которое улучшено использованием словарей «нормализованных» форм слов плюс дополнено like-поиском совпадений в заголовке (с повышенным приоритетом) и в остальных полях. Т.е. искать он должен значительно лучше, чем AjaxSearch, а не просто «лучше». Если есть какие-то более эффективные методы поиска по базе Mysql — так я только «за», чтобы их опробовать, т.к. согласен, что местами ищет недостаточно хорошо.

Ну а насчет rel и прочих параметров, если вы так и не нашли, это не значит, что его нет — вот оно. Не помню, чем там array_merge не подошел (видимо, были какие-то причины, которые к настоящему времени в связи с изменениями в коде могли и отпасть), но уж как есть, так есть :)
А вот тут этот rel используется в параметре WHERE для отсеивания «лишних» результатов.

В принципе сама релевантность в полнотекстовом поиске mysql — вещь достаточно неуловимая, поскольку зависит не только от конкретного текста, но и от других текстов. Потому ее надо корректировать не просто для конкретного сайта, но и для одного и того же сайта по мере добавления информации (если требуется точность).
Комментарий отредактирован 2018-02-03 06:50:02 пользователем webber
avatar
Изменил на 1, результат не изменился
1 и 0.01 на реальном сайте почти не имеют разницы, там счет идет на десятки, а то и на сотни в зависимости от типа сайта и заполненности его информацией. Плюс в приоритете точное совпадение поисковой фразы в заголовке, т.е. общая сортировка вывода идет по убыванию «точное совпадение в заголовке -> релевантность mysql -> точное совпадение в любом другом месте индексируемой информации»
avatar
Не подскажите, почему релевантность результатов поиска идёт в обратном порядке. Например, по запросу «морозильный ларь» первым выдаёт — «ларь для картофеля», затем — «ларь для овощей», а уж потом — выдаёт «морозильные лари»
avatar
Киньте доступ, гляну что там с релевантностью. Должно быть в порядке уменьшения релевантности. Возможно, у вас слишком релевантный «ларь»:)
avatar
Проблему помог решить webber , большое ему спасибо.
Решение: выкинул из вызова evoSearch параметры sortBy=`menuindex` и sortDir=`ASC`. Сортировка товара и релевантность это разные вещи, однако сортировка отодвигает релевантные товары назад, тем самым получается «каша». А еще у меня интернет магазин, где очень мало описания товара и очень много повторяющихся заголовков, тем самым теряется уникальность заголовка. Это оказывается тоже влияет на выдачу в поиске.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.