Есть компонент catalog search, который состоит из двух компонентов:
catalog page и catalog section.
Логика у него простая, результат catalog page передаётся в catalog section, который и выводит на страницу.
catalog page может сортировать по релевантности, но проблема в том, что catalog section применяет свою сортировку, а сортировки по релевантности он не имеет из-за того, что её не поддерживает CIBlockElement::GetList.
catalog page и catalog section.
Логика у него простая, результат catalog page передаётся в catalog section, который и выводит на страницу.
catalog page может сортировать по релевантности, но проблема в том, что catalog section применяет свою сортировку, а сортировки по релевантности он не имеет из-за того, что её не поддерживает CIBlockElement::GetList.
Почему нет сортировки по цене ТП в каталоге? С точки зрения маркетинга неплохо бы выводить в секции у товара цену самого его дешёвого ТП. Зайдя уже в карточку пользователь сам сможет решить какие настройки товара(ТП) ему нужны.
Ответил 
Жуков Евгений 15.02.2018 11:45:14
Жуков Евгений 15.02.2018 11:45:14
catalog 17.6.0 + iblock 17.6.0
Если коротко - двух параметров для сортировки не всегда достаточно. Еще хотелось бы управлять сортировкой через глобальный массив, подобно тому, как это происходит с FILTER_NAME.
Все что для этого нужно - добавить еще один параметр в компонент, например "SORT_NAME" и несколько строк кода, примерно так:
Все что для этого нужно - добавить еще один параметр в компонент, например "SORT_NAME" и несколько строк кода, примерно так:
Предлагаю специально для разработчиков включить в поставку компонента заготовку шаблона, вроде такой:
<?if(!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED!==true)die();?>
<?foreach($arResult["ITEMS"] as $arElement):?>
<?$this->AddEditAction($arElement['ID'], $arElement['EDIT_LINK'], CIBlock::GetArrayByID($arParams["IBLOCK_ID"], "ELEMENT_EDIT"));
$this->AddDeleteAction($arElement['ID'], $arElement['DELETE_LINK'], CIBlock::GetArrayByID($arParams["IBLOCK_ID"], "ELEMENT_DELETE"), array("CONFIRM" => GetMessage('CT_BCS_ELEMENT_DELETE_CONFIRM')));?>
id="<?=$this->GetEditAreaId($arElement['ID']);?>
<?endforeach;?>
|
Свойства для элементов получаем на 788 строке с помощью такого кода:
CIBlockElement::GetPropertyValuesArray($arElementLink, $arParams["IBLOCK_ID"], $arFilter);
Но при этом не учитываются внешние фильтры.
Можно сделать это также, как делается и при выборке самих элементов в этом же компоненте. Вместо $arFilter использовать array_merge($arrFilter, $arFilter);
CIBlockElement::GetPropertyValuesArray($arElementLink, $arParams["IBLOCK_ID"], $arFilter);
Но при этом не учитываются внешние фильтры.
Можно сделать это также, как делается и при выборке самих элементов в этом же компоненте. Вместо $arFilter использовать array_merge($arrFilter, $arFilter);
Ответил
Жуков Евгений 02.06.2014 13:23:53
Жуков Евгений 02.06.2014 13:23:53
Внешние фильтры учитываются. Более того, у Вас устаревший код компонента, эта строка была изменена в iblock 14.5.4
Собственно сабж.
Сейчас выбираются все активные торговые предложения, но бывают ситуации, когда ТП обладают некоторым свойством, которое накладывает свою логику отображения. Например создание ТП с привязкой к разным городам/складам.
Сейчас выбираются все активные торговые предложения, но бывают ситуации, когда ТП обладают некоторым свойством, которое накладывает свою логику отображения. Например создание ТП с привязкой к разным городам/складам.
Ответил
Жуков Евгений 31.08.2015 18:05:04
Жуков Евгений 31.08.2015 18:05:04
За это отвечает ключ OFFERS основного фильтра.
По умолчанию идет
$rsElements = CIBlockElement::GetList($arSort, array_merge($arrFilter, $arFilter), false, $arNavParams, $arSelect);
где $arrFilter - пользовательский массив фильтрации, и некоторые значения, которые идут в $arFilter, переопределяют значения в $arrFilter
$arFilter = array(
"IBLOCK_ID" => $arParams["IBLOCK_ID"],
"IBLOCK_LID" => SITE_ID,
"IBLOCK_ACTIVE" => "Y",
"ACTIVE_DATE" => "Y",
"ACTIVE" => "Y",
"CHECK_PERMISSIONS" => "Y",
"MIN_PERMISSION" => "R",
"INCLUDE_SUBSECTIONS" => ($arParams["INCLUDE_SUBSECTIONS"] == 'N' ? 'N' : 'Y'),
;
например "ACTIVE_DATE" => "Y", "ACTIVE" => "Y"
$rsElements = CIBlockElement::GetList($arSort, array_merge($arrFilter, $arFilter), false, $arNavParams, $arSelect);
где $arrFilter - пользовательский массив фильтрации, и некоторые значения, которые идут в $arFilter, переопределяют значения в $arrFilter
$arFilter = array(
"IBLOCK_ID" => $arParams["IBLOCK_ID"],
"IBLOCK_LID" => SITE_ID,
"IBLOCK_ACTIVE" => "Y",
"ACTIVE_DATE" => "Y",
"ACTIVE" => "Y",
"CHECK_PERMISSIONS" => "Y",
"MIN_PERMISSION" => "R",
"INCLUDE_SUBSECTIONS" => ($arParams["INCLUDE_SUBSECTIONS"] == 'N' ? 'N' : 'Y'),
;например "ACTIVE_DATE" => "Y", "ACTIVE" => "Y"
Идея, как дополнение к новому функционалу - . И соответственно при включении данного фильтра, опция “Не отображать товары, которых нет на складе” будет распространяться только на данный склад(-ы).
Ответил
Жуков Евгений 22.03.2019 16:37:42
Жуков Евгений 22.03.2019 16:37:42
Вышло в catalog 15.0.2
Сейчас для свойства типа "Файл" в случае если у элемента добавлен один файл, структура результирующего массива - $arResult["DISPLAY_PROPERTIES"]["MORE_PHOTO"] в шаблоне следующая:
и соответствующий ему массив
в тоже время, если у элемента больше одного значения для свойства типа "Файл" - имеем следующую структуру:
и соответствующий ему массив
Т.е. во втором массиве появляется еще один уровень вложенности, на мой взгляд, в первом варианте должно быть также.
[VALUE] => Array ( [0] => 958 ) |
и соответствующий ему массив
[FILE_VALUE] => Array ( [ID] => 958 ... [SRC] => /upload/iblock/914/2.jpg ) |
в тоже время, если у элемента больше одного значения для свойства типа "Файл" - имеем следующую структуру:
[VALUE] => Array ( [0] => 948 [1] => 949 ) |
и соответствующий ему массив
[FILE_VALUE] => Array ( [0] => Array ( [ID] => 948 ... [SRC] => /upload/iblock/3af/1.jpg ) [1] => Array ( [ID] => 949 ... [SRC] => /upload/iblock/e22/2.jpg ) |
Т.е. во втором массиве появляется еще один уровень вложенности, на мой взгляд, в первом варианте должно быть также.
Ответил
Жуков Евгений 31.10.2013 19:41:07
Жуков Евгений 31.10.2013 19:41:07
Невозможно из соображений совместимости
Проблема заключается в том, что компонент "bitrix:catalog.section" не реагирует на фильтр, если в параметрах не передан ID/CODE раздела инфоблока. При этом не спасает даже параметр "SHOW_ALL_WO_SECTION", установленный в значение "Y", хотя пару лет назад это решение работало.
Собственно, эта логика прослеживается в исходном коде компонента "bitrix:catalog.section", но такое поведение компонента является неоправданным и усложняет разработку проектов. Объективной необходимости проводить проверку наличия ID/CODE раздела до обработки фильтра нет: эти вещи не являются взаимоисключающими. При этом фильтр по всем элементам (без указания разделов) заказчики требуют довольно часто, и каждый раз кастомизировать компонент - не очень хороший выход.
Предлагаю либо довести компонент "bitrix:catalog.section" до ума, либо создать аналогичный компонент, не требующий жесткого указания раздела. Например, его можно назвать "Элементы инфоблока".
P.S. В поддержке проблемой это признать отказались. В принципе, их можно понять, но разработчикам от этого не легче.
Собственно, эта логика прослеживается в исходном коде компонента "bitrix:catalog.section", но такое поведение компонента является неоправданным и усложняет разработку проектов. Объективной необходимости проводить проверку наличия ID/CODE раздела до обработки фильтра нет: эти вещи не являются взаимоисключающими. При этом фильтр по всем элементам (без указания разделов) заказчики требуют довольно часто, и каждый раз кастомизировать компонент - не очень хороший выход.
Предлагаю либо довести компонент "bitrix:catalog.section" до ума, либо создать аналогичный компонент, не требующий жесткого указания раздела. Например, его можно назвать "Элементы инфоблока".
P.S. В поддержке проблемой это признать отказались. В принципе, их можно понять, но разработчикам от этого не легче.
Ответил
Жуков Евгений 01.09.2014 14:43:43
Жуков Евгений 01.09.2014 14:43:43
Компонент применяет фильтр, даже если раздел не найден (считается, что идет работа с корневым разделом).
Сейчас в компоненте действует алгоритм исключающих условий:
Предложенный подход не изменит логику компонента, но сделает его работу более предсказуемой.
- передан ли параметр by_link,
- указан ли код секции,
- указан ли ID секции.
Предложенный подход не изменит логику компонента, но сделает его работу более предсказуемой.
Ответил
Жуков Евгений 28.02.2014 19:44:39
Жуков Евгений 28.02.2014 19:44:39
Вышло в обновлении iblock 12.5.5
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
