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

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Услуги, которые мы предлагаем
Показано 1 из 1Все 1626 услуг
Разработка сайта театра на 1С-Битрикс под ключ
Сложный
от 1 недели до 3 месяцев
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    947
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Разработка на базе Битрикс, Битрикс24, 1С для компании Development of an Online Appointment Booking Widget for a Medical Center
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    830
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    732
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    1075

Разработка сайта театра на 1С-Битрикс — инженерная задача, где каждая секунда загрузки страницы стоит зрителя. Средний театр теряет до 2 000 000 рублей в год на комиссиях билетных операторов (10–30% с каждого билета). Мы строим систему, которая окупается за первый сезон: репертуарная сетка, SVG-схема зала и онлайн-продажа билетов без посредников. Реальный кейс: театр на 600 мест с аншлагом 3 раза в неделю экономит 18 млн рублей в год, отказавшись от внешнего билетного оператора. Зритель выбирает место за 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 — конкретные показы:

Поле Тип Описание
PROPERTY_SHOW_ID Привязка Спектакль из Repertoire
PROPERTY_VENUE_ID Привязка Зал из Venues
PROPERTY_DATETIME Дата/время Начало показа
PROPERTY_STATUS Список В продаже / Мало мест / Продано / Отменён
PROPERTY_CAST_OVERRIDE Множ. привязка Состав на конкретную дату (если отличается от основного)
PROPERTY_PRICE_SCHEME Привязка Ценовая схема из HL-блока PriceSchemes

Связка «один спектакль — много показов» даёт возможность на странице спектакля вывести все ближайшие даты, а в календарной афише — все показы с фильтрацией по дате, жанру и площадке. Компонент 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 работает без оптимизаций.

Оптимизация SVG для больших заловИспользуем Lazy Load для отображения только видимой области, разбиваем 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 вместо собственной системы продаж:

Система Интеграция Что получаем
Радарио REST API v2 Залы, схемы мест, события, наличие, создание заказа
Ticketland SOAP / REST Каталог, бронирование, статус оплаты
Яндекс.Афиша Widget API Виджет продажи с встраиванием на страницу
СБИС REST API Учёт билетов, фискализация через ОФД

При работе через API партнёра SVG-схема подтягивается из внешней системы, а не из инфоблока. Адаптер конвертирует формат в единый внутренний — фронтенд работает одинаково в обоих случаях. Если театр решит уйти от Радарио на собственную продажу — переключается адаптер, интерфейс остаётся прежним.

Абонементы и подарочные сертификаты

Абонемент — товар в каталоге sale со свойством «количество посещений» и сроком действия. При покупке создаётся запись в HL-блоке Subscriptions. При бронировании по абонементу списывается одно посещение вместо оплаты.

Подарочный сертификат реализуется через внутренние счета модуля sale. Покупатель оплачивает номинал, получает PDF с уникальным кодом. Получатель активирует код — средства зачисляются на внутренний счёт.

Труппа и архив

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

Спектакли, снятые с репертуара, переносятся в архив деактивацией PROPERTY_IN_REPERTOIRE. URL не меняется — SEO сохраняется. Для театра с историей в десятки лет архив даёт сотни проиндексированных страниц с уникальным контентом.

Что входит в работу

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

Сроки

Этап Длительность
Проектирование структуры и UX 2–3 недели
Дизайн (главная, афиша, карточка спектакля, выбор мест) 3–4 недели
Вёрстка и адаптивность 2–3 недели
Программирование инфоблоков и бизнес-логики 3–4 недели
SVG-схемы залов и интерактив покупки 2–3 недели
Интеграция с платёжной / билетной системой 2–3 недели
Контент и тестирование 2 недели
Итого 16–22 недели

Параллельная работа дизайнера и разработчика сокращает общий срок на 3–4 недели. При использовании готового API билетной системы (Радарио) этап интеграции уменьшается до 1–2 недель. Стоимость рассчитывается индивидуально после анализа требований.

Получите консультацию по разработке сайта театра — мы проанализируем ваши требования и подготовим коммерческое предложение. Свяжитесь с нами, чтобы обсудить проект.

Как правильно проектировать инфоблоки?

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

Наш подход: проектируем инфоблоки до первой строки кода. Отдельные инфоблоки под сущности (товары, категории, бренды), свойства-справочники через highload-блоки, торговые предложения для SKU. Это закладывает производительность на годы вперёд. Если хотите получить предварительный аудит вашей схемы инфоблоков — свяжитесь с нами, разберём типовые ошибки и дадим рекомендации бесплатно.

Почему 1С-Битрикс выгоднее альтернатив?

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

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

Что дают HL-блоки и как мы ускоряем каталог

Highload-блоки — это альтернатива расширенным свойствам инфоблоков, когда список значений может расти до тысяч записей. Типичный пример: производители, страны, цвета. Если хранить их как свойства-списки в инфоблоке, каждая фильтрация вызывает полное сканирование таблицы b_iblock_property_enum. С HL-блоками выборка идёт по индексу — время ответа фильтра снижается с 1–2 секунд до 50 мс. Мы используем 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 часов).

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

Тип проекта Сроки Сложность Ключевые особенности
Корпоративный сайт от 1 месяца Средняя Каталог, новости, формы, CRM-интеграция
Интернет-магазин от 2 месяцев Высокая 54-ФЗ, маркетплейсы, обмен с 1С, SKU
B2B-портал от 3 месяцев Очень высокая Персональные цены, документооборот, Bizproc
Лендинг от 2 недель Низкая LCP < 2с, композитный кеш, статика
Многосайтовая структура от 1,5 месяцев Высокая Раздельный контент, общий каталог, hreflang

Стек: вёрстка 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 часов.

Интеграции, мультиязычность и редизайн

Направление Сервисы
CRM и аналитика Битрикс24 (нативная), amoCRM, Roistat, Calltouch, Mindbox
Платежи ЮKassa, CloudPayments, Тинькофф, Apple Pay, Google Pay
Фискализация 54-ФЗ АТОЛ, OrangeData — настройка через sale.cashbox
Логистика СДЭК, Boxberry, ПЭК, Почта России, Яндекс.Доставка
Коммуникации JivoSite, Carrot Quest, SendPulse
  • Полная локализация через языковые файлы 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 — закажите аудит производительности и миграцию на Битрикс.