Свойства инфоблоков в Битрикс: типы, настройка и вывод

Свойства инфоблоков в Битрикс - первое, с чем сталкивается разработчик, когда нужно вывести на карточке товара цвет, размер, срок доставки или ссылку на PDF-инструкцию. За несколько лет работы с 1С-Битрикс я перенастраивал свойства инфоблоков в десятках проектов - от каталогов на 200 позиций до маркетплейсов с 40 000 SKU, и почти каждый раз находил свойства, заведённые криво: строка вместо справочника, несвязанные значения, дублирующиеся коды. Разберу, какие типы свойств есть в модуле iblock, как их настраивать через админку и API и как выводить в шаблонах компонентов без лишних SQL-запросов.

Что такое свойства инфоблоков и где они хранятся

У каждого элемента инфоблока есть фиксированный набор полей - NAME, PREVIEW_TEXT, DETAIL_PICTURE, ACTIVE и ещё десяток штук, они одинаковые для любого инфоблока в системе. Всё остальное - цена за упаковку, объём в литрах, привязка к бренду, файл сертификата - заводится через свойства. Это отдельная сущность модуля iblock: таблица b_iblock_property хранит описание свойства (тип, код, обязательность, множественность), а b_iblock_element_property - сами значения по каждому элементу.

Важный момент, который у новичков вылетает из головы: свойства привязаны не к типу инфоблока, а к конкретному инфоблоку. Если у вас два инфоблока «Товары» и «Услуги» одного типа, свойство «Гарантия» в одном не появится автоматически в другом - придётся либо создавать заново, либо копировать через экспорт-импорт настроек. На проектах с десятком похожих каталогов (розница + опт + маркетплейс) я обычно завожу свойства один раз в «эталонном» инфоблоке и переношу остальным через стандартный экспорт списка свойств в админке - это быстрее, чем руками кликать по 30 полей в каждом.

У свойства есть код (SYMBOL_CODE / PROPERTY_CODE) - именно по нему вы обращаетесь к значению в шаблоне. Код задаётся один раз при создании и латиницей без пробелов: COLOR, SIZE, PDF_FILE. Менять код у свойства, которое уже используется в шаблонах, - плохая идея, обычно после переименования вывод молча пропадает, потому что вся логика в компонентах завязана на строковый ключ, а не на ID.

Типы свойств инфоблоков: полный список и когда какой брать

В админке при создании свойства выбирается тип из выпадающего списка, но по факту в базе хранится буквенный код типа плюс необязательный подтип через двоеточие. Вот что реально используется на практике:

Последний пункт - то, на чём чаще всего экономят разработчики и потом расплачиваются. Список типа L хранит варианты в отдельной таблице b_iblock_property_enum, и админка при 200+ значениях начинает открывать форму редактирования свойства по 3-4 секунды на каждый клик. Если у вас справочник брендов на 500 позиций - заводите Highload-блок и привязывайте свойство типа S:directory к нему, а не список.

Как создать и настроить свойство через админку

Путь стандартный: Контент → Инфоблоки → нужный тип → конкретный инфоблок → «Свойства» в дереве настроек. В форме создания свойства обязательно заполняю:

• Название - то, что видит контент-менеджер
• Код - латиница, без пробелов, по нему обращаемся из PHP
• Тип - из таблицы выше
• Множественное - Да/Нет, отдельно разберу ниже
• Обязательное - если без значения элемент нельзя сохранить/опубликовать
• Для типа «Список» - заполняю «Варианты» с XML_ID для каждого значения (пригодится при обмене с 1С)
• Роль поля - если инфоблок участвует в обмене с 1С, привязка ролей экономит часы на настройке правил обмена

Отдельно стоит «Количество строк для ввода» - по умолчанию 1, но для множественных строковых свойств удобнее сразу ставить 3-5, чтобы контент-менеджер не докликивал добавление полей вручную.

Множественные свойства: где хранится массив значений

Когда у свойства стоит MULTIPLE => "Y", в базе для одного элемента появляется несколько строк в b_iblock_element_property с одинаковым PROPERTY_ID. В PHP это превращается в массив: при работе через CIBlockElement::GetList с параметром bIncludeValues => true значение свойства приходит не строкой, а массивом ключей VALUE и DESCRIPTION.

Типичная ошибка - обращаться к множественному свойству как к одиночному и получать вместо строки Array в выводе. Правильно оборачивать в цикл:

if (!empty($arElement['PROPERTIES']['SIZE']['VALUE'])) {
    foreach ($arElement['PROPERTIES']['SIZE']['VALUE'] as $key => $value) {
        echo $value;
        if ($key !== array_key_last($arElement['PROPERTIES']['SIZE']['VALUE'])) {
            echo ', ';
        }
    }
}

