Розробка сайту театру на 1С-Бітрікс під ключ

Розробка сайту театру на 1С-Бітрікс — інженерна задача, де кожна секунда завантаження сторінки коштує глядача. Середній театр втрачає до 2 000 000 гривень на рік на комісіях квиткових операторів (10–30% з кожного квитка). Ми будуємо систему, яка окупається за перший сезон: репертуарна сітка, SVG-схема залу та онлайн-продаж квитків без посередників. Реальний кейс: театр на 600 місць з аншлагом 3 рази на тиждень значно економить, відмовившись від зовнішнього квиткового оператора. Глядач обирає місце за 40 секунд, а сервер обробляє до 2 000 запитів на секунду на піку — завдяки Redis.

Як структура інфоблоків впливає на розробку сайту театру на 1С-Бітрікс?

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

Інфоблок 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 перекриває основний склад на сторінці конкретної дати. Глядач бачить, хто саме грає того вечора, на який він купує квиток.

Чому Redis — ключовий компонент розробки сайту театру на 1С-Бітрікс?

Технічно найважчий блок — 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. При наведенні — tooltip: ряд, місце, категорія, ціна
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С-Бітрікс з тегованого кешування, використання кешування на сторінках вибору місць знижує навантаження на сервер у 5 разів.

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

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 зберігається. Для театру з історією в десятки років архів дає сотні проіндексованих сторінок з унікальним контентом.

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

• Проектування структури інфоблоків та UX-сценаріїв
• Дизайн головної, афіші, картки вистави, вибору місць
• Верстка та адаптивність під усі пристрої
• Програмування інфоблоків, бізнес-логіки, інтеграцій
• Розробка SVG-схем залів та інтерактиву покупки
• Підключення платіжної та/або квиткової системи
• Наповнення контентом та тестування
• Документація, передача доступів, навчання співробітників
• Гарантійна підтримка 3 місяці

Терміни

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

Отримайте консультацію з розробки сайту театру — ми проаналізуємо ваші вимоги та підготуємо комерційну пропозицію. Зв'яжіться з нами, щоб обговорити проект.

Як правильно проектувати інфоблоки?

Ми бачимо десятки проєктів, де неправильна структура інфоблоків перетворює сайт на гальмо. Типовий сценарій: замовник просить «каталог товарів». Розробник створює один інфоблок catalog, закидає туди 15 властивостей. Через півроку — 40 властивостей, 8 з яких використовуються лише для однієї категорії. Фільтр гальмує, таблиця b_iblock_element_property розрослася до мільйонів рядків, CIBlockElement::GetList виконується 3 секунди. Наслідки — падіння конверсії, втрата клієнтів, додаткові витрати на оптимізацію. В одному проєкті після рефакторингу каталогу час генерації сторінки знизився з 4,2 до 0,8 секунди, а вартість підтримки значно скоротилася — за рахунок усунення надлишкових запитів та агентів.

Наш підхід: проектуємо інфоблоки до першого рядка коду. Окремі інфоблоки під сутності (товари, категорії, бренди), властивості-довідники через HL-блоки, торгові пропозиції для SKU. Це закладає продуктивність на роки вперед. Якщо хочете отримати попередній аудит вашої схеми інфоблоків — зв'яжіться з нами, розберемо типові помилки та надамо рекомендації.

Чому 1С-Бітрікс вигідніший за альтернативи?

Вибір CMS диктується не уподобаннями, а бізнес-завданнями. Ось ключові аргументи:

• Нативний обмін з 1С — модуль catalog.import.1c забезпечує двосторонній обмін товарами, цінами, залишками та замовленнями через CommerceML. Без сторонніх модулів. Це в 5 разів швидше, ніж розробка власного обміну на OpenCart або WordPress. Економія на інтеграції — до 200 000 грн порівняно з кастомними рішеннями.
• Проактивний захист — модуль security включає WAF, контроль цілісності файлів, захист від SQL-ін'єкцій, двофакторну автентифікацію. Для проєктів з вимогами ФСТЭК — сертифіковане рішення (згідно з Wikipedia, це стандарт для корпоративних систем).
• Модульна архітектура — підключаємо лише потрібні модулі: iblock, catalog, sale, search. Менше модулів — менше запитів до БД на кожен хіт.
• Регулярні патчі — вендор випускає security-патчі, закриваючи вразливості швидше, ніж open-source проєкти (середній час виправлення CVE — 2 тижні). Офіційна документація по модулях доступна на сайті розробника.

Що дають HL-блоки і як ми прискорюємо каталог

