Розширення логіки стандартних компонентів без копіювання 1С-Бітрікс

Ми часто зустрічаємо проекти, де розробники копіюють стандартні компоненти Бітрікс. Це призводить до проблем при оновленнях. Уявіть: ваш інтернет-магазин пропрацював рік. Ви скопіювали catalog.section, додали кастомні поля та рейтинг. Виходить мажорне оновлення — ви витрачаєте два дні на злиття змін. Через півроку знову оновлення — і знову головний біль. Кожна копія компонента перетворюється на технічний борг, який гальмує розвиток і збільшує вартість підтримки.

За нашою статистикою, 80% проектів з копіями компонентів вимагають тотального рефакторингу при переході на нову мажорну версію. Заміна копій на рідні механізми розширення окупається вже через 4-6 місяців: час на оновлення скорочується в 5 разів, зникають баги сумісності.

Ми — команда з 8-річним досвідом розробки на Бітрікс. Завершили 40+ проектів з рефакторингу та модернізації. Допомагаємо компаніям позбутися копій компонентів без втрати функціональності. Зв'яжіться з нами для консультації — оцінимо ваш проект.

Які механізми розширення надає Бітрікс?

Бітрікс пропонує чотири способи розширити логіку стандартного компонента без його копіювання: result_modifier.php, події, класи-розширення та компонент-обгортка.

result_modifier.php — швидке доповнення даних

Файл result_modifier.php у папці шаблону виконується після основної логіки компонента, але до виведення шаблону. Ви отримуєте посилання на $arResult і можете додавати або змінювати дані. Наприклад, підвантажити рейтинги товарів із зовнішнього сервісу:

<?php
// /local/templates/my_site/components/bitrix/catalog.section/.default/result_modifier.php
if (!defined('B_PROLOG_INCLUDED') || B_PROLOG_INCLUDED !== true) die();

$ids = array_column($arResult['ITEMS'], 'ID');
if ($ids) {
    $ratings = MyRatingService::getAverageForItems($ids);
    foreach ($arResult['ITEMS'] as &$item) {
        $item['MY_RATING'] = $ratings[$item['ID']] ?? 0;
    }
}

Цей метод простий, але не дозволяє змінити SQL-запит компонента. Для втручання в запит потрібні події.

Події компонента — втручання на рівні запитів

Більшість стандартних компонентів генерують події. Наприклад, OnBeforeIBlockElementGetList дозволяє модифікувати фільтр вибірки. Ось як приховати товари без ціни:

// /local/php_interface/init.php
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'iblock',
    'OnBeforeIBlockElementGetList',
    function (\Bitrix\Main\Event $event) {
        $filter = $event->getParameter('filter');
        $filter['!CATALOG_PRICE_1'] = false;
        $event->setParameter('filter', $filter);
        return $event;
    }
);

Події дають гнучкість без копіювання компонента. Однак складну бізнес-логіку краще виносити в клас-розширення.

Клас-розширення — максимальна гнучкість

Створюєте клас-спадкоємець у /local/components/bitrix/ім'я_компонента/class.php. Бітрікс автоматично підхопить його замість оригінального. Шаблони при цьому залишаються з /bitrix/. Приклад — додаємо ознаку "новинка" для товарів, створених менш ніж 30 днів тому:

<?php
// /local/components/bitrix/catalog.section/class.php
\Bitrix\Main\Loader::includeModule('iblock');
\Bitrix\Main\Loader::includeModule('catalog');

class MyCatalogSectionComponent extends \Bitrix\Iblock\Component\ElementList
{
    protected function getFilter(): array
    {
        $filter = parent::getFilter();
        $filter['!PREVIEW_PICTURE'] = false; // приховати товари без зображення
        return $filter;
    }
    
    protected function prepareElementData(array $element): array
    {
        $element = parent::prepareElementData($element);
        $element['IS_NEW'] = (time() - strtotime($element['DATE_CREATE'])) < 86400 * 30;
        return $element;
    }
}

Цей підхід зберігає оновлюваність: при виході нової версії Бітрікс ваш клас успадковує покращення батьківського компонента. Порівняйте: ручне злиття копії займає від 2 до 8 годин, а при використанні класу-розширення — 0 годин. Клас-розширення дозволяє успадковувати поведінку стандартного компонента, зберігаючи можливість оновлення ядра (з документації Бітрікс).

Компонент-обгортка — повна заміна логіки

Якщо потрібно повністю перевизначити логіку, але викликати оригінал — створюєте компонент з іншим ім'ям. Використовується рідко, зазвичай для агрегації даних з кількох компонентів.

Зведена таблиця механізмів

Як розширити компонент без втрати оновлень?

Відповідь проста: використовуйте клас-розширення або події. Вони зберігають сумісність з ядром і не вимагають ручного злиття при оновленні. Результат — зниження часу на оновлення на 80% та економія на підтримці до 40%.

