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

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

Сайт театру стикається з проблемою, яку не вирішує жодний шаблонний підхід: сітка афіш. Один спектакль йде на трьох площадках, з різним складом, у різні дати, з різними цінами. Глядач хоче вибрати конкретне місце в залі, побачити вид зі свого ряду та оплатити квиток за 40 секунд. Якщо хоч одна ланка гальмує — він йде на Афішу або Радаріо, де театр платить комісію з кожного квитка.

На 1С-Бітрікс такий сайт збирається з комбінації інфоблоків для контентної частини та модуля sale для квиткової. Головне інженерне завдання — SVG-схема залу з блокуванням місць у реальному часі.

Репертуар та розклад: два інфоблоки замість одного

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

Інфоблок Repertoire — карточка спектаклю:

• PROPERTY_GENRE — жанр (драма, комедія, мюзикл, балет, опера — довідник)
• PROPERTY_AGE_RATING — вікові обмеження (0+, 6+, 12+, 16+, 18+)
• PROPERTY_DURATION — хронометраж з антрактом та без (два числових поля)
• PROPERTY_PREMIERE_DATE — дата прем'єри
• PROPERTY_DIRECTOR — режисер (привязка до інфоблоку Staff)
• PROPERTY_CAST — основний склад (множинна привязка до Staff)
• PROPERTY_SCENE — площадка (Основна, Мала, Камерна — привязка до Venues)
• PROPERTY_TRAILER — відеотрейлер (YouTube / Vimeo)
• PROPERTY_GALLERY — фотогалерея (множинний файл)
• PROPERTY_PRESS — рецензії (множинний HTML з джерелом та цитатою)
• PROPERTY_IN_REPERTOIRE — чекбокс (зняті з репертуару залишаються в архіві для SEO)

Інфоблок Schedule — конкретні покази:

Зв'язка «один спектакль — багато показів» дає можливість на сторінці спектаклю вивести всі найближчі дати, а в календарній афіші — усі покази з фільтрацією за датою, жанром та площадкою. Компонент bitrix:news.list з фільтром >=PROPERTY_DATETIME за поточною датою та сортуванням за датою — на головну. Минулі покази автоматично йдуть з афіші, але сторінка спектаклю з фотографіями та рецензіями живе.

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

SVG-схема залу та продаж місць

Технічно найважчий блок. Тут перетинаються фронтенд (інтерактивна карта місць), бекенд (блокування, атомарні транзакції) та інфраструктура (Redis для тимчасових блокувань).

SVG-файл залу. Кожен зал — окремий SVG, де кожне місце — елемент з data-атрибутами:

<circle
  data-row="7"
  data-seat="14"
  data-zone="parter"
  data-category="A"
  cx="312" cy="285" r="6"
  class="seat seat--available"
/>

Атрибут data-category привязує місце до цінової категорії. Категорії зберігаються в HL-блоці SeatCategories: A — центр партеру (найкраща видимість), B — бічні секції, C — балкон, D — ложа, E — галерея. Для кожного показу — своя цінова сітка. Буденний вечір у грудні та суботній передноворічний спектакль — різні гроші за одне й те саме місце.

SVG-файли завантажуються в інфоблок Venues як властивість PROPERTY_SVG_MAP. Один раз підготував файл — далі він використовується для всіх показів у цьому залі.

Інтерактив на фронтенді. При відкритті сторінки покупки:

1. Завантажується SVG-схема залу з інфоблоку
2. AJAX-запит повертає масив занятих та заблокованих місць для конкретного показу
3. JavaScript розставляє класи: seat--available, seat--occupied, seat--locked, seat--selected
4. При наведенні — підказка: ряд, місце, категорія, ціна
5. При кліку — місце йде в кошик, колір змінюється
6. Pinch-zoom на мобільних та scroll-zoom на настільних (бібліотека svg-pan-zoom)

Для залів на 800–1200 місць SVG містить відповідну кількість елементів. На слабких мобільних пристроях це може гальмувати. Рішення — відрисовування через Canvas з растеризацією SVG: на екрані відображається bitmap, а при зумі — перерахунок області з відрисовуванням окремих місць. Але для залів до 500 місць SVG працює без оптимізацій.

Блокування місць — Redis. Коли глядач клікає на місце, встановлюється тимчасове блокування. Ключ у Redis: lock:show_{id}:row_{r}:seat_{s} з TTL 600 секунд (10 хвилин). Перед записом — SETNX: якщо ключ вже існує, місце заблоковано іншим покупцем, фронтенд отримує помилку та перерисовує місце як занята.

Таймер зворотного відліку видиме покупцю: «Місця зарезервовані на 8:42». Час закінчився — блокування знімається через TTL автоматично, без cron та агентів.

Чому Redis, а не запис у БД? Тому що TTL-механізм Redis гарантує звільнення місць навіть при падінні PHP-процесу. Якщо користувач закрив вкладку — через 10 хвилин місце знову доступне. З записом у b_iblock_element_property довелося б писати окремий агент-чистильник, який викликається раз у хвилину й перевіряє протерміновані блокування. Redis робить це безкоштовно.

Серверна обробка покупки:

1. Повторна перевірка доступності: Redis-блокування + HL-блок SoldSeats
2. Створення замовлення в sale — кожне місце як окрема позиція кошика з ціною за категорією
3. Перенаправлення на платіжну систему (ЮKassa, CloudPayments, Сбер)
4. Обробник OnSalePayOrder фіксує місця як продані в SoldSeats
5. Генерація PDF-квитка з QR-кодом (TCPDF + phpqrcode)
6. Відправлення на email через модуль mail

QR-код містить URL site.ru/ticket/verify/{hash}, де hash — HMAC-SHA256 від ID замовлення та секретного ключа. Контролер при вході сканує QR, система помічає квиток як використаний. Повторний прохід — відмова.

Інтеграція з квитковими системами

Якщо театр уже працює з Радаріо, Ticketland або Яндекс.Афішею — сайт підключається до їхнього API замість власної системи продажів:

При роботі через API партнера SVG-схема підтягується з зовнішної системи, а не з інфоблоку. Адаптер конвертує формат у єдиний внутрішній — фронтенд працює однаково в обох випадках. Якщо театр вирішить піти від Радаріо на власну продаж — перемикається адаптер, інтерфейс залишається попереднім.

Абонементи та подарункові сертифікати

Абонемент — товар у каталозі sale зі властивістю «кількість відвідувань» та терміном дії. При покупці створюється запис у HL-блоці Subscriptions. При бронюванні за абонементом списується одне відвідування замість оплати.

Подарунковий сертифікат реалізується через внутрішні рахунки модуля sale. Покупець платить номінал, отримує PDF з унікальним кодом. Одержувач активує код — кошти зараховуються на внутрішній рахунок.

Трупа та архів

Інфоблок Staff: фото, біографія, ролі (множинна привязка до Repertoire). На сторінці актора — список ролей з фото зі спектаклів. На сторінці спектаклю — склад з аватарами.

Спектаклі, зняті з репертуару, переносяться в архів деактивацією PROPERTY_IN_REPERTOIRE. URL не змінюється — SEO зберігається. Для театру з історією в десятки років архів дає сотні індексованих сторінок з унікальним контентом.

Графік робіт

Паралельна робота дизайнера та розробника скорочує загальний термін на 3–4 тижні. При використанні готового API квиткової системи (Радаріо) етап інтеграції зменшується до 1–2 тижнів. Вартість розраховується індивідуально після аналізу вимог — масштаб залежить від кількості залів, наявності зовнішної квиткової системи та обсягу контенту.