Розробка сайту заходів на 1С-Бітрікс

Розробка сайту заходів на 1С-Бітрікс

Сайт конференції — це транзакційна система, а не сторінка з розкладом. Реєстрація учасників, продаж квитків, розсилка повідомлень, генерація QR-кодів для входу, особистий кабінет — усе це працює на модулях sale, catalog, subscribe та інфоблоках. Помилка в архітектурі даних на старті — і через півроку при запуску другого заходу з'ясовується, що інфоблок «Заходи» містить і спікерів, і розклад, і квитки в одній плоскій структурі. Переробляти на проді — мігрувати дані, переписувати шаблони компонентів, перебудовувати логіку кошика.

Структура інфоблоків

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

Інфоблок «Заходи» (тип events) — основна сутність. Властивості:

• DATE_START, DATE_END — тип «Дата/час». Використовуються у фільтрації та сортуванні, індекс на b_iblock_element_property за IBLOCK_PROPERTY_ID + VALUE_DATE обов'язковий
• VENUE — прив'язка до елемента інфоблоку «Майданчики» або Highload-блоку. Майданчик містить адресу, координати, місткість залу
• CAPACITY — числове, максимальна кількість учасників. Перевіряється при оформленні замовлення через обробник OnSaleOrderBeforeSaved
• STATUS — список: «Реєстрація відкрита», «Реєстрація закрита», «Завершено», «Скасовано»
• STREAM_URL — рядок, посилання на трансляцію (YouTube/Vimeo). Відображається лише авторизованим учасникам з оплаченим квитком
• SCHEMA_ORG — обчислюване, не зберігається в БД. Формується в result_modifier.php компонента детальної сторінки

Інфоблок «Спікери» (тип speakers) — окремий від заходів. Один спікер виступає на кількох заходах, прив'язка через множинну властивість типу «Прив'язка до елемента» (E). Властивості: PHOTO (файл), BIO (HTML/текст), COMPANY, POSITION, SOCIAL_LINKS (множинний рядок).

Інфоблок «Розклад» (тип schedule) — один елемент = один слот. Властивості:

• EVENT_ID — прив'язка до заходу
• SPEAKER_ID — множинна прив'язка до спікерів
• TIME_START, TIME_END — час всередині дня
• HALL — зал/потік (для паралельних секцій)
• SLOT_TYPE — список: «Доповідь», «Воркшоп», «Перерва», «Нетворкінг»

Інфоблок «Квитки» (тип tickets) — зв'язка з модулем catalog. Кожен тип квитка — елемент інфоблоку, підключений як товар торгового каталогу. Властивості: EVENT_ID, TICKET_TYPE (стандарт, VIP, онлайн), AVAILABLE_SEATS, VALID_UNTIL.

Чому не Highload для всього? Спікери й розклад — це десятки-сотні записів. Інфоблоки дають штатні компоненти news.list, news.detail, візуальний редактор в адмінці. Highload доречний для майданчиків (якщо їх понад 500) і для логу check-in (тисячі записів QR-сканувань).

Продаж квитків: ядро системи

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

Товар = елемент інфоблоку «Квитки», підключеного до торгового каталогу через CCatalog::Add(). Кожен тип квитка на кожен захід — окремий товар. Конференція на 500 осіб із трьома типами квитків — три товари в каталозі, кожен зі своїм залишком на складі.

Складський облік реалізує обмеження місткості. Створюється склад у модулі catalog, у кожного товару-квитка встановлюється кількість = доступне число місць. При оформленні замовлення модуль sale автоматично зменшує залишок. Коли залишок = 0, кнопка «Купити» замінюється на «Квитки розпродано» — через перевірку CCatalogProduct::GetByID() у шаблоні компонента.

Процес оформлення замовлення:

