Sports Club Website on 1C-Bitrix: Schedule to Ticket System

Sports Club Website: From Schedule to Merch on 1C-Bitrix

Imagine: a fan wants to buy a match ticket, select a specific seat on the stadium map, and also order a jersey with a player's name — all on one site. And it all must work smoothly under peak loads. We build such sites on 1C-Bitrix, where training schedules, tournament tables, a seat-selection ticket system, and a merch store coexist. Each block requires separate data architecture, and together — proper caching and tagging. Our experience shows that standard components only work with custom configuration of infoblocks and Highload blocks. Project cost is calculated individually — contact us for an estimate.

How to Design Data Structure for a Sports Club?

For a sports club, a hierarchy of several linked infoblocks is built:

• Teams — main infoblock linked to sport type, league, season. Properties: roster (link to "Athletes" infoblock), coaching staff, logo, uniform colors.
• Athletes — infoblock with detailed profiles: full name, position, number, anthropometry, uniform photo, season statistics (goals/points/assists stored in a separate Highload block for fast retrieval).
• Matches and Training Sessions — Highload block (b_hlblock_schedule), because over several seasons there are thousands of records. Fields: date/time, type (training/match/friendly), home team, away team, stadium, status (scheduled/in progress/completed/postponed), score.
• Tournaments — infoblock linked to season. The tournament table is generated by a custom component based on match results from the Highload block.

Links between infoblocks are implemented via a property of type "Link to elements" (E) or via Highload directories if performance is needed on selections.

Why Use Highload Blocks for Scheduling?

The training and match schedule is the "hottest" section of the site. Fans check upcoming games, coaches view training sessions, admins update results in real time.

Highload block is chosen for a reason: with 300+ matches per season and 5-6 teams in a club, a regular infoblock starts to lag on complex filters. A Highload block stores data in a separate MySQL table, queries go directly without the overhead of the infoblock API. Comparison: Highload blocks process queries 5 times faster than infoblocks on selections of 10,000 records.

Frontend filtering: by team, by event type, by month. The component renders a calendar grid with color indicators — gray for training, green for home matches, blue for away. For SEO, each match gets its own detail page with a human-readable URL like /matches/2024-25/spartak-vs-dinamo-12-10/.

Cache is tagged, tied to the schedule_updated tag. When any Highload block element is updated via the HighloadBlockOnAfterUpdate event handler, only this tag is cleared, not the entire site cache.

How the Ticket System with Seat Selection Works

This is the key and most technically complex part of the project. The standard sale module in Bitrix is designed for items in the cart — add, checkout, pay. A ticket for a specific seat in a specific sector is a completely different mechanism.

Architecture solution: Each stadium (hall, arena) is described by an SVG file, where each seat is a separate <rect> or <circle> element with attributes data-sector, data-row, data-seat. The SVG is loaded into the browser, a JavaScript handler takes care of interactivity: highlight on hover, seat selection on click, display of occupied seats in gray.

Storage of seats and states: A Highload block hl_stadium_seats is created with fields:

For each match, a booking table is created — another Highload block hl_ticket_bookings:

Purchase process step by step:

1. User opens the match page, the SVG scheme loads.
2. AJAX request to REST controller gets the array of occupied seats for this match. JavaScript colors them gray and removes the click handler.
3. User clicks on a free seat — it is marked as reserved in hl_ticket_bookings with a timestamp. The reservation lives for 15 minutes, then a cron agent (CTicketReserveAgent) clears expired ones.
4. Selected seats are added to the cart of the sale module as product items. For this, each price zone is represented by a trade offer in the catalog. The cart property SEAT_INFO stores serialized data about the specific seat.
5. Checkout is standard — sale.order.ajax with a customized template. On successful payment, the status changes to sold, a PDF ticket with QR code is generated via the TCPDF library.
6. The QR contains a signed token (HMAC-SHA256), which is verified at the entrance by a scanner.

Concurrent access is critical. Two fans must not book the same seat. Solution: UPDATE ... WHERE UF_STATUS = 'free' with affected rows check. If 0 returned — seat already taken, frontend shows notification and redraws SVG.

Why Connect Tournament Tables via Custom Component?

The custom component custom:tournament.table aggregates data from the Highload block of matches: calculates points (3 for win, 1 for draw), goal difference, sorts. The result is cached with the tag tournament_{ID}, cleared when the score of any match in that tournament is updated.

For team sports with playoffs, the component can render a playoff bracket via SVG — pairs, winners, connection lines between rounds.

Athlete Profiles

The athlete detail page includes: photo, biography, career achievements (timeline via infoblock property "multiple" — club, years, achievements), current season statistics from the Highload block, photo/video gallery linked via CIBlockElement::GetProperty.

For SEO — micro-markup schema.org/Person with athlete in jobTitle field, linked to schema.org/SportsTeam.

Fan Zone and Merch Store

The news section is implemented with the standard news.list / news.detail component with a customized template. Photo and video gallery — infoblock linked to matches and athletes.

The merch store is a full-fledged online store on the catalog + sale module: jerseys, scarves, merchandise. Trade offers by size and color, integration with 1C for inventory management. It runs parallel to the ticket system but in a separate infoblock type so that the product catalog does not intersect with tickets.

Integration with Ticket Operators

If the club sells tickets not only through its website but also through Ticketland, Kassir.ru, or similar systems, synchronization is needed. This is implemented via the ticket operator's REST API: when a booking/sale occurs on the operator's side, a webhook updates the status in hl_ticket_bookings. And vice versa — a sale on the website sends data to the operator.

A cron synchronization agent runs every 2 minutes to fetch changes that may have failed to arrive via the webhook (network failures, timeouts).

Development Stages

What's Included

• Full documentation on infoblock structure, HL blocks, caching settings.
• Source code of all custom components and agents in the repository.
• Editor training: how to add matches, update statistics, upload SVG schemes.
• Warranty support for 1 month after launch — bug fixes, consultations.

We guarantee correct system operation under peak loads of up to 10,000 concurrent visitors. Contact us for a project estimate — we will prepare a commercial proposal. Get a consultation on your sports website architecture.

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.