Есть страница с компонентом catalog. Соответственно, список товаров определённого раздела выводится компонентом catalog.section. Который, в свою очередь, дёргает catalog.item. У которого, в конце концов, вызывается шаблон card/template.php.
Ближе к концу файла проверяется флаг $item['OFFERS_PROPS_DISPLAY'], и если он установлен, выводятся торговые предложения из $item['JS_OFFERS'].
Проблема в том, что $item['OFFERS_PROPS_DISPLAY'] равен false.
Этот флаг зависит от заполненности списка $offer['DISPLAY_PROPERTIES'] в каждом торговом предложении.
Хвосты ведут в файл catalog.section/.default/result_modifier.php, где вызывается код
который в итоге приводит в файл bitrix/modules/iblock/lib/component/elementlist.php, в метод editTemplateOfferProps().
Там как раз у каждого торгового предложения убивается то самое важное поле $offer['DISPLAY_PROPERTIES']:
Суть этого метода в том, что из $offer['DISPLAY_PROPERTIES'] удаляются все свойства, перечисленные в $iblockParams['OFFERS_TREE_PROPS'].
Берётся эта переменная чуть выше по коду:
Свойство торговых предложений, которое мне нужно выводить в карточках товаров, называется RAZMER. там могут быть значения типа 15, 16, 17 итд. И вот по каким-то причинам в $iblockParams['OFFERS_TREE_PROPS'] указано именно свойство - в виде массива: ['RAZMER'].
Затык расследования в том, что я не могу найти, где инициализируется $this->storage['IBLOCK_PARAMS']. Несомненно, инициализация есть в файле bitrix/modules/iblock/lib/component/base.php, метод loadOfferTreePropertyCodes() - но попытка вклинить туда отладку не увенчалась успехом: этот метод не вызывается.
Допустим, что инициализация действительно происходит этим вызовом:
судя по всему, это значит, что настройки содержатся не в настройках компонента catalog, а где-то в админке. Быстрый просмотр админки ничего подозрительного не дал. Вопрос всё ещё в силе: почему в настройках инфоблока торговых предложений указанно, что удалять нужно именно свойство RAZMER - единственно важное для вывода на списочной странице в карточках товаров.
При этом тот же самый "размер" без проблем используется на детальных страницах товаров - размеры можно щёлкать, при этом переключаются цены. То есть, в заполнении товарной базы проблем тоже нет.
Настройки компонента catalog следующие:
Внешний вид -> Схема отображения: расширенный
Внешний вид -> Свойства для отбора предложений: [212][RAZMER] Размер
Настройки списка -> Свойства предложений: [RAZMER] Размер
Куда копать, куда спасаться? Пока что обходным вариантом видится полное игнорирование JS_OFFERS, OFFERS_PROPS_DISPLAY и прочих, и самодельная реализация через использование массива $offer['PROPERTIES'], который, к счастью, заполнен всегда. Тем более, шаблон всё равно нужно кастомизировать. Но беспокоит, что рано или поздно эта непонятная ситуация может выстрелить где-нибудь в неожиданном месте; и всегда лучше попытаться разобраться по-красоте, а не сразу кидаться через бурелом.
Ближе к концу файла проверяется флаг $item['OFFERS_PROPS_DISPLAY'], и если он установлен, выводятся торговые предложения из $item['JS_OFFERS'].
Проблема в том, что $item['OFFERS_PROPS_DISPLAY'] равен false.
Этот флаг зависит от заполненности списка $offer['DISPLAY_PROPERTIES'] в каждом торговом предложении.
Хвосты ведут в файл catalog.section/.default/result_modifier.php, где вызывается код
Код |
---|
$component = $this->getComponent(); $arParams = $component->applyTemplateModifications(); |
который в итоге приводит в файл bitrix/modules/iblock/lib/component/elementlist.php, в метод editTemplateOfferProps().
Там как раз у каждого торгового предложения убивается то самое важное поле $offer['DISPLAY_PROPERTIES']:
Код |
---|
\CIBlockPriceTools::clearProperties($offer['DISPLAY_PROPERTIES'], $iblockParams['OFFERS_TREE_PROPS']); |
Суть этого метода в том, что из $offer['DISPLAY_PROPERTIES'] удаляются все свойства, перечисленные в $iblockParams['OFFERS_TREE_PROPS'].
Берётся эта переменная чуть выше по коду:
Код |
---|
$iblockParams = $this->storage['IBLOCK_PARAMS'][$item['IBLOCK_ID']]; |
Свойство торговых предложений, которое мне нужно выводить в карточках товаров, называется RAZMER. там могут быть значения типа 15, 16, 17 итд. И вот по каким-то причинам в $iblockParams['OFFERS_TREE_PROPS'] указано именно свойство - в виде массива: ['RAZMER'].
Затык расследования в том, что я не могу найти, где инициализируется $this->storage['IBLOCK_PARAMS']. Несомненно, инициализация есть в файле bitrix/modules/iblock/lib/component/base.php, метод loadOfferTreePropertyCodes() - но попытка вклинить туда отладку не увенчалась успехом: этот метод не вызывается.
Допустим, что инициализация действительно происходит этим вызовом:
Код |
---|
Catalog\Product\PropertyCatalogFeature::getOfferTreePropertyCodes( $this->storage['CATALOGS'][$iblockId]['IBLOCK_ID'], ['CODE' => 'Y'] ); |
судя по всему, это значит, что настройки содержатся не в настройках компонента catalog, а где-то в админке. Быстрый просмотр админки ничего подозрительного не дал. Вопрос всё ещё в силе: почему в настройках инфоблока торговых предложений указанно, что удалять нужно именно свойство RAZMER - единственно важное для вывода на списочной странице в карточках товаров.
При этом тот же самый "размер" без проблем используется на детальных страницах товаров - размеры можно щёлкать, при этом переключаются цены. То есть, в заполнении товарной базы проблем тоже нет.
Настройки компонента catalog следующие:
Внешний вид -> Схема отображения: расширенный
Внешний вид -> Свойства для отбора предложений: [212][RAZMER] Размер
Настройки списка -> Свойства предложений: [RAZMER] Размер
Куда копать, куда спасаться? Пока что обходным вариантом видится полное игнорирование JS_OFFERS, OFFERS_PROPS_DISPLAY и прочих, и самодельная реализация через использование массива $offer['PROPERTIES'], который, к счастью, заполнен всегда. Тем более, шаблон всё равно нужно кастомизировать. Но беспокоит, что рано или поздно эта непонятная ситуация может выстрелить где-нибудь в неожиданном месте; и всегда лучше попытаться разобраться по-красоте, а не сразу кидаться через бурелом.