1. Користувач обирає захід і тип квитка
2. Додавання до кошика через \Bitrix\Sale\Basket::addItem() — не через застарілий CSaleBasket::Add()
3. На етапі оформлення — кастомний крок order.ajax із полями: ПІБ учасника, email, телефон, компанія. Дані записуються у властивості замовлення (\Bitrix\Sale\Order::setField()) та у властивості кошика
4. Оплата через платіжну систему: ЮKassa, Stripe або PayPal. Налаштування через модуль sale → «Платіжні системи» → обробник yookassa або кастомний обробник у local/php_interface/include/sale_payment/
5. Після успішної оплати — подія OnSalePaymentEntitySaved. Обробник генерує QR-код, надсилає email із квитком, створює запис у CRM

Контроль місткості в реальному часі. Стандартний складський облік працює на рівні замовлення, але між додаванням у кошик та оплатою минає час. Щоб не продати 501 квиток на 500 місць:

• Обробник OnSaleOrderBeforeSaved перевіряє поточний залишок і відхиляє замовлення, якщо місць немає
• М'яке резервування через CCatalogProduct::Update() зі зменшенням QUANTITY при додаванні до кошика та поверненням через 30 хвилин по агенту, якщо замовлення не оформлено

Промокоди — через catalog.discount. Правило знижки з умовою «Промокод = X», тип знижки — відсоток або фіксована сума. У шаблоні sale.order.ajax додаємо поле введення промокоду, застосування через \Bitrix\Sale\Discount::setBasketItemDiscount(). Для раннього бронювання — знижка з умовою за датою: діє до визначеної дати, вимикається автоматично.

Реєстрація та інтеграція з CRM

Реєстрація на безкоштовний захід — без модуля sale. Кастомний компонент project:event.register із формою:

• Валідація на фронті (JS) та на бекенді (в component.php)
• Запис у Highload-блок «Реєстрації»: EVENT_ID, USER_ID, STATUS, REGISTERED_AT
• Створення ліда в CRM через REST API: CRest::call('crm.lead.add', [...]) або через модуль crm напряму, якщо Бітрікс24 розгорнуто на тому ж сервері

Для платних заходів реєстрація відбувається автоматично при оплаті замовлення. Обробник OnSalePaymentEntitySaved створює запис у Highload-блоці й оновлює статус ліда в CRM.

Особистий кабінет учасника будується на sale.personal.section із кастомним шаблоном:

