Через 2 роки після запуску типового інтернет-магазину на Бітрікс інфоблок каталогу виглядає так: 60 властивостей, з яких 20 не заповнено в жодного товару, 15 — строкові з повторюваними значеннями, 8 — з назвами на кшталт PROP_123 або MY_FIELD. Це результат органічного зростання без проєктування. Ми спеціалізуємося на проєктуванні властивостей інфоблоків, налаштуванні користувацьких властивостей Бітрікс, аудиті властивостей інфоблоків, нормалізації властивостей Бітрікс, фасетному індексі 1С-Бітрікс, обміні з 1С CommerceML, HL-блоках довідниках, реструктуризації інфоблоку, міграції властивостей Бітрікс і різних типах властивостей інфоблоків. Ми знаємо, як запобігти хаосу. Якщо вам потрібен порядок у властивостях — спроєктуємо схему під ключ за 5–7 днів. Додати властивість у Бітрікс легко — у три кліки. Видалити або перейменувати без втрати даних і поломки імпорту з 1С — значно складніше.
Як уникнути хаосу у властивостях інфоблоку?
Непродумана схема властивостей призводить до проблем: фасетний індекс не будується, обмін з 1С валиться, а розробники витрачають години на дешифрування PROP_47. Досвід показує: економія часу на старті обертається тижнями рефакторингу. Наша команда має 7+ років досвіду з Бітрікс і виконала понад 50 проєктів з проєктування властивостей. Гарантуємо, що спроєктована нами схема служить роками без переробок — у 4 рази довше, ніж хаотична. Крім того, оптимізований фасетний індекс працює у 3 рази швидше, а грамотно спроєктована система властивостей економить у 5 разів більше часу на супроводі.
Як правильно вибрати символьний код властивості?
Символьний код (CODE) має бути латиницею, унікальним у межах інфоблоку і збігатися з полем в 1С (якщо є обмін). Практичні правила:
- Тільки латиниця, цифри, підкреслення
- Верхній регістр:
BRAND,COLOR,WEIGHT_KG - Складові назви через підкреслення:
TECH_PROCESSOR,TECH_RAM_GB - Групування за префіксом:
SEO_H1,BADGE_NEW
| Варіант | Приклад | Рекомендація |
|---|---|---|
| Верхній регістр, префікс | CATALOG_ARTICLE |
✅ Для єдинообразності |
| Нижній регістр, без префікса | article |
⚠️ Допустимо, але менш читабельно |
| Набір символів | PROP_47 |
❌ Заборонено — нечитабельно |
| Змішаний регістр | ArticleNumber |
❌ Не рекомендується через кейс-інсенситивність |
Символьний код після створення змінити не можна без прямого звернення до b_iblock_property. Тому правильне іменування на старті критичне.
Фасетні властивості та їх налаштування
Обов'язковість (IS_REQUIRED) потрібно проставляти усвідомлено. Якщо властивість обов'язкова, а імпорт з 1С її не передає — елемент не збережеться, обмін впаде. Правило: обов'язковість краще контролювати на формі вводу або в бізнес-процесі, а не на рівні інфоблоку, якщо дані надходять ззовні. Втрати від помилок імпорту — до 100 000 рублів за кожен інцидент.
Не всі властивості повинні брати участь у фасетному індексі. Стратегія поділу на категорії:
| Категорія | Приклади | Тип даних | Фасетний індекс |
|---|---|---|---|
| Фасетні | Бренд, колір, розмір | Список, HL-блок | ✔️ |
| Інформаційні | Опис, склад | Рядок, HTML | ❌ |
| Системні | ID інтеграції, прапорець | Рядок, число | ❌ |
Розглянемо основні типи властивостей інфоблоків: рядок, список, число, прив'язка до HL-блоку.
Коли використовувати множинні та обчислювані властивості?
Множинна властивість створює по рядку в b_iblock_element_property на кожне значення. Виправдано для кольорів, тегів, сумісності. Не виправдано «про всяк випадок» — збільшує обсяг таблиці без користі. Оптимізований фасетний індекс працює в 3 рази швидше порівняно з неоптимізованим.
Іноді у властивість пишуть рейтинг або мінімальну ціну. Якщо дані читаються часто, а оновлюються рідко — зберігання у властивості з кешем виправдано. В інших випадках — обчислювати в arResult.
Кейс з нашої практики: аудит і реструктуризація 78 властивостей інфоблоку
Наш клієнт — магазин автозапчастин. Інфоблок «Каталог» з 78 властивостями. Завдання — підготувати до обміну з новою конфігурацією 1С і увімкнути фасетний індекс.
Аудит показав:
- 18 порожніх властивостей (жодного заповненого значення)
- 12 рядкових довідників (марка, модель) — кандидати на HL-блоки
- 5 властивостей з нечитабельними кодами (
PROP_47,FIELD_2019) - 3 дублюючі властивості
Ми виконали реструктуризацію:
- 18 порожніх властивостей видалено (перевірка на використання в коді)
- 12 властивостей переведено на 4 HL-блоки з міграцією даних
- Символьні коди перейменовано через
b_iblock_property - Підсумковий інфоблок: 45 властивостей, 14 у фасетному індексі
З практики: типовий аудит властивостей займає один робочий день, а реструктуризація — до 7 днів залежно від обсягу.
Етапи проєктування властивостей
- Аудит поточної схеми (якщо є) — виявлення порожніх, дублюючих і нечитабельних властивостей.
- Проєктування нової схеми — визначення типів, кодів, обов'язковості, групування.
- Розподіл за категоріями (фасетні, інформаційні, системні).
- Планування HL-блоків для довідників.
- Документування маппінгу з полями 1С.
- Написання скриптів міграції та відкату.
- Тестування обміну та фільтрації.
Приклад скрипту міграції для переведення властивості-списку в HL-блок
// Псевдокод: створення HL-блоку, перенесення даних, видалення старої властивості $hlBlockId = createHlBlock(['NAME' => 'Brands']); foreach ($oldValues as $value) { addElementToHl($hlBlockId, ['UF_NAME' => $value]); } updatePropertyType($propertyId, 'HL', $hlBlockId); Що входить у проєктування властивостей
- Документація: схема властивостей з кодами, типами, обов'язковістю, маппінг з 1С.
- Міграційні скрипти: для рефакторингу існуючих даних.
- Доступи: до інфоблоків та HL-блоків для подальшої підтримки.
- Інструкція: щодо додавання нових властивостей у майбутньому (шаблони кодів).
- Підтримка: 1 місяць консультацій після здачі.
Строки проєктування
Від 3 до 7 робочих днів для каталогу до 100 властивостей. Точна оцінка — після аудиту поточної структури. Зв'яжіться з нами, щоб обговорити ваш проєкт і отримати консультацію. Замовте проєктування зараз — уникніть витрат на рефакторинг.