Як вибрати підходящий механізм?

Якщо потрібно швидко додати поле — result_modifier.php. Якщо потрібно змінити запит — події. Для серйозної бізнес-логіки — клас-розширення. Компонент-обгортка — для випадків, коли потрібно повністю змінити поведінку.

Як ми реалізуємо розширення компонентів без копіювання?

Наш підхід — використовувати рідні механізми Бітрікс, зберігаючи оновлюваність. Процес включає п'ять етапів:

1. Аудит кодової бази — знаходимо всі копії компонентів, оцінюємо обсяг та складність.
2. Проектування — обираємо оптимальний механізм для кожного випадку.
3. Реалізація — пишемо класи-розширення, обробники подій, модифікатори.
4. Тестування — перевіряємо сумісність з шаблонами та кастомними доробками.
5. Підтримка — надаємо документацію, навчаємо вашу команду та даємо гарантію на 12 місяців.

Що входить в роботу:

• Повна відмова від копій компонентів (рефакторинг).
• Оптимізація запитів та кешування.
• Тестування на всіх канонічних сценаріях.
• Навчання вашої команди роботі з розширеннями.
• Гарантія зворотної сумісності.

Приклад з практики: для інтернет-магазину з каталогом з 50 000 товарів ми замінили 12 копій компонентів на класи-розширення. Час оновлення ядра скоротився з 3 днів до 4 годин. Економія на підтримці — 40% на рік.

Строки та вартість

Точна вартість розраховується індивідуально після аудиту. Готові позбутися копій компонентів? Замовте аудит — наші інженери оцінять проект і запропонують оптимальне рішення.

Неправильний вибір редакції 1С-Бітрікс: як це ламає проект

Купили «Малий бізнес», запустили магазин, трафік виріс — і сайт впав. Композитний кеш тільки в «Бізнес», веб-кластер теж. Апгрейд — доплата різниці плюс робота по налаштуванню нових модулів. Правильний підбір та налаштування редакції 1С-Бітрікс одразу економлять значну частину бюджету на ліцензію та виключають витрати на позаплановий апгрейд. За роки роботи з Бітріксом ми провели багато апгрейдів і бачили всі типові помилки: від покупки «Старту» під великий каталог до використання «Бізнесу» для лендінгу з низькою відвідуваністю. Наш принцип — підібрати редакцію під реальні завдання та налаштувати її так, щоб не переплачувати за непотрібні модулі, але й не впиратися в стелю при першому стрибку трафіку.

Редакції 1С-Бітрікс: Управління сайтом

Чотири редакції, і різниця між ними — не в кількості функцій, а в доступних модулях ядра. Офіційна документація 1С-Бітрікс уточнює: композитний кеш доступний лише в редакції «Бізнес» і вище.

Старт — мінімум, тільки контентні модулі: iblock, form, базове SEO. Для візиток і лендінгів. Модуля sale немає — магазин не побудувати.

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

Малий бізнес — перша редакція з e-commerce: з'являється модуль sale. Комфортний стеля — до ~10 000 товарів без серйозної оптимізації. Для невеликих магазинів і каталогів з замовленням.

Бізнес — повний набір: композитний кеш (TTFB падає з 800 мс до 50–80 мс — в 10–15 разів швидше), веб-кластер, багатосайтовість, мультисклад, REST API. Для великих магазинів, маркетплейсів, проектів з 10 000+ відвідувачів на день.

Як не помилитися з вибором редакції 1С-Бітрікс?

Типові помилки

• Покупка «Старту» під інтернет-магазин — модуль sale відсутній, доведеться або апгрейдити одразу, або костилити через кастомні замовлення.
• Вибір «Малого бізнесу» для проекту, який через півроку виросте до 10 000 товарів — композитний кеш не включити, апгрейд до «Бізнесу» обійдеться в різницю ліцензій плюс робота по налаштуванню.
• Використання «Бізнесу» для лендінгу — переплата за функції, які ніколи не знадобляться.

Чому композитний кеш є must have для високонавантаженого проекту?

Композитний кеш (main.composite) прискорює завантаження сторінок в 10–15 разів порівняно з динамічною генерацією. Для магазину з великим трафіком без композиту сервер починає «потіти»: середній час відповіді зростає, база даних перевантажується, сторінки чекауту падають по таймауту. Композит вирішує проблему кардинально — HTML віддається nginx'ом без запуску PHP. Докладніше про технологію — в офіційній документації. Важливо правильно налаштувати exclude-маски для кошика, особистого кабінету та сторінок, де потрібна актуальність даних. Ми налаштовуємо це на кожному апгрейді до «Бізнес».

Вибір редакції для інтернет-магазину

Як вибрати редакцію: жорсткі критерії

