Нужно добавить возможность настраивать главный поиск в для более целенаправленного поиска.
Например есть задача найти в сущности "Контакты" с внутренним ID 61554.
Когда в поиск вставить данный ID - 61554, то результат просто раздражает, так как невозможно найти нудную информацию. Скриншот: http://prntscr.com/ky04m2
Да есть возможность зайти в перейти на страницу "Контакты" и в поиске вставить данный код, но это только лишнее движения/ клики, на которые нужно при оперативно работе много времени в это отвлекает.
РЕШЕНИЕ: Сделайте возможность самостоятельно настраивать данный поиск. Например: 1. По умолчанию поиск будет работать как и сейчас, но при настройках он более индивидуальный. 2. Для этого можно добавить в начале ли в конце поля "Поиск" маленькую кнопку "Настройка" может быть иконка. 3. При клику открывается окно настройки поиска. За пример можно взять как реализовано на страницах сущостей - http://prntscr.com/ky09xl
Идея достаточно объемная, но, думаю, востребованная. HL-блокам не хватает немного функционала стандартных инфоблоков и тогда продукт станет массовым и удобным: 1) Шаблон пути на страницу списка элементов хл-блока 2) Шаблон пути на детальную страницу элемента хл-блока 3) Участвует ли хл-блок в модулей поиска 4) Участие в модули поиска конкретного пользовательского поля хл-блока
Нюанс в том, что хл-блоки не нацелены на массу (если рассуждать в разрезе маркетинга). Это очень специфичный инструмент, который разработчик (даже не клиент) должен применять осознанно.
Про индексацию поиском хл-блоков думали, но тут главная проблема, что непонятно что считать детальной страницей элемента. В хл-блоках отсутствует даже понятие заголовка элемента (что важно для поиска) - заголовком может быть любое поле, или не быть им вовсе.
Это все конечно решается выведением хл-блоков в ряд к инфоблокам, но такое не планируется.
Это сейчас не реализовано! В техподдержке предлагают:
- Компонент отдает в шаблон массив результатов. Сделайте его count() средствами php - А если элементов больше чем одна страница? - Если включена постраничная навигация - то никак, к сожалению.
Люди, ну это полнейшая глупость, даже в поисковых системах показывает, сколько нашлось записей, а здесь по-умолчанию такая функция и недоступна. Сделайте!
Мода на плиточный поиск растет, потому есть потребность выводить не такой длинный текст, необходимо в свойствах задать свое количество максимальных символов MaxChars для вывода результата для одной.
Все управление созданием карты сайта sitemap.xml сводится к внутреннему поисковому индексу.
Поэтому чтобы добавить что-то в файл sitemap.xml, нужно добавить это в поисковый индекс. Хотя было бы не плохо иметь события на добавление каких то $additionalUrls в этот файл (через событие).
Еще идеи по поводу генератора Google sitemap.xml
1/ хотелось бы иметь возможность менять теги loc "на лету" в момент генерации карты. Я вижу это в виде некого события OnBeforeGoogleSitemapItemWrite($locXml, $arUrl) - т.е. событие перед непосредственной записью ссылки в тег loc файла sitemap.xml
2/ Хотелось бы иметь некую сортировку ссылок в файле. Главную хотелось бы располагать в самом верху файла sitemap.xml с тегом priority = 1.
3/ Что на счет не обязательных тегов changefreq и priority? Для главной priority ставить 1, для всех остальных ссылок 0.8 см http://www.sitemaps.org/ru/protocol.html
4/ Добавить возможность отключить кластеризацию ссылок по файлам sitemap_000.xml .. sitemap_N.xml т.к. чаще всего на проектах два файла sitemap.xml с оглавлением, и sitemap_000.xml с ссылками, поэтому создание оглавления излишне.
5/ Добавить возможность периодической не ручной генерации данного файла (напр. через cron)
При наличии события п.1 второй и третий пункты реализуются собственными силами.
Про индексацию поиском хл-блоков думали, но тут главная проблема, что непонятно что считать детальной страницей элемента. В хл-блоках отсутствует даже понятие заголовка элемента (что важно для поиска) - заголовком может быть любое поле, или не быть им вовсе.
Это все конечно решается выведением хл-блоков в ряд к инфоблокам, но такое не планируется.