Применение эвента products_collection
Насколько я понял, данное событие перехватывается только для новых типов "Коллекций", и если мне надо изменить существующий вывод товара в категории на фронте то данный хук мне не подходит?
По коду я вижу что если тип "category", то евент не вызывается вообще?
Отсюда следует, что если я хочу кое чего добавить в SQL-запрос товара в категории , то плагином это сделать невозможно? Или есть выход?
7 ответов
Возможно, что то, что вы хотите сделать, можно сделать по-другому. Какой план-то? Что вы собирались делать добавленными в запрос данными? И идёт ли речь про фронтэнд или бэкэнд?
--------------------------------------
Стоит вполне себе абстрактная задача, необходимо в SS5 добавить
принудительную сортировку товара в категориях во фронтенде, чтобы
товары с нулевым количеством улетали в конец списка, но при этом чтобы
товары продолжали сортироваться по наименованию, цене и прочему и прочему...
В общем то не большая проблема..
При SQL-запросе товара в SELECT добавляем поле ", IF(p.count = 0, 0,1) AS count_binary",
а в ORDER BY добавляем " count_binary DESC ," и после этого уже остальные поля сортировки.
Но вот возникает вопрос как это сделать плагином, не трогая системных
классов и модулей?
В плагине я цепляюсь к событию "frontend_category", но ведь в тот
момент когда плагин включается в работу (я имею ввиду при обработке
экшена "shopFrontendCategory.action.php") запрос товара уже
сформирован и что хуже того выполнен....
В принципе, я могу в своем плагине заново собрать и выполнить этот
запрос только уже как мне надо, а потом просто заново отправить результат в смарти-переменную:
$this->view->assign('products', $products);
$this->view->assign('products_count', $count);
И вроде бы всё будет хорошо и правильно, но ведь SQL-запрос (И не
один!!) выполниться дважды! Сначала системный потом мой. Нагрузка то
на сервер от этого возрастет чуть не в два раза!
Подскажите есть какой-то способ о котором я не подумал? Чтобы плагин
был полноценным и самодостаточным?
--------------------------------------
Я его задавал и на форуме, и по почте, но везде сплошной игнор. И тут я попросил заказчика задать техподдержке мой вопрос. Потому что я не могу выполнить задачу заказчика, так чтобы это не затерлось обновкой (не трогая системных файлов).
В техподдержке ответили:
"Для задания дополнительных параметров формирования SQL-запроса для выборки товаров используйте хук products_collection. Пример реализации можно посмотреть в исходном коде плагина "Избранные товары"
Понятно, что я в лице заказчика - неуч не читающий документацию. Я сам так подумал. А начав работы с "products_collection" оказалось, что он не подходит для этой задачи. Если всетаки мне не ответят на поставленный вопрос положительно.
Мне нужен, официальный ответ, что "да! плагинами данная задача не решается в принципе", "нет. есть ещё один обиван..."
Дело ведь даже не в этой задаче конкретно - МНЕ НУЖНО МОДИФИЦИРОВАТЬ SQL-ЗАПРОС ТОВАРОВ В КАТЕГОРИИ!!! НУЖНО И ВСЁ! ДЛЯ ОПТИМИЗАЦИИ,ДЛЯ ДОПОЛНЕНИЙ, ДЛЯ ЧЕГО УГОДНО!
Модификация произвольных SQL запросов коллекции вряд ли будет доступна для плагинов когда-либо вообще.
Если заказчику прямо очень-очень надо, всегда есть чёрная магия вуду, которая позволит это сделать сейчас поверх 5.1 и не затрётся обновлением. Можно в плагине написать экшн, который полностью копирует функционал shopFrontendCategoryAction.
А дальше, собственно, чёрная магия: подменить контроллер. Это можно сделать на уровне роутинга, добавив новое скрытое поселение в глобальный роутинг wa-config/routing.php перед основным поселением магазина. Правило примерно такого вида:
array(
'app' => 'shop',
'url' => // взять из правила категории из shop/lib/config/routing.php
'private' => '1', // скрытое поселение
'module' => 'plgnPluginMdl', // экшн плагина притворяется, что он из модуля приложения
'action' => 'actn', // будет использован класс shopPlgnPluginMdlActnAction
// другие параметры - theme, theme_mobile, locale - такие же, как в основном поселении магазина в wa-config/routing.php
),
Типа всё, контроллер подменили, категория теперь показывается новым контроллером. Но. Могу предположить, что создание второго поселения для Магазина может сломать генерацию URLов во фронтэнде. Если урлы стали генериться неправильно, это вряд ли можно будет исправить в принципе, и надо пробовать другой способ.
Другой способ - создать кастомный FrontController для Магазина. Вот тут в разделе "Переопределение правил маршрутизации в бекенде" написано, как его создать: http://www.webasyst.ru/developers/docs/routing/backend-routing/
Поскольку для фронтэнда используется тот же фронт-контроллер, метод dispatch() позволяет переопределить роутинг как угодно. Вот это уже должно сработать без побочных эффектов. Тут другой минус. Этот способ сломается, если в дистрибутив Магазина когда-нибудь будет включен файл factories.php
Оба способа - на свой страх и риск. Если что - я вам ничего не говорил, вы меня не знаете, я вас не знаю :D
Всё также осталось по-старому?
Или в новых версиях(7-8) можно как-то другим, более простым, способом изменить вывод товаров в категории - через свой кастомный хелпер(или плагин)?
В новых версиях есть своя настройка для товаров которых нет на складе есть своя настройка в настройках магазина
Это не то.
Мне нужно переопределить products_collection для некоторых категорий-фильтров - чтобы не создавать дополнительные sql-запросы для выборки товаров.
Есть-ли решение - чтобы можно было заменить массив $products своим, перед передачей его в category.html?