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

Если товары, вакансии и новости лежат в инфоблоках одного типа, администраторы рано или поздно начинают путать настройки, а разработчики — фильтры и шаблоны. В 1С-Битрикс собственный тип инфоблока задаёт логическую группу, а свойства описывают элементы внутри конкретного инфоблока. Ошибка в этой схеме обходится не строкой кода, а миграциями, ручной чисткой данных и сломанными фильтрами.

Сначала границы, потом поля

Дальше речь о классическом API модуля «Информационные блоки» в 1С-Битрикс Управление сайтом 23.x–24.x. В проектах с более новой версией проверьте актуальность методов и полей по документации вашей установки. D7 и старый API не стоит смешивать в одном примере без необходимости.

Тип инфоблока группирует инфоблоки в административной части. Например, отдельный тип «Каталог» уместен для товарных инфоблоков, если у них общий смысл и свои права или настройки. Само по себе создание типа не создаёт каталог и не добавляет свойства: это отдельные сущности.

Перед настройкой ответьте на три вопроса:

• Какие данные принадлежат каждому элементу? Это свойства инфоблока.
• Какие данные общие для всего инфоблока — например, тип контента или назначение каталога? Возможно, это поле элемента лишнее: его место в настройке инфоблока.
• Есть ли у поля отдельный смысл для пользователей, импорта, поиска или фильтра? Если нет, новое свойство может только усложнить поддержку.

Свойство¹ — дополнительное поле элемента инфоблока: строка, число, список, файл, привязка к разделу или другому элементу. Это не то же самое, что стандартные поля элемента, например название и дата активности.

Выбирайте код как часть интерфейса проекта

У типа и свойств есть символьные коды. Их используют в компонентах, фильтрах, импорте и пользовательском коде. Выбирайте короткие устойчивые коды латиницей: catalog, COLOR, VENDOR_CODE. Название можно отредактировать для редакторов, код лучше считать контрактом.

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

Свойство — не способ спрятать структуру данных

Если значение повторяется и должно иметь собственные поля, историю или независимое управление, одной строкой обычно не обойтись. Например, хранить несколько характеристик товара в одной строке с разделителями удобно только до первого запроса на фильтрацию. Для связанного справочника рассмотрите отдельный инфоблок и свойство-привязку.

А если у каждого элемента одно значение, множественное свойство не нужно. Оно влияет на форму редактирования, чтение данных и логику фильтрации. Лучше включать множественность только под конкретный сценарий.

Как описывать свойства без сюрпризов

В классическом API свойство создают через CIBlockProperty::Add. Поля IBLOCK_ID, NAME, CODE и PROPERTY_TYPE задают его принадлежность, название, код и тип. Ниже — пример для строки; перед запуском подставьте ID существующего инфоблока и проверьте результат в тестовой базе.

<?php
// 1С-Битрикс Управление сайтом 23.x–24.x, классический API
if (!\Bitrix\Main\Loader::includeModule('iblock')) {
    throw new \RuntimeException('Не удалось подключить модуль iblock');
}

$property = new CIBlockProperty();
$propertyId = $property->Add([
    'IBLOCK_ID' => 17,
    'NAME' => 'Артикул поставщика',
    'ACTIVE' => 'Y',
    'SORT' => 100,
    'CODE' => 'VENDOR_CODE',
    'PROPERTY_TYPE' => 'S',
    'MULTIPLE' => 'N',
    'IS_REQUIRED' => 'N',
    'FILTRABLE' => 'Y',
]);

if (!$propertyId) {
    throw new \RuntimeException($property->LAST_ERROR);
}

Проверка после создания — свойство видно в настройках нужного инфоблока, имеет ожидаемый тип, а тестовый элемент сохраняет значение. Число 17 здесь пример ID, а не универсальная константа. В автоматизации не храните ID как предположение: получайте нужный инфоблок по устойчивому коду и проверяйте, что нашли ровно один.

Фильтруемость и обязательность — разные решения

FILTRABLE нужен, когда значение должно участвовать в фильтрации. Не включайте его для каждого свойства «на будущее»: настройки компонента и нагрузка на выборки зависят от конкретного способа чтения данных. Обязательность тоже не заменяет валидацию интеграции: импорт может обходить привычный сценарий заполнения, поэтому проверяйте данные на входе.

Для списка заранее решите, кто управляет вариантами и нужно ли хранить внешний идентификатор значения. Для привязки к элементу определите целевой инфоблок. Для файла договоритесь о правилах обновления: импорт не должен случайно заменять загруженный редактором файл пустым значением.

Подходы: руками, через код или миграцию

Для одного проекта с ручным управлением подойдёт админка, если изменения документируют. Для нескольких окружений лучше миграция или проверяемый скрипт: иначе тест и прод со временем расходятся. Не запускайте создание свойства вслепую при каждом деплое — сначала найдите его по коду внутри нужного инфоблока, сравните параметры, затем создавайте или обновляйте согласно принятой стратегии.

Код свойства — это договор между настройками Битрикс, шаблоном, импортом и фильтром. Менять его без проверки всех потребителей опаснее, чем поменять подпись в административной форме.

Что ломается на практике

• Свойство создали не в том инфоблоке. Тип объединяет инфоблоки, но свойства принадлежат конкретному инфоблоку. Проверяйте ID и код целевого объекта.
• Фильтр не видит значение. Проверьте код свойства, настройки фильтра компонента и флаг фильтруемости. Сверьте это на элементе с заполненным значением.
• Код дублируется. Поиск по коду должен учитывать инфоблок. Перед созданием проверьте существующую структуру, включая неактивные свойства.
• Редактор не понимает, что вводить. Уточните подпись, подсказку, тип и формат. Поле «число» не объясняет, в каких единицах вводить массу или длину.
• Импорт перезаписывает ручные данные. Разделите ответственность за заполнение: зафиксируйте, какие свойства принадлежат источнику, а какие — редактору.

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

Что делать дальше

Составьте реестр свойств: код, тип, множественность, источник данных, фильтруемость и потребители в коде. Затем сравните его с настройками тестового инфоблока и проверьте один полный цикл данных. Отдельная тема — перенос значений при изменении типа или кода; не меняйте их на боевом проекте без плана миграции и резервной копии.

¹ В документации Битрикс свойства элементов инфоблока также встречаются под названием «свойства инфоблока»; не путайте их с пользовательскими полями других сущностей.