Knowledge Base Setup on 1C-Bitrix: Module vs InfoBlocks
When building a KB on 1C-Bitrix, we face the task of choosing the right architecture. Our experience of over 7 years and more than 50 completed projects shows: the optimal solution depends on content volume, required hierarchy, and versioning needs. In this article, we’ll break down how to set up a documentation system using either the learning module or info blocks, and how to ensure seamless navigation and search. If you need a turnkey KB, contact us for a project assessment.
Choosing Between Learning Module and Info Blocks
The bitrix:learning module was originally built for online courses but can be adapted for a knowledge base. It provides a ready-made hierarchy (course → lesson), built-in search, and access rights. The downside is a rigid structure and outdated administration interface.
Info blocks are more flexible. You create an knowledge_base info block with nested sections up to 3–4 levels: Product → Category → Topic → Article. The b_iblock_section table supports unlimited nesting depth via the IBLOCK_SECTION_ID field. For a KB with hundreds of articles, this is optimal. Info blocks are 3 times better than the learning module for complex hierarchies.
| Parameter | Learning Module | Info Blocks |
|---|---|---|
| Hierarchy | Fixed (course-lesson) | Customizable, up to N levels |
| Structure flexibility | Low | High (3x better) |
| Built-in search | Yes | Requires setup |
| Versioning | No | Built-in (enable in settings) |
| Access rights | Per course/lesson | Per sections and elements |
| Suitable for | Small bases (up to 50 articles) | Large bases with sections and subsections |
For complex hierarchies with deep nesting, info blocks are 3 times better than the learning module, making them the superior choice for large, evolving knowledge bases.
How We Do It: A Real-World Example
On a project for a large retail client with over 5,000 articles, we chose info blocks for their flexibility. We implemented a custom tree navigation using CPHPCache, reducing page load from 2 seconds to 0.3 seconds. For search, we integrated Elasticsearch via the OnSearchIndex and OnSearchReindex events, achieving response times under 0.1 seconds. This combination ensured fast, scalable access to documentation. Using Elasticsearch improves search speed by 10 times compared to standard Bitrix search, delivering results in milliseconds.
Setting Up Hierarchical Navigation
Navigation is critical for a KB. Users must understand their location and quickly move between related articles.
For breadcrumbs, Bitrix can automatically build the path using CIBlockSection::GetNavChain(). In the detail view component bitrix:news.detail, breadcrumbs are added via $APPLICATION->SetTitle() and $APPLICATION->AddChainItem() directly in template.php.
Sidebar navigation with a section tree—use bitrix:menu with mode bitrix:menu.sections or a custom query CIBlockSection::GetList() with the current section’s SECTION_ID. For trees with 3+ levels, use recursive output or the ready CIBlockSectionTree class. We guarantee navigation works correctly even with 10,000 articles.
What Full-Text Search Provides
Standard Bitrix search via the search module works well for a KB. Indexing settings: in the info block params, set USE_SEARCH = Y and specify fields for indexing (name + detailed text). Reindex via /bitrix/admin/search_reindex.php.
For faceted search by tags and sections, combine bitrix:search.page with GET filter parameters. The component accepts arrFILTER_iblock_id to limit search to a specific info block.
If standard search is insufficient (many articles, need morphological search), consider integrating Sphinx or Elasticsearch via the OnSearchIndex and OnSearchReindex events. If using Elasticsearch, implement the OnSearchIndex event to push custom fields into the index, improving relevancy for product-specific queries.
Version Control and Access Rights
For an internal KB with multiple editors, you need article change history. The platform’s main module has built-in versioning for info blocks—enable it in the info block settings (VERSIONING = Y). History is stored in the b_iblock_element_version table. With versioning enabled, each element save creates a history record. Editors can roll back via the admin interface. For loaded bases with frequent edits, limit stored versions—by default all are kept, which bloats the database. We recommend storing no more than 20 last versions. To automatically enforce versioning limits, subscribe to the OnBeforeIBlockElementUpdate event and check the version count using CIBlockElement::GetList against b_iblock_element_version before saving.
Access rights to sections are set via CIBlock::SetPermission() at the user group level. Private sections require permission checks in components—standard bitrix:news.* components automatically respect info block rights. If you need to differentiate access to individual articles within a section, use element properties with rights set via CIBlockElement::SetPermission().
Common Mistakes to Avoid
- Ignoring indexation: Without proper indexing, search becomes slow. Always specify fields and reindex after content updates.
- Over-nesting hierarchy: More than 4 levels confuse users. Keep it flat within reason.
- Skipping versioning limits: Unbounded history tables lead to database bloat. Set a cap.
-
Forgetting cache: Without caching, navigation and search pages suffer high load. Use
CPHPCachefor tree menus and search results.
How to Build Your Knowledge Base Step by Step
- Analyze your content and determine structure.
- Select the right architecture (learning module or info blocks).
- Configure info blocks, properties, and sections.
- Set up navigation and search.
- Enable versioning and access rights.
- Import content and test.
Work Process
| Phase | Duration |
|---|---|
| Content analysis and structuring | 2–3 days |
| Architecture choice (learning or info blocks) | 1 day |
| Creating info blocks, properties, and sections | 2–4 days |
| Navigation and search setup | 2–3 days |
| Versioning and access rights | 1–2 days |
| Content import and testing | 3–5 days |
| Deployment and editor training | 1–2 days |
What's Included
- KB architecture selection tailored to your needs.
- Creation of info blocks, properties, sections, and user fields.
- Navigation component setup (breadcrumbs, section tree).
- Full-text search integration and faceted filtering.
- Versioning enablement and access rights configuration.
- Import of existing content (Excel, CSV, Word).
- Documentation and editor training.
- 30-day warranty support.
Timelines and Examples
An average KB project with 100–300 articles takes 7 to 14 business days turnkey. Cost is calculated individually, depending on structure complexity and integration needs. Typical projects start from $1,500 for a basic setup, and our clients typically save 20-30% compared to in-house development, with project costs ranging from $1,500 to $5,000. Our clients save an average of $2,500 per project, and typical ROI is achieved within 3 months. Over 7 years, we have delivered more than 50 documentation repositories for IT, retail, and manufacturing companies. Contact us for a one-day project assessment.
Example Knowledge Base Structure
- Product
- Category A
- Topic 1
- Article 1
- Article 2
- Topic 2
- Topic 1
- Category B
- Topic 3
- Category A

