Коли інфоблоки перестають справлятися з документацією

База знань часто виростає з хаосу: інфоблоки з купою полів, загублені версії, пошук не знаходить потрібне. Співробітники витрачають до 30% робочого часу на пошук інформації — це прямі збитки. Нещодавно до нас звернулася компанія: 5000 статей в інфоблоках, пошук через LIKE працював 30 секунд, версії не зберігалися, доступ — лише адміністраторам. Після впровадження модуля час пошуку скоротився до 0,2 секунди, а співробітники самі публікують статті з контролем змін. Частка незадовільних результатів пошуку знизилася на 60%. Інший клієнт зіткнувся з проблемою: при інтеграції з 1С через CommerceML дані оновлювалися раз на добу, і персонал працював із застарілими інструкціями. Після міграції на спеціалізований модуль синхронізація стала практично миттєвою, а час на пошук інформації скоротився ще на 40%. Коли на сайті сотні інструкцій, а співробітники витрачають години на пошук — це явний сигнал: потрібен модуль з версіонуванням, повнотекстовим пошуком та розмежуванням доступу. Ми займаємося Бітрікс-розробкою понад 10 років і гарантуємо якість кожного модуля. У цій статті розповімо, як влаштовано модуль зсередини, і покажемо реальні цифри. Зв'яжіться з нами для розрахунку вартості та термінів.

Які проблеми вирішує спеціалізований модуль бази знань?

Звичайні інфоблоки не дають:

• історії змін — не можна відкотитися до попередньої версії;
• повнотекстового пошуку — пошук по LIKE повільний і неточний;
• розмежування доступу — складно приховати розділи від неавторизованих користувачів;
• інтеграції з підтримкою — клієнт не може зі статті перейти до створення тікету.

Модуль Vendor.KnowledgeBase вирішує все це. Нижче — як він влаштований.

Як ми будуємо модуль: стек та архітектура

Модуль створюється на базі ORM Бітрікс (таблиці b_vendor_kb_*) з використанням PostgreSQL для повнотекстового пошуку. Також підтримується інтеграція з 1С через CommerceML для синхронізації статей з обліковою системою. Стек: PHP 8.1, ORM Бітрікс, PostgreSQL 15, Redis для кешування. Детальніше про ORM Бітрікс — у офіційній документації.

Модель даних:

• b_vendor_kb_section — розділи: id, parent_id, name, slug, description, sort, icon, access_level (public/registered/group), is_active
• b_vendor_kb_article — статті: id, section_id, title, slug, body (HTML/Markdown), excerpt, author_id, status (draft/review/published), views, helpful_count, not_helpful_count, created_at, updated_at, published_at
• b_vendor_kb_revision — версії статей: id, article_id, body, author_id, created_at, change_summary
• b_vendor_kb_attachment — файли: id, article_id, file_id, name
• b_vendor_kb_tag та b_vendor_kb_article_tag — теги

Як організовано версіонування статей?

При кожному збереженні створюється нова ревізія. Код сервісу — на PHP 8.1+:

class ArticleService { public function update(int $articleId, array $fields, int $editorId, string $changeSummary = ''): void { $current = ArticleTable::getById($articleId)->fetch(); RevisionTable::add([ 'ARTICLE_ID' => $articleId, 'BODY' => $current['BODY'], 'AUTHOR_ID' => $editorId, 'CHANGE_SUMMARY' => $changeSummary ?: 'Обновление', 'CREATED_AT' => new DateTime(), ]); ArticleTable::update($articleId, array_merge($fields, [ 'UPDATED_AT' => new DateTime(), ])); } public function rollback(int $articleId, int $revisionId): void { $revision = RevisionTable::getById($revisionId)->fetch(); $this->update($articleId, ['BODY' => $revision['BODY']], 0, 'Откат к ревизии #' . $revisionId); } } 

Історія версій зберігається безстроково. Для економії місця старі ревізії можна архівувати агентом (залишати N останніх + щомісячні знімки). Детальніше про версіонування — Wikipedia: Software versioning.

Як працює повнотекстовий пошук через PostgreSQL?

Пошук за заголовками та тілом статей будується на векторах tsvector. PostgreSQL tsvector у 3 рази швидший за звичайний LIKE-пошук на 10 000 статей. Детальніше про технологію — Повнотекстовий пошук на Wikipedia. Приклад SQL:

UPDATE b_vendor_kb_article SET fts_vector = to_tsvector('russian', title || ' ' || strip_tags(body)) WHERE id = :id; SELECT id, title, ts_headline('russian', body, q) AS excerpt FROM b_vendor_kb_article, to_tsquery('russian', :query) q WHERE fts_vector @@ q AND status = 'published' ORDER BY ts_rank(fts_vector, q) DESC LIMIT 20; 

Результат — з підсвічуванням збігів та ранжуванням. Вектор tsvector будується при збереженні статті тригером на рівні БД, а асинхронний агент оновлює індекс раз на хвилину. Пошук по 10 000 статей займає менше 0,1 секунди.

Що дає розмежування доступу?

У кожного розділу — рівень доступу:

• public — всім.
• registered — лише авторизованим.
• group — лише користувачам із зазначених груп Бітрікс.

Наслідування працює за принципом: якщо батьківський розділ прихований, всі дочірні автоматично отримують той самий рівень. Перевірка — у middleware компонента. Це гарантує, що конфіденційні документи не потраплять до сторонніх.

Друкована версія та PDF

Компонент vendor:kb.article.print віддає сторінку без навігації, оптимізовану для друку. PDF генерується через mPDF, кешується у файловій системі та скидається при оновленні статті.

Процес розробки модуля

Чек-лист етапів:

1. Аналіз вимог та схеми доступу.
2. Проектування таблиць ORM.
3. Реалізація сервісного шару (версіонування, пошук).
4. Розробка адміністративного інтерфейсу.
5. Створення компонентів сайту.
6. Інтеграція з тікет-системою (опціонально).
7. Тестування на реальних даних.
8. Деплой та навчання.

Що входить у роботу: deliverables

Порівняння самописної бази знань та готових рішень

Власний модуль дає безшовну інтеграцію та гнучкість — це окупається на масштабах від тисяч статей. На тестовому каталозі з 10 000 статей модуль показав у 3 рази меншу затримку пошуку порівняно з інфоблочним рішенням. Проект окупається за 6–12 місяців.

Орієнтовні терміни

Вартість розраховується індивідуально залежно від складності. Замовте консультацію — впровадимо базу знань за 2 тижні.