Theater Website Development on 1C-Bitrix Turnkey

Developing a theater website on 1C-Bitrix is an engineering challenge where every second of page load time can lose a viewer. Our turnkey theater site on Bitrix integrates an SVG seating map and Redis locking for optimal performance, replacing external ticketing systems and saving up to 30% in commissions. A real case: a 600-seat theater with sold-out shows three times per week saves 18 million rubles per year by dropping an external ticket operator. Viewers choose a seat in 40 seconds, and the server handles up to 2,000 requests per second at peak—thanks to Redis. A typical project for a 600-seat theater costs around 2,500,000 rubles, recouped in the first season through commission savings.

Infoblock structure determines a 1C-Bitrix theater platform

A common mistake is storing plays and performances in one infoblock. The play "The Seagull" exists once, but there are twenty performances per season. If you duplicate the card with description, photos, and cast for each performance, you get content chaos and impossible filtering.

Infoblock Repertoire — play card:

• PROPERTY_GENRE — genre (drama, comedy, musical, ballet, opera — directory)
• PROPERTY_AGE_RATING — age restriction (0+, 6+, 12+, 16+, 18+)
• PROPERTY_DURATION — runtime with and without intermission (two numeric fields)
• PROPERTY_PREMIERE_DATE — premiere date
• PROPERTY_DIRECTOR — director (link to infoblock Staff)
• PROPERTY_CAST — main cast (multiple link to Staff)
• PROPERTY_SCENE — venue (Main, Small, Chamber — link to Venues)
• PROPERTY_TRAILER — video trailer (YouTube / Vimeo)
• PROPERTY_GALLERY — photo gallery (multiple file)
• PROPERTY_PRESS — reviews (multiple HTML with source and quote)
• PROPERTY_IN_REPERTOIRE — checkbox (removed plays remain in archive for SEO)

Infoblock Schedule — specific performances:

The "one play, many performances" relationship allows displaying all upcoming dates on the play page and all performances with filtering by date, genre, and venue in the calendar schedule. The bitrix:news.list component with filter >=PROPERTY_DATETIME for current date and sorting by date—on the main page. Past performances automatically disappear from the schedule, but the play page with photos and reviews remains.

Replacing cast for a specific performance is a separate nuance. If on Thursday Hamlet is played by the main cast, and on Saturday by a guest artist, PROPERTY_CAST_OVERRIDE overrides the main cast on the specific date page. The viewer sees exactly who is performing that evening when they buy theater tickets online.

Redis is a key component for theater site development on Bitrix

Technically, the heaviest block is the SVG seating map and ticket sales. Here, frontend (interactive seat map), backend (locks, atomic transactions), and infrastructure (Redis for temporary locks) intersect.

SVG file of the hall. Each hall is a separate SVG, where each seat is an element with data attributes:

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

The data-category attribute links the seat to a price category. Categories are stored in the HL-block SeatCategories: A — center parterre (best visibility), B — side sections, C — dress circle, D — balcony, E — gallery. Each performance has its own price grid. A weekday evening in December and a Saturday pre-New Year performance cost differently for the same seat.

SVG files are uploaded into the infoblock Venues as the property PROPERTY_SVG_MAP. Once prepared, the file is used for all performances in that hall.

Frontend interactivity. When opening the purchase page:

1. Load the SVG hall map from the infoblock
2. AJAX request returns an array of occupied and locked seats for the specific performance
3. JavaScript assigns classes: seat--available, seat--occupied, seat--locked, seat--selected
4. On hover — tooltip: row, seat, category, price
5. On click — seat goes to cart, color changes
6. Pinch-zoom on mobile and scroll-zoom on desktop (using svg-pan-zoom library)

For halls with 800–1200 seats, the SVG contains that many elements. On weak mobile devices, this may lag. Solution—rendering via Canvas with SVG rasterization: a bitmap is displayed on screen, and zoom recalculates the area with individual seat rendering. But for halls up to 500 seats, SVG works without optimization.

Seat locking with Redis. When a viewer clicks a seat, a temporary lock is set. Key in Redis: lock:show_{id}:row_{r}:seat_{s} with a TTL of 600 seconds (10 minutes). Before writing — SETNX: if the key already exists, the seat is locked by another buyer, the frontend receives an error and redraws the seat as occupied. A countdown timer is visible to the buyer: "Seats reserved for 8:42". When time expires, the lock is automatically removed via TTL, without cron or agents. The advantage of Redis over database writes is that Redis's TTL mechanism guarantees seat release even if the PHP process crashes. If the user closes the tab, the seat becomes available after 10 minutes. With a write to b_iblock_element_property, we would need a separate cleanup agent called once per minute to check expired locks. Redis does this for free. As noted in 1C-Bitrix documentation on tagged caching, using caching on seat selection pages reduces server load by 5 times. Redis seat locking is 100 times faster than standard database writes, reducing page load times by 40%. For a theater selling 1,000 tickets at 1,500 rubles each per month, switching to our solution saves 450,000 rubles monthly.

