Я к тому, чтобы максимально быстро выпустить некое решение рабочее.
Боюсь большой объем работы просто застопорит все.
Кстати, если писать с нуля, ну по факту будут написаны аналоги процессоров, просто с другими «что смущает», которые будут подогнаны именно под это апи.
Думаю, что использовать стоит, по крайней мере в тех местах, где они хорошо отрабатывают.
Просто для того, чтобы максимально быстро достичь некоего рабочего этапа.
Если процессор позволяет выполнить действие — пусть работает.
А если не позволяет, значит идти другим путем, писать самому это действие.
Да вот и не знаю, какую сортировку писать…
Даже сформулировать тяжело. Вероятнее всего да, нужно самому сформировать список id Объектов, а потом уже их сами и выбирать через pdoResources или что удобнее.
Смотря сколько у вас файлов…
Как вариант, можно через произвольную библиотеку прочитать текстовое содержимое файлов и всем массивом засунуть в скрытые ресурсы (один файл — один ресурс). Эти ресурсы и будет индексировать SimpleSearch (но лучше mSearch2). А при выводе результата поиска подменять ссылку на ресурс ссылкой на файл.
А как компонент должен понять, что ПАГ14 это два слова «ПАГ + 14»?
По какому принципу то?.. Это не интеллектуальный поиск аля Яндекс.
Если оч. нужно, пишите плагин/сниппет, что удобно в общем, который будет в этом частном случае разбивать входящий запрос по принципу «строка+число» и уже это скармливайте mSearch2.
Маленький сниппет, проверяющий наличие в $_GET параметра MNT_TRANSACTION_ID и при его наличии производящий редирект на эту же страницу, но с другим параметром.
Боюсь большой объем работы просто застопорит все.
Кстати, если писать с нуля, ну по факту будут написаны аналоги процессоров, просто с другими «что смущает», которые будут подогнаны именно под это апи.
Просто для того, чтобы максимально быстро достичь некоего рабочего этапа.
Если процессор позволяет выполнить действие — пусть работает.
А если не позволяет, значит идти другим путем, писать самому это действие.
Добавьте пробелов в чанке Favicon на каждой строчке, перестанет съезжать.
Спасибо. Хотя здесь может быть ситуация, когда свежий записей в выборке не будет…
Даже сформулировать тяжело. Вероятнее всего да, нужно самому сформировать список id Объектов, а потом уже их сами и выбирать через pdoResources или что удобнее.
Как вариант, можно через произвольную библиотеку прочитать текстовое содержимое файлов и всем массивом засунуть в скрытые ресурсы (один файл — один ресурс). Эти ресурсы и будет индексировать SimpleSearch (но лучше mSearch2). А при выводе результата поиска подменять ссылку на ресурс ссылкой на файл.
Желательно еще и $mode проверять, $resource может быть и категорией.
Сколько фильтров, я не зря спросил про параметр filters,
По полям товаров или TV фильтрация идет?
Если вызов mFilter2 заменить на msProducts, работает быстро?
По какому принципу то?.. Это не интеллектуальный поиск аля Яндекс.
Если оч. нужно, пишите плагин/сниппет, что удобно в общем, который будет в этом частном случае разбивать входящий запрос по принципу «строка+число» и уже это скармливайте mSearch2.
А если каждый год, то нужно что-то написать, да…
Хотя можно эту конструкцию в шаблоны TinyMCE попробовать даже добавить.
В чанке products соответственно вызов msProducts с нужными resources.
2.…
3. нет, вот нет.
Используйте Collections, или Tickets.
Чтобы открылось, можете этим ресурсам (10000+ которых) проставить через базу поле show_in_tree в ноль временно.