По модулях:

• Обмін з 1С (catalog) → мінімум «Малий бізнес»
• Композитний кеш (main.composite) → тільки «Бізнес»
• Веб-кластер (cluster) → тільки «Бізнес»
• Багатосайтовість → тільки «Бізнес»
• REST API → тільки «Бізнес»

По навантаженню:

• До 1000 уніків/день — будь-яка редакція впорається
• 1000–10 000 уніків/день — «Малий бізнес» з тюнінгом nginx/php-fpm упирається в стелю. «Бізнес» з композитним кешем — правильний вибір
• 10 000+ уніків/день — тільки «Бізнес» з композитом і кластером

По бюджету:

• Різниця між редакціями — варіюється (наприклад, Старт vs Бізнес — значно)
• Апгрейд у будь-який момент — доплата різниці у вартості ліцензій
• Наш принцип: беріть мінімально достатню. Але якщо знаєте, що через півроку знадобиться композит — беріть «Бізнес» одразу, тому що апгрейд — це ще й робота по налаштуванню

Чому апгрейд редакції вигідний при правильному виборі?

1С-Бітрікс дозволяє підвищувати редакцію без перевстановлення — дані зберігаються. Процес:

1. Доплата різниці у вартості ліцензії
2. Активація нового ключа: «Налаштування» → «Оновлення» → «Реєстрація»
3. Встановлення доступних модулів через адмінку
4. Налаштування нового функціоналу
5. Тестування сумісності

Що ми робимо при апгрейді:

• Перевіряємо кастомний код на конфлікти з новими модулями — особливо якщо є власні обробники подій OnBeforeOrderAdd, OnSaleBasketSaved
• Вмикаємо та налаштовуємо композитний кеш — коректні exclude-маски для динамічних сторінок (кошик, чекаут, особистий кабінет)
• Налаштовуємо мультисклад, якщо потрібно — b_catalog_store, правила вибору складу
• Проганяємо весь функціонал на staging
• Документуємо зміни

Що ви отримуєте в результаті:

• Працюючий сайт на новій редакції без втрати даних
• Налаштований композитний кеш (якщо перейшли на «Бізнес»)
• Протокол тестування та рекомендації щодо подальшої оптимізації
• Доступи до staging та документація щодо змін

Ліцензія: продовження та ризики

Активна ліцензія дає оновлення — нові версії, патчі безпеки, багфікси, доступ до маркетплейсу та техпідтримку вендора. При закінченні сайт продовжує працювати, але залишається без оновлень. Для магазинів це небезпечно — патчі безпеки закривають вразливості в модулях sale, catalog, main. Витік даних з b_sale_order або b_user — питання часу. Продовження коштує значно менше покупки нової ліцензії. Регулярне продовження — страховка від незакритих CVE.

Связка «Управління сайтом» + Бітрікс24

Частий сценарій: сайт на 1С-Бітрікс + CRM в Бітрікс24. Замовлення з b_sale_order автоматично перетворюються на ліди або угоди, працює єдина авторизація, синхронізація клієнтської бази. Форми сайту (form або кастомні) ведуть у воронку CRM. Це дві окремі ліцензії та два окремі продукти — інтеграція між ними штатна і стабільно працює.

Рекомендації з практики

• Не економте на редакції, якщо точно знаєте, що функціонал знадобиться через півроку. Апгрейд редакції — та ж доплата плюс робота по налаштуванню та тестуванню.
• Бізнес для проектів з амбіціями зростання — композитний кеш окупає різницю в ціні при першому стрибку трафіку. Без композиту 3000+ уніків/день — сервер починає потіти.
• Бітрікс24 і «Управління сайтом» — різні продукти, різні ліцензії. Плутанина тут коштує грошей.
• Продовжуйте ліцензію щорічно — вартість продовження значно нижча за покупку нової, а без оновлень ви залишаєтеся з незакритими CVE.

Що ми пропонуємо: підбір та налаштування під ключ

Ми не просто консультуємо — беремо на себе повний цикл: аналіз поточного проекту, підбір редакції, закупівлю ліцензії (якщо потрібно), міграцію, налаштування всіх модулів та навчання команди. В рамках послуги ви отримуєте:

• Акт вибору редакції з обґрунтуванням
• План міграції (якщо апгрейд)
• Розгорнутий staging з новою редакцією
• Налаштування композитного кешу та кластеру (при необхідності)
• Документацію по новій конфігурації
• Гарантію працездатності після переходу

Зателефонуйте нам або залиште заявку — розповімо, яка редакція підійде конкретно під ваш проект, навантаження та плани зростання. Замовте консультацію — оцінимо ваш проект за один день і запропонуємо оптимальну конфігурацію. Отримайте персональний розрахунок вартості підбору та налаштування редакції 1С-Бітрікс прямо зараз.