На практике множественные свойства чаще всего нужны для размерной сетки, набора файлов (несколько сертификатов) и для тегов/атрибутов, которые нельзя привести к одному значению.

Вывод свойств инфоблоков в шаблоне компонента

Частая причина «свойство есть в админке, но не выводится» - забыли добавить код свойства в параметр PROPERTY_LIST компонента (для news.list, catalog.section и подобных). Если код не указан в параметрах компонента, PHP просто не подтянет его в arResult, и никакой отладкой шаблона это не лечится - только правкой .php компонента страницы.

Когда свойство доступно в результате, обращаться к нему в шаблоне можно так:

foreach ($arResult['ITEMS'] as $arItem) {
    $file = $arItem['PROPERTIES']['PDF_FILE']['VALUE'];
    if ($file) {
        $arFile = CFile::GetFileArray($file);
        echo 'Скачать инструкцию';
    }

    if (!empty($arItem['PROPERTIES']['COLOR']['VALUE'])) {
        echo $arItem['PROPERTIES']['COLOR']['VALUE'];
    }
}

Если работаете напрямую через CIBlockElement::GetList без компонента (например, в кастомном обработчике или ajax-хендлере), значения свойств нужно запрашивать отдельно через GetPropertyValues или флаг выборки, иначе получите только фиксированные поля элемента. Для больших выборок - от пары тысяч элементов - я всегда включаю кэширование результата через CACHE_TYPE => "A" в параметрах компонента, иначе каждый проход по свойствам превращается в JOIN на несколько таблиц при каждом хите.

Частые ошибки при работе со свойствами инфоблоков

За годы поддержки чужих проектов на Битрикс список повторяющихся косяков почти не меняется:

• Меняют код свойства после того, как на него уже завязан шаблон - вывод пропадает без ошибок в логах, потому что PHP просто не находит ключ в массиве
• Забывают включить свойство в PROPERTY_LIST компонента после добавления нового поля в админке
• Держат справочник на сотни значений в типе «Список» вместо Highload-блока - админка виснет, а разработчики жалуются на «медленный Битрикс», хотя дело в структуре данных
• Не проставляют свойства в SMART_FILTER_PROPERTY_ID для умного фильтра каталога - фильтр либо не показывает нужный атрибут, либо пересчитывается по 10-15 секунд на разделах с большим количеством товаров
• Дублируют XML_ID у значений списочных свойств при повторных обменах с 1С - в итоге при каждой синхронизации плодятся новые варианты вместо переиспользования существующих

Отдельно скажу про кастомные типы свойств - когда стандартных S/N/L/F/E не хватает и нужен, например, виджет выбора координат на карте или интеграция с внешним справочником через API. Это уже не настройка через админку, а класс, наследующий CIBlockPropertyTools, с собственным обработчиком отображения и сохранения значения. На такие доработки - как и на связку инфоблоков с CRM или эквайрингом - я обычно закладываю отдельную разработку под конкретную бизнес-логику проекта, потому что готового решения из коробки под нестандартный сценарий, как правило, нет.

Частые вопросы

В чём разница между свойством и полем инфоблока?

Поля - фиксированный набор колонок таблицы b_iblock_element, одинаковый для всех инфоблоков: NAME, CODE, PREVIEW_TEXT, ACTIVE, SORT и так далее. Свойства настраиваются отдельно под каждый инфоблок и хранятся в связанных таблицах - через них добавляют любые кастомные атрибуты: цвет, размер, файл сертификата, привязку к другому элементу.

Как вывести свойство типа «Файл» (картинку) в шаблоне?

Значение свойства типа F хранит не путь к файлу, а его ID из таблицы b_file. Чтобы получить URL, нужно передать это значение в CFile::GetFileArray() или CFile::GetPath(), и уже из результата брать поле SRC. Прямой вывод VALUE без преобразования покажет просто цифру.

Сколько свойств можно завести в одном инфоблоке и не тормозит ли это сайт?

Жёсткого лимита в системе нет, я видел рабочие инфоблоки с 60+ свойствами на десятках тысяч элементов. Тормозит не количество свойств само по себе, а неправильный выбор типа (список вместо справочника) и отсутствие кэширования компонентов - при грамотной настройке админка и фронт держат такой объём без проблем.

Как перенести значения при смене типа свойства, например из списка в справочник?

Прямого автоматического конвертера в Битрикс нет - при смене типа старые значения теряют связь с новой структурой. На практике я выгружаю текущие значения через CIBlockElement::GetList в массив, создаю новое свойство нужного типа, а затем прохожу циклом по всем элементам и записываю значения заново через CIBlockElement::SetPropertyValuesEx. На инфоблоке в пару тысяч позиций такой скрипт отрабатывает за пару минут.