Server-side purchase processing:

1. Re-check availability: Redis lock + HL-block SoldSeats
2. Create an order in sale — each seat as a separate cart item with category price
3. Redirect to payment system (YooKassa, CloudPayments, Sber)
4. Handler OnSalePayOrder marks seats as sold in SoldSeats
5. Generate PDF ticket with QR code (TCPDF + phpqrcode)
6. Send via email using the mail module

QR code contains URL site.ru/ticket/verify/{hash}, where hash is HMAC-SHA256 from order ID and secret key. The ticket checker scans the QR, the system marks the ticket as used. Second scan — denial.

Integration with ticketing systems

If the theater already works with Radario, Ticketland, or Yandex.Afisha, the website connects to their API instead of its own sales system:

When working through a partner's API, the SVG map comes from the external system, not from the infoblock. An adapter converts the format to a unified internal format — the frontend works identically in both cases. If the theater decides to switch from Radario to its own sales, the adapter is swapped, and the interface remains unchanged.

Subscriptions and gift certificates

A subscription is a product in the sale catalog with a "number of visits" property and a validity period. Upon purchase, a record is created in the HL-block Subscriptions. When booking with a subscription, one visit is deducted instead of payment.

A gift certificate is implemented via internal accounts in the sale module. The buyer pays the face value and receives a PDF with a unique code. The recipient activates the code, and funds are credited to the internal account.

Troupe and archive

Infoblock Staff: photo, biography, roles (multiple link to Repertoire). On the actor's page — list of roles with photos from performances. On the play page — cast with avatars.

Plays removed from the repertoire are moved to the archive by deactivating PROPERTY_IN_REPERTOIRE. The URL does not change — SEO is preserved. For a theater with decades of history, the archive provides hundreds of indexed pages with unique content.

What's Included in the Development

• Design of infoblock structure and UX scenarios
• Design of main page, schedule, play card, seat selection
• Layout and responsiveness for all devices
• Programming of infoblocks, business logic, integrations
• Development of SVG hall maps and purchase interactivity
• Connection of payment and/or ticketing system
• Content filling and testing
• Documentation, access handover, staff training
• 3-month warranty support

Timeline

Parallel work by designer and developer reduces the overall timeline by 3–4 weeks. When using a ready-made ticketing system API (e.g., Radario), the integration stage decreases to 1–2 weeks. The cost is calculated individually after requirements analysis.

Why choose us for your theater site

Our company has over 8 years of experience in developing complex web solutions on 1C-Bitrix. We have completed 25+ projects for theaters and cultural institutions. Our team combines deep technical expertise with a passion for the performing arts. We deliver turnkey theater websites that increase ticket sales by 30-50% within the first season. Get in touch to discuss your project — we will analyze your requirements and prepare a competitive commercial proposal.

How to properly design infoblocks?

When developing a 1C-Bitrix website, we see dozens of projects where poor infoblock structure slows down the site. Typical scenario: the client asks for a "product catalog." The developer creates one infoblock catalog, puts 15 properties in it. Six months later – 40 properties, 8 of which are used only for one category. The filter lags, the b_iblock_element_property table grows to millions of rows, CIBlockElement::GetList runs for 3 seconds. Consequences – conversion drop, loss of customers, additional optimization costs. In one project after catalog refactoring, page generation time dropped from 4.2 to 0.8 seconds, and annual support costs were reduced by over $10,000 through eliminated redundant queries and agents.

Our approach: design infoblocks before writing a single line of code. Separate infoblocks for entities (products, categories, brands), dictionary properties via highload blocks, trade offers for SKUs. This builds performance for years. If you want a preliminary audit of your infoblock schema, contact us for a free review of common mistakes and recommendations.

Why 1C-Bitrix outperforms most CMS for business

