Online school website development using 1C-Bitrix

Online School Website Development on 1C-Bitrix

An online school on Bitrix is not a pure LMS. Moodle or iSpring handle course completion, testing, and learning analytics better. But when the task is to sell courses, manage access after payment, segment audience, and launch marketing campaigns, Bitrix with the sale module proves to be a strong platform. The LMS component is either built as a custom module or connected externally via API.

Let's examine course sales and access control in detail—this is the architectural core of the project.

Course Sales and Content Access Control

The key mechanic: a user pays for a course on the site and gains access to its materials. Sounds simple, but implementation depends on business model. One-time purchase, subscription, course packages, corporate access—each variant requires its own architecture.

Course Catalog

InfoBlock Courses with merchandise catalog (module catalog enabled). Sections are learning directions (programming, design, marketing, languages). Element properties:

Course price is a standard merchandise catalog property (b_catalog_price). For courses with variants (basic / with homework check / with mentorship) use SKU—nested infoBlock elements with different prices and feature sets.

Access Control Mechanism

There are three approaches, each with tradeoffs:

Option 1: User Groups. Upon payment, user is added to group bound to course. Course content (pages, files) is protected by group access rights. This is native Bitrix mechanism, operates at main module level.

Implementation: handler for OnSaleOrderPaid event. When order transitions to "Paid" status, script gets list of products, for each course-product—property value USER_GROUP_ID, and adds user to group via CUser::SetUserGroup().

// Handler pseudocode
$order = \Bitrix\Sale\Order::load($orderId);
foreach ($order->getBasket() as $item) {
    $courseId = $item->getProductId();
    $groupId = getGroupIdByCourse($courseId);
    addUserToGroup($order->getUserId(), $groupId);
}

Problem with this approach—scalability. At 200 courses—200 user groups. Management becomes cumbersome. Plus, temporary access (course for 90 days) requires cron task that daily checks expiry and removes users from groups.

Option 2: Custom access table. Create Highload block CourseAccess:

On payment—record created in CourseAccess. On content display—check active record exists for current user. Cron agent daily updates UF_STATUS for records with expired UF_DATE_TO.

More flexible: easy to implement limited access, freeze, extension, corporate licenses (multiple users per order).

Option 3: Hybrid. User groups for basic segmentation (registered / purchased course / subscriber), Highload block for specific course control. This is optimal for schools with 20+ courses.

Payment Systems

Module sale supports standard payment systems: YooKassa (formerly Yandex.Kassa), Robokassa, CloudPayments, Stripe. Critical for online school:

• Recurring payments—for subscription model. YooKassa and CloudPayments support via card token saving
• Receipts per Law 54-FZ—automatic fiscalization via OFD. In Bitrix configured via payment system handler: parameters PS_IS_CASH and integration with ATOL, OrangeData or payment aggregator cloud cash
• Refunds—automatic refund via payment system API on order cancellation

Promo Codes

Module sale has native coupon and cart rule mechanism. Promo code is a coupon (b_sale_discount_coupon) bound to discount rule (b_sale_discount). Coupon types: one-time, multi-use, per user.

For referral program—custom module. Scheme: user gets unique referral code (stored in UF_REFERRAL_CODE profile property). Invited user specifies code on registration. When invited user buys course—referrer gets bonus (record in Highload block ReferralBonuses): discount on next purchase or internal account credit (sale.account).

Course Catalog: Display and Navigation

Component catalog.section displays courses with filtering:

• By direction (infoBlock section)
• By difficulty level
• By format (video / webinar / text)
• By teacher
• By certificate availability
• By price (range)

Course card contains: name, brief description, teacher (photo + name), duration, lesson count, rating (average from completers), price, "Buy" or "Start Free" button (for courses with free introductory lessons).

Detail page—component catalog.element with custom template: course program (lesson list with "free"/"paid" marks), description, about author, graduate reviews, purchase block.

LMS Functionality

Custom LMS on Bitrix is a custom module. No native tools. Main entities:

Lessons—infoBlock Lessons, bound to course. Properties: ordinal, content type (video/text/test), video URL (Vimeo, Kinescope—for anti-download protection), text content (in detail description), duration, downloadable materials.

Progress—Highload block UserProgress: UF_USER_ID, UF_LESSON_ID, UF_STATUS (not_started / in_progress / completed), UF_COMPLETED_AT, UF_SCORE (for tests). Progress updated via AJAX: on video completion, test passage, "Lesson complete" click.

Tests—Highload block TestQuestions: UF_LESSON_ID, UF_QUESTION_TEXT, UF_ANSWERS (JSON array of options), UF_CORRECT_ANSWER, UF_TYPE (single_choice / multiple_choice / text_input). Results in UserProgress with details in separate HL block TestResults.

Certificates—PDF generation per template on course completion (all lessons completed, tests passed with minimum score). Template using mPDF with name, course title, date, unique number substitution. Number verifiable on site via direct link.

Alternative: Moodle Integration

If LMS functionality is critical and deep learning analytics required, better to integrate Bitrix with Moodle via Moodle Web Services API. Bitrix handles storefront, sales, marketing; Moodle handles learning. On course purchase in Bitrix—API request to Moodle to enroll user (core_enrol_get_enrolled_users, enrol_manual_enrol_users).

Similarly—GetCourse integration via their API for schools already on this platform but needing more flexible storefront.

Webinar Room

Bitrix lacks native webinar module. Integration with external services:

• Zoom—via Zoom API (OAuth 2.0). Create webinar: POST /v2/users/{userId}/webinars. Register participant: POST /v2/webinars/{webinarId}/registrants. Access link issued after payment or on booking
• VK Calls—for Russian schools avoiding foreign services

Webinar schedule—infoBlock Webinars: date/time, topic, teacher, room link (auto-filled on API creation), recording (video link, available after completion).

Segment Email Campaigns

Module sender supports audience segmentation. Segments for online school:

• Bought course X, didn't start (motivational letter)
• Completed 50% of course (continue reminder)
• Completed course (next level offer—upsell)
• Registered, didn't buy (welcome series → free mini-course offer)
• Inactive 30+ days (reactivation)

Segments built via SQL queries to Highload blocks CourseAccess and UserProgress. Each segment is a connector in sender module, implemented as PHP class inheriting \Bitrix\Sender\Connector\Base.

Implementation Timeline

Main time goes to LMS functionality. With Moodle or GetCourse integration instead of from-scratch development—timelines shorten by 4-8 weeks.