Разработка сайта мероприятий на 1С-Битрикс — это построение транзакционной системы: регистрация, продажа билетов, генерация QR-кодов, личный кабинет, интеграция с CRM и платёжными шлюзами. Ошибка на старте, например хранение докладчиков, расписания и билетов в одном инфоблоке, приводит к болезненной миграции данных через полгода, когда запускается второе мероприятие. Мы решаем эти проблемы, опираясь на многолетний опыт и проверенные архитектурные решения.
Какие минимальные инфоблоки нужны?
Для сайта мероприятий нужны минимум четыре инфоблока. Можно обойтись тремя, склеив расписание с мероприятиями, — но при появлении многодневных конференций с параллельными потоками это решение разваливается.
Инфоблок «Мероприятия» (тип events) — основная сущность. Свойства: DATE_START, DATE_END (тип «Дата/время», обязателен индекс на b_iblock_element_property), VENUE (привязка к Highload-блоку площадок), CAPACITY (проверяется в OnSaleOrderBeforeSaved), STATUS (список состояний), STREAM_URL (доступ после оплаты), SCHEMA_ORG (вычисляемое поле для JSON-LD).
Инфоблок «Спикеры» — отдельный, с множественной привязкой к мероприятию. Содержит фото, био, компанию, должность и ссылки на соцсети.
Инфоблок «Расписание» — каждый элемент = слот со временем, привязкой к мероприятию и спикеру, типом (доклад, воркшоп, перерыв).
Инфоблок «Билеты» — товары торгового каталога. Каждый тип билета — отдельный элемент со свойствами EVENT_ID, TICKET_TYPE, AVAILABLE_SEATS, VALID_UNTIL.
Почему не Highload-блоки? Для спикеров и расписания данных мало, а инфоблоки дают готовые компоненты и визуальный редактор. Highload оправдан для площадок (500+ записей) и логов check-in.
Как организовать продажу билетов на Битрикс?
Это центральная и самая сложная часть. Билет — товар в каталоге, но с нестандартной логикой: привязка к дате, именные, ограниченные по количеству.
Товар = элемент инфоблока «Билеты», подключённого к торговому каталогу. Каждый тип билета на каждое мероприятие — отдельный товар. Конференция на 500 человек с тремя типами билетов — три товара, каждый со своим остатком на складе.
Складской учёт автоматически уменьшает остаток при добавлении в корзину. Когда остаток = 0, кнопка «Купить» заменяется на «Билеты распроданы» — проверка через CCatalogProduct::GetByID() в шаблоне.
Процесс оформления заказа включает кастомный шаг с полями участника, оплату через ЮKassa, Stripe или PayPal, и событие OnSalePaymentEntitySaved, генерирующее QR-код и отправляющее email. Промокоды реализуются через catalog.discount с условием по промокоду.
Обработчик OnSaleOrderBeforeSaved отклоняет заказ, если мест нет. Дополнительное резервирование — уменьшение QUANTITY при добавлении в корзину с возвратом через 30 минут по агенту. 1С-Битрикс: Агенты в этом случае снимают резерв. Это предотвращает двойные продажи при высокой нагрузке.
Личный кабинет и уведомления
Для бесплатных мероприятий — кастомный компонент с записью в Highload-блок и созданием лида в CRM через REST API. Для платных — автоматическая регистрация при оплате.
Личный кабинет участника на sale.personal.section с кастомным шаблоном: список мероприятий, история заказов, скачивание PDF-билета с QR-кодом, доступ к трансляции (ссылка появляется за 30 минут до начала), сертификат участника.
Таймер обратного отсчёта — JS на setInterval с серверным временем. Трансляция — компонент с проверкой доступа: авторизация, оплаченный билет, время. При несоответствии — редирект на покупку.
Email-уведомления через модуль subscribe: подтверждение регистрации, билет после оплаты (с PDF), напоминание за 24 часа (агент), изменение расписания (обработчик OnAfterIBlockElementUpdate).
SEO и календарь
Schema.org Event — в result_modifier.php формируется JSON-LD разметка с полями name, startDate, location, offers, performer. Поле availability динамически меняется на InStock или SoldOut.
Календарь мероприятий: кастомный компонент + FullCalendar.js — интерактивный, с кешированием, загружается в 3 раза быстрее штатного при 50 событиях. Для простых списков подойдёт штатный iblock.element.list.
Какие этапы включает разработка сайта мероприятий?
Процесс делится на семь этапов: проектирование (1–2 недели), дизайн (1–2), бэкенд (2–4), фронтенд (2–3), интеграции (1–2), тестирование (1–2), запуск (3–5 дней). Ориентировочные сроки зависят от масштаба:
| Масштаб проекта | Ориентировочные сроки |
|---|---|
| Одно мероприятие, регистрация без оплаты | 3–5 недель |
| Мероприятие с продажей билетов и QR | 6–9 недель |
| Платформа серии мероприятий с личным кабинетом | 8–12 недель |
Что входит в работу
| Этап | Результат |
|---|---|
| Анализ требований | Техническое задание, прототип |
| Проектирование архитектуры | Схема инфоблоков, HL-блоков, агентов |
| Разработка компонентов | Бэкенд-логика, шаблоны, API |
| Интеграции | Платёжные системы, CRM, 1С, СДЭК |
| Генерация QR | Библиотека endroid/qr-code |
| Check-in | Вход по QR, верификация |
| Тестирование | Нагрузочное (имитация 500 покупок) |
| Документация и обучение | Административная инструкция |
| Гарантийная поддержка | 1 месяц после запуска |
Автоматизация продажи билетов окупается уже после двух мероприятий за счёт сокращения ручного труда. Получите консультацию по архитектуре вашего сайта мероприятий — наши инженеры подберут оптимальную структуру инфоблоков и интеграций. Свяжитесь с нами, чтобы обсудить ваш проект.