Driving School Website on 1C-Bitrix: Enrollment & Test Automation

A driving school with three branches and 500 students per month generates a stream of calls: "Are there spots available?", "What's the schedule?", "When is the test?" Without automation, an administrator spends up to three hours a day just answering calls, and scheduling errors lead to lost clients. For example, with 15 branches and 40 courses, manually updating the schedule takes 2 hours daily — cascading online enrollment via Highload-blocks reduces this to zero. Integration with 1C via CommerceML automatically syncs contracts and invoices, eliminating double entries. We build websites on 1C-Bitrix that automate enrollment, testing, and document management — they pay for themselves in 2-3 months by reducing manual labor and increasing enrollment conversion by 25%. This is a comprehensive turnkey driving school website development: from designing information blocks to custom testing components. Our solutions are proven in dozens of driving schools and scale to any branch.

How is the course catalog organized with information blocks?

The catalog's foundation is the information block "Courses" with the type "Training". Each element corresponds to one training program. Element properties:

• Category (list): A, A1, B, B1, C, CE, D, DE — according to driver's license classification.
• Duration (number): total number of days in the program.
• Theory hours (number): academic hours of theoretical classes.
• Practice hours (number): driving hours with an instructor.
• Format (list): in-person, distance, blended.
• Branches (binding to elements): link to the "Branches" information block.

Information block sections mirror the categories — this provides SEO pages like /courses/category-b/ with automatic filtering. Each section has its own SEO template via section properties: title, description, og:image.

The bitrix:catalog.section.list component displays the category tree on the main page, and bitrix:news.list shows course cards within a section. Filtering by format is implemented via bitrix:catalog.smart.filter with AJAX reload without full page refresh.

Why Use Highload-blocks for Online Enrollment?

Student enrollment is not just a web form. We need to show available groups, start dates, number of free seats, and linking to a specific branch. The Highload-block "Groups" contains fields:

We chose a Highload-block over a regular information block for performance: with 15+ branches and dozens of groups simultaneously, selection via ORM D7 works much faster.

The enrollment form works cascading: student selects category → branch → sees only groups with status "Open" and UF_CURRENT_COUNT < UF_MAX_STUDENTS. After submitting a request, the handler on the OnAfterHLBlockElementAdd event increments the counter and, if the group is full, automatically changes the status.

Class Schedule

The schedule is implemented with two information blocks: "Theory Schedule" and "Driving Schedule". Theory is linked to the group: fixed days and time, same for all students in the group. It is displayed as a table in the personal account and on the group page.

Driving is individual. The information block "Driving Slots" contains a binding to the instructor, date, start and end time, status (free / booked / completed). The student sees available slots for their instructor in the personal account and books them via an AJAX request to a custom controller.

Student Personal Account

The personal account is built on the bitrix:main.profile component with a custom template and additional tabs:

• My Course — information about the group, instructor, dates.
• Schedule — theory (common table) + driving (personal slots).
• Progress — number of completed theory sessions, driving hours, internal test results.
• Grades — results of mock exams.
• Documents — contract, payment receipts (files from user properties).

Authentication uses the standard main module with SMS confirmation via sms.ru or an SMSC gateway.

Progress and grades data are aggregated from Highload-blocks of test results via D7 API. Tabs are implemented with JavaScript routing and AJAX content loading.

How is the Traffic Law Test Protected?

Traffic law testing is a key function that brings students back to the site daily. Standard Bitrix modules (surveys, web forms) are unsuitable: no timer, no randomization, no breakdown by topic with statistics.

Question Storage Architecture

Information block "Traffic Law Questions" with sections by topic: "Intersection Crossing", "Road Signs", "Traffic Light Signals", "First Aid", etc. (40 topics per the traffic police exam structure).

Element properties:

• Question text — detailed element description (with image support via visual editor).
• Image — picture of a road situation (file type property).
• Option 1–5 — string properties for answers.
• Correct answer — number (option number).
• Explanation — text property with breakdown of the correct answer and a reference to the traffic law clause.
• Difficulty — list (easy / medium / hard).
• Ticket — number (official exam ticket number, 1-40).
• Number in ticket — number (question position, 1-20).

Custom Testing Component

The atlas:pdd.test component operates in three modes:

1. Exam Mode — 20 questions from different topics, 20 minutes for the entire ticket. The component selects questions via CIBlockElement::GetList with a filter by ticket number or generates a random set using RAND() in SORT. The timer is client-side (JavaScript countdown), but the control time is stored server-side in the session — on page reload, the timer continues from the same point.

2. By Topic Mode — the student selects a topic and receives all questions from that section in random order. No time limit. After each answer, an explanation is shown.

3. Marathon Mode — all 800 questions in a row. Progress is saved in a Highload-block so the student can continue from any device after authentication.

Saving and Statistics

Results of each attempt are recorded in the Highload-block "Test Results":

Based on this data, analytics are built in the personal account: percentage of correct answers by topic, dynamics over the last week, weak topics (where percentage is below 80%). Chart.js is used for visualization, data is fetched via an AJAX request to the D7 controller.

Answer Mechanics

The frontend sends an AJAX request with the question ID and the selected option number. The controller checks the answer server-side (the correct option number is never sent to the client before the answer) and returns the result: correct/incorrect, explanation text, reference to traffic law clause. This prevents peeking via DevTools — answers are verified only server-side.

To protect against stat padding, a debounce check is implemented: if less than 2 seconds pass between answers, the result is not counted (bot or autoclicker). We guarantee that the testing system has passed load testing with 500 concurrent users and maintains data correctness.

Graduate Reviews

Information block "Reviews" with mandatory pre-moderation (WF_STATUS_ID). Properties: name, photo, category (which one they passed), text, rating (1-5), graduation date. On the course page, only reviews linked to the corresponding category are displayed via bitrix:news.list with a filter by property.

Additionally, a review collection widget is implemented: 7 days after course completion, the student receives an email with a link to a form. Sending is done via bitrix:iblock.element.add.form with a custom template.

Work Stages

Total timeline — 8–11 weeks, provided the traffic law question database is supplied by the client in a structured format (Excel/CSV). If manual entry of 800 questions with images is required, allocate an additional 2–3 weeks for content.

Request a consultation — clarify details for your project.

What's Included in Development

The result includes:

• Full structure of information blocks and Highload-blocks with migrations.
• Custom components (testing, enrollment, schedule).
• Design mockups and responsive layout.
• Integration with payment systems (YooKassa, Sber) and fiscalization.
• Training for administrators and a user manual.
• Support for 30 days after launch.

Savings on administrative work significantly reduce operational expenses. Automation reduces advertising costs thanks to built-in SEO pages for courses.

Get a consultation and estimate the savings for your business. We have proven experience: certified 1C-Bitrix specialists with 10+ years in production.

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.