• Список зареєстрованих заходів (вибірка з Highload-блоку за USER_ID)
• Історія замовлень і квитки (штатний sale.personal.order)
• Завантаження квитка з QR-кодом (PDF через TCPDF або Dompdf)
• Доступ до трансляції (посилання на STREAM_URL з'являється за 30 хвилин до початку)
• Сертифікат учасника після заходу (PDF із даними з Highload-блоку)

QR-код і check-in

При успішній оплаті генерується QR-код. Вміст — унікальний хеш замовлення: md5($orderId . $userId . $salt). Хеш зберігається у властивості замовлення QR_HASH.

Генерація QR — бібліотека endroid/qr-code (Composer-пакет, підключається в local/php_interface/). QR вставляється в PDF-квиток і надсилається на email.

На вході — мобільний застосунок або веб-сторінка /check-in/ зі сканером камери (бібліотека html5-qrcode). Сканований хеш відправляється POST-запитом на /api/checkin/, контролер перевіряє:

1. Чи існує замовлення з таким QR_HASH
2. Чи оплачено замовлення (\Bitrix\Sale\Order::isPaid())
3. Чи не був квиток вже використаний (поле CHECKED_IN у властивостях замовлення)

При успіху — оновлення властивості замовлення, запис у лог check-in (Highload-блок), відповідь 200 із даними учасника.

Календар заходів

Два підходи:

Кастомний компонент + FullCalendar.js. Компонент project:event.calendar віддає JSON-масив заходів через AJAX. На фронті — FullCalendar із eventSources, що вказує на /api/events/calendar/. Кожна подія містить title, start, end, url (посилання на детальну сторінку), color (за типом заходу). Кешування JSON-відповіді — 10 хвилин із тегованим кешем по інфоблоку заходів.

Штатний компонент iblock.element.list із кастомним шаблоном, що виводить сітку за датами. Простіший у підтримці, але менш інтерактивний — немає перемикання місяць/тиждень/день без кастомного JS.

Для серій заходів (щорічна конференція) — фільтрація за розділом інфоблоку. Кожен рік = розділ, заходи всередині = елементи.

Таймер зворотного відліку та трансляція

Таймер — JS-компонент, що зчитує DATE_START заходу з data-атрибута. Серверний час передається через <?= time() ?> для синхронізації. Жодного зовнішнього API — чистий setInterval із розрахунком різниці.

Трансляція — iframe YouTube/Vimeo, обгорнутий у компонент із перевіркою доступу. Компонент project:event.stream у component.php перевіряє:

• Чи авторизований користувач
• Чи є оплачене замовлення з квитком типу «Онлайн» або «VIP» на цей захід
• Чи не закінчився захід

Якщо перевірка не пройдена — редирект на сторінку придбання квитка.

Email-повідомлення

Модуль subscribe + поштові події модуля main:

• Підтвердження реєстрації — поштова подія EVENT_REGISTER_CONFIRM, шаблон у «Налаштування» → «Поштові події»
• Квиток після оплати — EVENT_TICKET_PAID, із вкладенням PDF
• Нагадування за 24 години — агент CAgent, що вибирає заходи з DATE_START = завтра і надсилає листи зареєстрованим учасникам через CEvent::Send()
• Зміна розкладу — обробник OnAfterIBlockElementUpdate на інфоблоці «Розклад», розсилає оновлення учасникам заходу

SEO: розмітка Schema.org Event

У result_modifier.php детальної сторінки заходу формується JSON-LD:

{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "...",
  "startDate": "2025-09-15T10:00:00+03:00",
  "endDate": "2025-09-15T18:00:00+03:00",
  "location": {
    "@type": "Place",
    "name": "...",
    "address": "..."
  },
  "offers": {
    "@type": "Offer",
    "price": "...",
    "priceCurrency": "UAH",
    "availability": "https://schema.org/InStock",
    "validFrom": "..."
  },
  "performer": [...]
}

Розмітка виводиться в <head> через $APPLICATION->AddHeadString(). Поле availability оновлюється динамічно: InStock при наявності квитків, SoldOut при нульовому залишку.

Мульти-заходи: серії та щорічні конференції

Розділи інфоблоку «Заходи» працюють як групування: «Конференція 2024», «Конференція 2025». Спільні дані серії (опис, логотип, архів) — властивості розділу через CIBlockSection::GetList().

Для річних звітів та аналітики (скільки учасників за 3 роки, динаміка продажів) — кастомний компонент із вибіркою з b_sale_order за властивістю EVENT_ID і групуванням за роками.

Етапи розробки

1. Проєктування (1-2 тижні) — структура інфоблоків, схема даних, прототипи сторінок, опис бізнес-процесів реєстрації та оплати
2. Дизайн (1-2 тижні) — макети сторінок: каталог заходів, детальна, розклад, особистий кабінет, check-in
3. Бекенд (2-4 тижні) — інфоблоки, торговий каталог, компоненти реєстрації й оплати, інтеграція з платіжною системою, генерація QR
4. Фронтенд (2-3 тижні) — шаблони компонентів, календар, таймер, адаптив, сторінка check-in зі сканером
5. Інтеграції (1-2 тижні) — CRM, email-повідомлення, трансляція
6. Тестування (1-2 тижні) — функціональне, оплата в тестовому режимі, навантажувальне (імітація 500 одночасних покупок)
7. Запуск (3-5 днів) — деплой, моніторинг, перевірка на реальному заході

Терміни залежать від кількості типів квитків, інтеграцій із зовнішніми сервісами та вимог до особистого кабінету учасника.