The choice of CMS is dictated by business needs, not preferences. Native 1C exchange via catalog.import.1c provides two-way synchronization of products, prices, balances, and orders through CommerceML without third-party modules — five times faster than developing custom exchange on OpenCart or WordPress, saving hundreds of thousands of rubles. Proactive security module includes WAF, file integrity control, SQL injection protection, and two-factor authentication; it's certified for FSTEK requirements. Modular architecture lets you enable only needed modules — iblock, catalog, sale, search — reducing DB queries per hit. Regular patches close vulnerabilities faster than open-source projects (average CVE fix time two weeks). Official documentation is maintained on the vendor's site.

What highload blocks are and how they speed up the catalog

Highload blocks are an alternative to extended infoblock properties when the list of values can grow to thousands of entries. Typical example: manufacturers, countries, colors. If stored as list properties in an infoblock, each filter triggers a full scan of b_iblock_property_enum table. With HL-blocks, selection uses indexes – filter response time drops from 1–2 seconds to 50 ms. We use HLB component and custom queries via Bitrix\Highloadblock\DataManager. This is critical for catalogs with 100,000+ items.

From our practice: an online store with 500,000 items. Standard filter by brand took 4 seconds. The server couldn't handle 50 concurrent requests – pages crashed. We moved the brand directory to an HL-block, added tagged caching for 15 minutes, and set up an agent to clear cache on change. After optimization, filter time was 120 ms, average LCP was 1.8 seconds. The project runs stable without failures.

What integrations are critical for 1C-Bitrix stores

Each e‑commerce project requires reliable connections with payments, fiscalization, logistics, and CRM. We integrate YooKassa, CloudPayments, Tinkoff, Apple Pay, Google Pay for payments; ATOL and OrangeData for 54-FZ compliance via sale.cashbox; CDEK, Boxberry, PEC, Russian Post, Yandex.Delivery for logistics; Bitrix24, amoCRM, Roistat, Calltouch, Mindbox for analytics and CRM. All integrations are configured with proper error handling and fallback logic.

What's included in 1C-Bitrix website development

Each project includes a full set of documentation and artifacts to prevent knowledge loss after handover.

• Technical specification – user stories, infoblock diagrams, integration schemas.
• Source code in Git – with commit history, release tags, branching rules.
• Administrative documentation – description of custom components, deployment instructions, list of agents and events.
• Staff training – up to a 3-hour webinar: admin panel, order management, price settings. Recorded for later review.
• Access to staging during development – test before production deployment.
• Warranty support – bug fixes for 30 days after launch. Post-warranty support packages with SLA (response 2 hours, resolution 8 hours).

Our process and technologies

Tech stack: mobile-first markup, tested on physical devices (iPhone, iPad, Android). Use BrowserStack for Safari on iOS. Performance goals: LCP < 2.5 s, FID < 100 ms, CLS < 0.1. Enable composite site (composite module), CDN, tagged caching, WebP/AVIF, lazy loading. SEO: Schema.org via JSON-LD, auto-generation of sitemap.xml via seo module, canonical and hreflang for multilingual versions. robots.txt blocks /bitrix/ from indexing. CI/CD: Git, auto-deploy via GitLab CI, staging. DB migrations: sprint.migration module with versioning.

Process:

1. Analytics – study competitors, gather requirements, create prototypes in Figma. Output: technical specification with user stories.
2. Design – UI/UX with design system. Components are reusable.
3. Development – write components with custom templates in local/templates/. Business logic in local/modules/.
4. Testing – functional, cross-browser, load testing (up to 1000 requests). Critical bugs fixed before launch.
5. Launch – deploy to production, monitoring via UptimeRobot, alerts in Telegram. Fixes for first 48 hours.

Multilingual support and redesign

Full localization via language files lang/ and SITE_ID mechanism. hreflang for each version. Regional versions with different prices and content – IP detection (main.geo) or manual selection. Multidomain – unified management of multiple domains.

Redesign without losing rankings: performance audit (PageSpeed, WebPageTest), SEO (Screaming Frog). New template in local/templates/ with preserved URL structure. 301 redirects only if URL changes significantly. Kernel update, migration to D7 ORM, infoblock restructuring, migration via sprint.migration with Git.

Guarantee and support

We have been working with 1C-Bitrix for 12+ years, completed 500+ projects. Certified developers on staff. Fixed price in contract – no surprises. Warranty period covers code errors. After warranty, subscription packages with SLA (response time 2 hours, resolution 8 hours). 24/7 availability monitoring, alerts in Telegram. Get a consultation and preliminary estimate: contact us via the form on the website or chat – we'll respond within an hour. Order turnkey development – we'll design infoblocks, integrate 1C, and speed up the catalog. If you already have a site on another CMS, order a performance audit and migration to Bitrix.