Development of an educational institution's website using 1C-Bitrix

Educational Institution Website Development on 1C-Bitrix

A school, college, or university website is one of the few site types where structure is dictated not by marketing but by federal law. Federal Law 273-FZ "On Education in the Russian Federation" and Rosobrnadzor Order #831 establish a mandatory list of sections and documents that must be published on the official website of an educational organization. The absence of any of these is grounds for an inspection notice.

On 1C-Bitrix, such a site is implemented through a system of infoBlocks, Highload blocks for schedules, a web-form module for admissions, and a custom personal account. Let's examine in detail the mandatory sections per 273-FZ and their technical implementation.

Compliance with 273-FZ: Mandatory Sections

Rosobrnadzor Order #831 defines a special section "Information About Educational Organization" with a fixed set of subsections. Each subsection is a page with a specific information list. During inspection, Rosobrnadzor literally goes through a checklist and marks the presence or absence of each item.

Structure of "Information About Educational Organization"

These are 13 mandatory subsections. Each must be accessible within 3 clicks from the home page, have a direct link, and be indexed by search engines.

Technical Implementation

For "Management. Teaching Staff"—infoBlock Teachers with properties:

• FIO—name (string)
• POSITION—position (string)
• DISCIPLINES—teaching subjects (multiple binding to disciplines infoBlock or text)
• DEGREE—academic degree (list: none, candidate, doctor)
• EXPERIENCE_TOTAL—total experience (number)
• EXPERIENCE_SPECIALTY—specialty experience (number)
• QUALIFICATION_DOCS—professional development documents (multiple file)
• PHOTO—photo (file)
• DEPARTMENT_ID—department binding (type E)

Display via component iblock.list with custom template as table. Rosobrnadzor specifically requires table view with name search capability.

For "Documents"—infoBlock OfficialDocuments with category sections (Charter, Licenses, Accreditation, Policies). Each element is a document with PDF file and metadata (approval date, number, approved by). PDF files must be text (not scans) so search engines can index and screen readers can read them.

"Education" subsection is the most extensive. InfoBlock EducationPrograms contains:

• Program name
• Level (primary, general basic, general secondary, secondary vocational, bachelor's, master's)
• Form of study (full-time, distance, part-time)
• Standard duration
• Accreditation expiration date
• Language of instruction
• Curriculum (PDF file)
• Program annotations (multiple file or binding to separate infoBlock)
• Student numbers (by funding source: state, contract)

Student numbers update annually. Convenient to store in Highload block StudentCount with fields UF_PROGRAM_ID, UF_YEAR, UF_BUDGET_COUNT, UF_CONTRACT_COUNT, UF_FOREIGN_COUNT.

Monitoring Relevance

Rosobrnadzor checks not just information presence but also relevance. Documents with expired validity, outdated student data—all violations.

To control, create a Bitrix agent (\CAgent) checking daily:

• Documents with expiring validity (license, accreditation)—notification 60 and 30 days before
• Sections not updated for 6+ months—update reminder
• Presence of all mandatory subsections—automatic checklist

Schedule of Classes

Schedule is the second most visited section after home. Students and parents visit daily.

Storage—Highload block Schedule:

Highload block chosen over regular infoBlock for performance: a large school's schedule is 500-2000 entries accessed simultaneously by dozens of users. ORM queries to Highload block operate significantly faster than CIBlockElement::GetList().

Display component is custom, with filtering by class and day navigation. AJAX loading when filter changes. For parents—ability to subscribe to class schedule changes (email notification on Highload block edits).

Schedule import from Excel file via custom admin page. Administrators upload file, system parses it (PhpSpreadsheet library) and updates Highload block records.

Personal Account

Personal account varies by role:

• Student—their class schedule, grades, homework, announcements
• Parent—same data, binding to child (property UF_PARENT_OF in user profile, link to student ID)
• Teacher—their schedule, grade entry, homework publishing

Grades stored in Highload block Grades: UF_STUDENT_ID, UF_SUBJECT_ID, UF_DATE, UF_GRADE, UF_TYPE (current/test/quarterly/final).

Homework—Highload block Homework: UF_CLASS_ID, UF_SUBJECT_ID, UF_TEACHER_ID, UF_DATE_ASSIGNED, UF_DATE_DUE, UF_DESCRIPTION, UF_FILES.

Access control via Bitrix user groups and component rights checking. Groups: "Students," "Parents," "Teachers," "Administration." Student-to-class binding via profile property UF_CLASS_ID.

Admissions Campaign

Online application for admission—web form from module form or custom React component (via Inertia.js or standalone). Fields: applicant name, birth date, program/class selection, parent contacts, document upload (birth certificate, documents).

Application saved in Bitrix CRM as lead. Pipeline: "New application" → "Documents under review" → "Admitted" / "Rejected". Parent notifications on status change via main module email templates.

Accessibility (WCAG 2.1)

An educational organization website must be accessible to people with disabilities. Minimum requirements:

• Version for visually impaired—font size switcher, high contrast theme. Implemented via CSS variables and JS switcher saving choice in localStorage
• Alt text for all images
• Keyboard navigation—correct tabindex, visible focus
• Text contrast—minimum 4.5:1 per WCAG AA
• Video captions (if video content exists)

In Bitrix, the visually impaired version typically uses a separate site template or CSS modifier on same template. Second option is simpler to maintain.

Implementation Timeline