Highload-блоки — це альтернатива розширеним властивостям інфоблоків, коли список значень може зростати до тисяч записів. Типовий приклад: виробники, країни, кольори. Якщо зберігати їх як властивості-списки в інфоблоці, кожна фільтрація викликає повне сканування таблиці b_iblock_property_enum. З HL-блоками вибірка йде по індексу — час відповіді фільтра знижується з 1–2 секунд до 50 мс. Продуктивність HL-блоків у 8 разів вища за властивості-списки інфоблоків. Ми використовуємо HLB компонент і кастомні запити через Bitrix\Highloadblock\DataManager. Це особливо критично для каталогів з 100 000+ товарами.

З нашої практики — проєкт інтернет-магазину з 500 000 товарів. Стандартний фільтр по бренду виконувався 4 секунди. Сервер не витримував навантаження в 50 одночасних запитів — сторінки падали. Ми перевели довідник брендів у HL-блок, додали теговане кешування на 15 хвилин і налаштували агент для скидання кешу при зміні. Після доопрацювання час фільтрації склав 120 мс, середній LCP сторінки — 1,8 секунди. Проєкт працює стабільно без збоїв.

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

Кожен проєкт включає повний комплект документації та артефактів, що виключає втрату знань після передачі.

• Технічне завдання — user stories, діаграми інфоблоків, схеми інтеграцій.
• Вихідний код у Git — з історією комітів, тегами релізів, правилами гілкування.
• Адміністративна документація — опис кастомних компонентів, інструкції з розгортання, перелік агентів і подій.
• Навчання співробітників — до 3 годин вебінару: панель управління, робота з замовленнями, налаштування цін. Записуємо, щоб можна було переглянути.
• Доступ до staging на час розробки — тестуєте самостійно до деплою на продуктив.
• Гарантійна підтримка — виправлення помилок коду протягом 30 днів після запуску. Післягарантійні абонентські пакети з SLA (реакція 2 години, рішення 8 годин).

Наш процес і технології

Стек: верстка mobile-first, тестуємо на фізичних пристроях (iPhone, iPad, Android). Використовуємо BrowserStack для Safari на iOS. Продуктивність — LCP < 2,5 с, FID < 100 мс, CLS < 0,1. Включаємо композитний сайт (composite), CDN, теговане кешування, WebP/AVIF, lazy loading. SEO — Schema.org через JSON-LD, автогенерація sitemap.xml модулем seo, canonical і hreflang для мультимовних версій. robots.txt закриваємо /bitrix/ від індексації. CI/CD — Git, автодеплой через GitLab CI, staging. Міграції бази — модуль sprint.migration з версіонуванням.

Процес роботи:

1. Аналітика — вивчаємо конкурентів, збираємо вимоги, малюємо прототипи в Figma. На виході — ТЗ з user stories.
2. Дизайн — UI/UX з дизайн-системою. Компоненти перевикористовуються.
3. Розробка — пишемо компоненти з кастомними шаблонами в local/templates/. Бізнес-логіку виносимо в модулі local/modules/.
4. Тестування — функціональне, кросбраузерне, навантажувальне (до 1000 запитів). Критичні баги виправляємо до запуску.
5. Запуск — деплой на прод, моніторинг через UptimeRobot, алерти в Telegram. Усуваємо перші 48 годин.

Інтеграції, мультимовність і редизайн

• Повна локалізація через мовні файли lang/ і механізм SITE_ID. hreflang для кожної версії. Регіональні версії з різними цінами та контентом — визначення за IP (main.geo) або ручний вибір. Мультидоменність — єдине управління кількома доменами.

• Редизайн без втрати позицій: аудит продуктивності (PageSpeed, WebPageTest), SEO (Screaming Frog). Новий шаблон у local/templates/ із збереженням URL-структури. 301-редиректи лише якщо URL змінюється суттєво. Оновлення ядра, перехід на D7 ORM, реструктуризація інфоблоків, міграція через sprint.migration з Git.

Гарантія та підтримка

Ми працюємо з 1С-Бітрікс 12+ років, реалізували 500+ проєктів. У штаті сертифіковані розробники. Фіксована вартість у договорі — без сюрпризів. Гарантійний період покриває помилки коду. Після — абонентські пакети з SLA (час реакції — 2 години, рішення — 8 годин). Моніторинг доступності 24/7, алерти в Telegram. За потреби отримайте попередній аудит — зв'яжіться з нами через форму на сайті або напишіть у чат, відповімо протягом години. Замовте розробку під ключ — ми спроєктуємо інфоблоки, інтегруємо 1С і розженимо каталог. Якщо вже є сайт на іншій CMS — замовте аудит продуктивності та міграцію на Бітрікс.