В стандартных компонентах (например, bitrix:catalog.element) идет разделение свойств на PROPERTIES и DISPLAY_PROPERTIES, то есть, абсолютно все свойства, и свойства, которые выводятся для просмотра посетителям сайта.
Но сделано немного непродуманно, например, если добавляется еще одно свойство у товара, то нужно потом заходить еще и на страницу каталога на сайте, и в режиме "правки" настраивать параметры компонента, где через Ctrl выделять еще одно свойство, которые было создано.
Так как это никуда не годится (редактор может ошибиться и случайно сбросить все свойства, может забыть его добавить, да и вообще, свойства без символьных кодов через парамерты компонента нельзя выбрать), то пришлось добавить небольшой хак.
1. Для свойств, которые отображать на странице товара не нужно (например, служебные или сео-свойства) ставим отрицательную сортировку (меньше нуля), Битрикс это позволяет, значит, почему бы не воспользоваться. А редактору вряд-ли прийдет в голову использовать отрицательные сортировки.
2. В result_modifier.php в шаблоне компонента добавляем код для форматирования и отображения всех свойств с положительной сортировкой:
//==============================================//
// Показывать все свойства в DISPLAY_PROPERTIES //
//==============================================//
$arResult["DISPLAY_PROPERTIES"] = array();
foreach ($arResult["PROPERTIES"] as $pid => &$arProp)
{
// Не выводим для просмотра свойства с сортировкой мнеьше 0 (они будут у нас служебными)
if ($arProp["SORT"] < 0)
continue;
if((is_array($arProp["VALUE"]) && count($arProp["VALUE"])>0) ||
(!is_array($arProp["VALUE"]) && strlen($arProp["VALUE"])>0))
{
$arResult["DISPLAY_PROPERTIES"][$pid] = CIBlockFormatProperties::GetDisplayValue($arResult, $arProp);
}
}
Теперь, можем создать инфоблок, определить в нем системные свойства, которые будут у всех товаров, но не будут выводиться (поставив им отрицательную сортировку), и можно смело отдавать сайт в редактирование редакторам или клиенту, они будут лихо добавлять новые свойства через новый модуль магазина, и эти свойства будут сразу показываться на странице товара, на стандартных компонентах, без необходимости каждый раз настраивать параметры компонента.
Еще было бы круто, чтобы добавили поддержку вывода новых добавленных свойств в форме редактирования элемента инфоблока (если форма кастомизированная), это бы еще больше добавило гибкости и убрало бы необходимость настраивать форму редактирования товара еще и в админке.
UPD: в обновлении 14.0 убрали возможность задавать отрицательные сортировки, теперь, лучше под это дело резервировать другое число, например, не показывать товары сортировка у которых равна 1.
Только непонятно, зачем это было делать, если вдруг работающий сайт с таким механизмом, и обновление, тогда сразу все свойства будут выводиться, совсем нехорошо.
Но сделано немного непродуманно, например, если добавляется еще одно свойство у товара, то нужно потом заходить еще и на страницу каталога на сайте, и в режиме "правки" настраивать параметры компонента, где через Ctrl выделять еще одно свойство, которые было создано.
Как раз продуманно.
Особенно, если учесть, что сейчас большинство магазинов при создании используют комплексный компонент (настройка в одном месте, а вот что касается настроек компонент, то мы не пускали бы туда менеджеров)
В большинстве случаев это приходится делать на этапе разработки - но тогда можно сказать, что не продумана архитектура и на самом деле страдают не контент менеджеры, а сами же разработчики Но мы то знаем что такое DISPLAY_PROPERTIES
Но даже при всем при этом, при одном каталоге на весь магазин ( а таких вариантов большинство в рунете) это не составляет хлопот.
Ваше решение может понадобиться скорее на более сложных проектах Например, если несколько каталогов или несколько абсолютно разных разделов на разных ИБ. То может быть и полезно.
Если оставить за кадром тот момент, что придется модифицировать с данной целью все необходимые шаблоны компонентов, то очень даже здаво, но не каждому подойдет Я бы рассматривал исходя из особенностей проекта. Так как большинство проектов после запуска вообще редко модифицируются, на них затраты на централизацию управления могут оказаться бесполезными.
Но сделано немного непродуманно, например, если добавляется еще одно свойство у товара, то нужно потом заходить еще и на страницу каталога на сайте
И тут менеджер Василий решил добавить свойство "моя прибыль после сбыта этого барахла"...
Вообще добавление свойств это более этап разработки. Если это все же повседневная задача - тут уже несколько другая идеология и подход, идущий в разрез "с стандартными компонентами".
Ваше решение может понадобиться скорее на более сложных проектах Например, если несколько каталогов или несколько абсолютно разных разделов на разных ИБ. То может быть и полезно.
Как раз очень часто и надобится, для разделения труда, когда программист запрограммировал возможность вывода свойств и фильтрации по ним, а контент-менеджер набивает эти свойства и значения. Давать контент-менедежру лезть в настройки компонента не хочется, а вот отдать ему механическую часть работы (создавать свойства) - почему-бы и нет.
Шаблон template.php модифицировать не нужно, изменения нужно внести только в result_modifier.php
Вообще, в рабочей версии мастера магазина, у меня еще идет проверка чекбокс-параметра "Всеггда показывать все свойства", если он установлен, то используется этот механизм, а если не установлен - то старый, битриксовский, с ручным указанием через параметры. Поэтому, возможность выбора есть.
В моей практике описанная ситуация кстати встречалась довольно часто - например, когда свойствами клиент управляет в 1С, и хочет после обмена видеть новые свойства на сайте. Я делал в этом случае дополнительный параметр шаблона комплексного компонента, и выносил туда свойства, которые показывать точно НЕ нужно, а остальные выводил. Конечно, этот набор тоже может измениться, но это обычно реже бывает.
Хм, в последнем обновлении убрали возможность задавать отрицательные сортировки, значит, теперь в своем мастере буду резервировать сортировку 1 под служебные свойства, а всё что больше - выводить.
Странно, конечно. но задача, например, какие свойства в какой группе показывать встречается гораздо чаще, чем то, что вы описали. Или другой момент: непонятно как вы все же разделяете списки от детальных карточек товаров? В комплексном это две разные настройки и у каждой свой набор свойств.
код рабочий, но надо добавить 3-й параметр в GetDisplayValue и заменить $arResult на $arResult['ITEMS'] $arResult["DISPLAY_PROPERTIES"][$pid] = CIBlockFormatProperties::GetDisplayValue($arResult['ITEMS'], $arProp, '');
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».