База знаний на PHP: сравнение Tiki, HumHub, WordPress и phpBB

Внутренняя база знаний на PHP в такой постановке должна уметь почти всё: документировать деятельность, вести учёт оборудования, хранить данные клиентов и партнёров, образцы документов и фотографии — с иерархией разделов, ролями и API, бесплатно и желательно с привычным форумным интерфейсом. Готового решения, которое закрывало бы всё это «из коробки», не существует — есть четыре платформы, каждая со своим компромиссом: Tiki Wiki CMS Groupware, HumHub, WordPress с bbPress и phpBB с расширениями. Версии, лицензии и активность проверены 11 ноября 2026 года по API репозиториев и официальным каталогам — не по памяти и не по прошлогодней статье.

Сразу главное: ни одна из четырёх не является системой учёта оборудования, и это не их вина — для инвентаризации нужен отдельный инструмент. Всё остальное они закрывают, но с очень разной ценой сопровождения. Материал заменяет прежнюю заметку 2025 года, где сравнение было одной таблицей без проверки версий.

TL;DR: что это и как проверить за десять минут

1. Задача. Внутренняя база знаний: вики-страницы с иерархией, файлы и фото, задачи, обсуждения, роли, API.
2. Tiki — «всё в одном»: вики, форум, трекер, календарь в одном пакете. Самое полное покрытие и самая высокая цена освоения.
3. HumHub — корпоративная соцсеть с модулями Wiki и Tasks: современный интерфейс, задачи ближе всего к Asana, форум — отдельным модулем.
4. WordPress + bbPress — знакомый интерфейс и лучшая экосистема; функции собираются из плагинов, за совместимость отвечаете вы.
5. phpBB + расширения — идеальный «форумный» вид и минимум нагрузки; вики и задачи здесь только имитацией.
6. Проверка версий — четыре запроса к API, не требующие установки:

curl -s https://api.wordpress.org/core/version-check/1.7/ | head -c 160; echo
curl -s https://api.github.com/repos/humhub/humhub/releases/latest | grep '"tag_name"'
curl -s "https://gitlab.com/api/v4/projects/tikiwiki%2Ftiki/repository/tags?per_page=3" | grep '"name"'
curl -s https://api.github.com/repos/phpbb/phpbb/tags | grep '"name"' | head -4

Ожидаемо на 11.11.2026: WordPress 7.1.4, HumHub v1.19.4, Tiki 30.2 (и поддерживаемые ветки 24.x, 27.x), phpBB release-3.3.19 плюс альфа release-4.0.0-a2.

Проблема, которую это решает

Внутренняя база знаний ломается не на выборе движка, а на трёх вещах. Первая — структура: пока документы лежат в папках на файловом сервере, «где у нас регламент замены картриджей» знает один человек. Вторая — поиск: если он не находит по содержимому и по вложениям, база знаний превращается в свалку, к которой возвращаются копипастой из чата. Третья — права: данные клиентов и оборудование нельзя показывать всем, а разграничение «по отделам и разделам» на файловом сервере делается вручную и рассыпается при первом переводе сотрудника.

Форумный интерфейс в этой задаче — не эстетика, а привычка аудитории: если сотрудники годами пользовались форумом, дерево «раздел → подраздел → тема» они освоят быстрее, чем пространства и страницы. Именно поэтому в требованиях и появился «вид как на трекере».

Отсюда критерий выбора: не «какая система мощнее», а сколько компонентов придётся связать и кто будет их обновлять. Ниже — сравнение по этому критерию.

Что такое эти четыре платформы

Все четыре — PHP-приложения с базой MySQL/MariaDB, но устроены они по-разному, и это определяет всё остальное.

flowchart LR
  U["Сотрудник"] --> WEB["Nginx / Apache + PHP"]
  WEB --> CORE["Ядро платформы"]
  CORE --> WIKI["Вики-раздел"]
  CORE --> TASKS["Задачи"]
  CORE --> FORUM["Форум"]
  WIKI --> DB[("MySQL / MariaDB")]
  TASKS --> DB
  FORUM --> DB
  WIKI --> FS[("Каталог вложений")]
  CORE --> AUTH["Пользователи и роли"]
  AUTH --> DB

Разница в подходе видна на одной ситуации — «нужна вики рядом с форумом». В Tiki вики уже есть, включать нечего. В HumHub её включает модуль. В WordPress ставится плагин базы знаний. В phpBB ищется расширение, которое добавляет к форуму простейшие статьи с версиями, — или рядом поднимается второй движок.

Возможности

Требования из исходной задачи сведены в матрицу. Обозначения: «да» — есть штатно или официальным модулем, «частично» — реализуемо с оговорками, «—» — нет.

База знаний и документы

Задачи и проекты

Обсуждения, права и интеграции

Как это устроено внутри

Разница между «всё в одном» и «ядро + модули» проявляется не в функциях, а в том, что происходит с запросом и с обновлением.

flowchart TD
  R["HTTP-запрос"] --> M["Маршрутизация: раздел и материал"]
  M --> P{"Права пользователя"}
  P -- нет --> D["403 или скрытие раздела"]
  P -- да --> Q["Выборка из базы"]
  Q --> F["Вложения из каталога файлов"]
  F --> T["Шаблон ядра"]
  T --> A["Ответ страницы"]
  Q --> S["Поисковый индекс"]

1. Маршрутизация. Tiki и phpBB определяют страницу по своей схеме URL из коробки; WordPress разбирает адрес по правилам ЧПУ и отдаёт его плагинам через хуки; HumHub ищет пространство и модуль по сегментам пути.
2. Права. В Tiki и phpBB проверка прав встроена в ядро и настраивается группами; в WordPress её выполняет ядро для ролей, а тонкости вроде «этот раздел вики только для отдела» добавляет плагин; в HumHub права привязаны к пространству.
3. Выборка и рендер. Единственное ядро (Tiki, phpBB) держит один слой шаблонов и один стиль кода — обновление меняет всё сразу. Связка WordPress + bbPress + плагин вики + плагин задач — это четыре независимых цикла обновлений, и совместимость между ними никем не гарантирована.
4. Файлы. У всех четырёх вложения живут в файловой системе, а метаданные — в базе. Значит, бэкап «только база» неполон: восстановление без каталога вложений даёт базу знаний с битыми картинками.

Практический вывод из схемы простой: чем больше компонентов, тем дешевле старт и тем дороже сопровождение. Tiki и phpBB требуют меньше решений при развёртывании, WordPress — меньше усилий на обучение пользователей, HumHub — меньше усилий на «чтобы выглядело современно».

Есть и вторая разница, которую видно только при обновлении. У систем «всё в одном» обновление — это одна процедура и один список изменений: если портал поднялся после обновления, он поднялся целиком. У связки на WordPress каждый компонент обновляется отдельно и в своём темпе, поэтому проверять нужно не «обновилось ли ядро», а «работают ли после этого форум, вики и задачи вместе». На практике это выглядит так: ядро обновилось вечером, а утром выясняется, что плагин задач потерял связь с рубриками. Именно поэтому в чек-листе ниже отдельным пунктом стоит регламент обновлений с проверкой совместимости.

Замеры и цифры

Все числа сняты 11 ноября 2026 года: версии и активность — через API репозиториев (GitHub, GitLab, api.wordpress.org), лицензии — по файлам LICENSE в репозиториях, размер репозитория — поле size в GitHub API.

Границы замера, без которых числа врут: размер репозитория — это история кода, а не размер установки (у WordPress в репозитории лежат все ветки и тесты). Звёзды измеряют внимание разработчиков, а не качество: у Tiki основная площадка — GitLab, поэтому 86 звёзд там несопоставимы с 21 тысячей на GitHub. Поведенческих замеров (скорость страницы, число запросов) здесь нет: для этого нужно поднимать все четыре системы, а такой замер ничего не скажет о вашей нагрузке.

Сильные стороны продукта

Речь о сильных сторонах самого подхода «бесплатное PHP-ядро плюс модули», потому что именно он объединяет все четыре варианта.

1. Нет подписки и нет вендор-лока. Все четыре распространяются по свободным лицензиям (GPL, LGPL, AGPL), код лежит в открытых репозиториях: WordPress и phpBB — на GitHub, Tiki — на GitLab. Развернуть можно на своём сервере без внешних зависимостей.
2. Данные остаются внутри. База и вложения лежат на вашем диске: данные клиентов и оборудование не уезжают в чужое облако, а бэкап — это два каталога и дамп базы.
3. Единая аутентификация на всё. Во всех четырёх пользователь один: и в вики, и в задачах, и в форуме. Не нужно синхронизировать учётки между системами.
4. Права настраиваются по разделам, а не «всё или ничего». Группы и роли есть штатно у Tiki, phpBB и WordPress, у HumHub — через пространства.
5. Привычный интерфейс снижает стоимость обучения. phpBB и bbPress дают классическое дерево форума; для аудитории, выросшей на форумах, это готовый паттерн навигации.
6. Расширяемость без переписывания ядра. Tiki — модули, WordPress — плагины и хуки, HumHub — модули с миграциями, phpBB — расширения на событиях. Любой из вариантов доводится до требований без форка.
7. API для интеграций. У WordPress REST API в ядре с версии 4.7; у HumHub — отдельным модулем; у Tiki REST API появился в ветке 24 (по документации проекта). Это позволяет связать базу знаний с учётной системой или ботом.

Установка

Самый короткий путь для связки WordPress + bbPress (единственная из четырёх с полноценным CLI-установщиком):

wp core download --locale=ru_RU
wp config create --dbname=kb --dbuser=kb --dbpass='***' --dbhost=127.0.0.1
wp core install --url=https://kb.example.org --title="База знаний" \
  --admin_user=admin --admin_password='***' --admin_email=admin@example.org
wp plugin install bbpress --activate
wp plugin list --fields=name,status,version --format=table

Tiki и phpBB ставятся распаковкой архива и веб-мастером; HumHub — тоже архивом, установщик открывается по адресу /install. Для всех четырёх после установки обязательны три шага: включить HTTPS, настроить ежедневный дамп базы, вынести каталог вложений в бэкап.

Настройка

Порядок настройки у всех похож, но названия разные; важнее не названия, а последовательность — сначала структура, потом права, потом поиск.

flowchart TD
  S["Старт настройки"] --> ST["Структура разделов"]
  ST --> RO["Роли и права"]
  RO --> FL["Файлы и квоты"]
  FL --> SR["Поиск и проверка на реальных запросах"]
  SR --> AU["Вход: локальный или LDAP / SSO"]
  AU --> BK["Бэкап базы и вложений"]
  BK --> GO{"Восстановление проверено?"}
  GO -- нет --> BK
  GO -- да --> DONE["Портал готов к наполнению"]

Практическая настройка WordPress, которую чаще всего забывают: роли для вики и форума раздаются отдельно от роли «редактор», а bbPress использует роли самого WordPress.

wp role list --fields=name,role --format=table
wp cap add editor upload_files
wp option get blog_public          # 0 = сайт закрыт от индексации, для интранета это норма

Подводные камни

1. phpBB 4.0 — альфа, а не «скоро релиз». В репозитории лежат теги release-4.0.0-a1 и release-4.0.0-a2; рабочий вариант сегодня — 3.3.19. Планировать интеграции «на 4.0» нельзя: API там только появляется.

2. HumHub под двойной лицензией. Файл LICENSE прямо говорит: AGPL-3.0-only или проприетарная лицензия. Внутреннее использование AGPL не ограничивает, но если вы доработали код и отдаёте систему наружу как сервис — условия AGPL применяются.

3. REST API у HumHub — отдельный модуль. В ядре его нет: это ещё одна установка, ещё один цикл обновлений и ещё одна поверхность для ошибок.

4. У Tiki код не на GitHub. Репозиторий tikiwiki/tiki на GitHub отдаёт 404 — проект переехал на GitLab (gitlab.com/tikiwiki/tiki), там же теги. Это важно, если вы привыкли искать релизы через GitHub API.

5. Связка WordPress — это N обновлений. bbPress сегодня требует WordPress 6.0+ и заявлен совместимым с 7.1.4, но каждый следующий плагин (вики, задачи, права) обновляется самостоятельно. Перед обновлением ядра проверяйте всю цепочку, иначе получите базу знаний с неработающим форумом.

6. phpBB 3.3 без штатного REST API. Интеграция возможна через прямые запросы к базе или парсинг страниц — оба пути хрупкие. Если API нужен, phpBB не подходит как основа.

7. Учёт оборудования не закрывает ни одна из четырёх. Ни Tiki, ни HumHub не ведут инвентаризацию с серийными номерами, гарантией и историей ремонтов: получится таблица на вики-странице. Для учёта техники нужен специализированный инструмент (например, GLPI), а база знаний останется местом для регламентов и фото.

8. Поиск «из коробки» — не полнотекстовый. В WordPress это LIKE по заголовкам и тексту: на десятках тысяч страниц он начнёт тормозить и промахиваться. Если поиск критичен, планируйте внешний индекс.

9. Сайты проектов не всегда доступны скриптам. При проверке 11.11.2026 phpbb.com ответил 403, humhub.com не ответил вовсе — это защита от автоматических запросов, а не признак заброшенности проекта. Версии и лицензии надёжнее брать из API репозиториев.

10. Бэкап без вложений бесполезен. Все четыре хранят файлы вне базы. Проверьте восстановление на копии: дамп базы плюс каталог вложений, иначе база знаний восстановится без половины документов.

Чек-лист внедрения

• [ ] Список требований зафиксирован письменно: вики, задачи, форум, файлы, права, API — и что из этого обязательно, а что «хорошо бы».
• [ ] Выбран один вариант из четырёх и записано, чем он закрывает каждое обязательное требование.
• [ ] Проверено, что учёт оборудования вынесен в отдельную систему, а не «пока на вики».
• [ ] Определены роли: кто читает, кто пишет, кто модерирует, кто администрирует.
• [ ] Настроен HTTPS и закрыт внешний доступ (интранет или VPN).
• [ ] Настроен ежедневный бэкап: дамп базы + каталог вложений, с проверкой восстановления.
• [ ] Заведён регламент обновлений: кто и когда обновляет ядро, плагины и модули.
• [ ] Проверен поиск на реальных запросах сотрудников, а не на «тест».

FAQ

Итог

Из четырёх вариантов полностью закрывает требования связка WordPress + bbPress + плагины и Tiki — но разными способами: первая даёт знакомый интерфейс и экосистему ценой сопровождения четырёх компонентов, вторая — всё в одном пакете ценой сложности освоения. HumHub выигрывает там, где важен современный интерфейс и задачи, близкие к Asana, а форум — вторичен. phpBB остаётся лучшим выбором, если нужен только форум с базовой вики.

Общее правило для всех четырёх: считайте не функции, а стоимость эксплуатации. Система, которую кто-то обновляет и бэкапит, полезнее системы, которая «умеет больше» и стоит без обновлений полгода.

Цитата: База знаний умирает не от недостатка функций, а от отсутствия человека, который отвечает за её обновления и бэкапы.

Связанные материалы

• Лучшие плагины форумов для WordPress — детальное сравнение bbPress, wpForo и Asgaros в одной таблице.
• Репозиторий HumHub — исходный код, релизы и файл лицензии.
• Репозиторий phpBB — теги версий, включая альфу 4.0.
• Tiki на GitLab — код и теги проекта (на GitHub его нет).
• WordPress REST API — справочник по интеграциям, если строите связку на WordPress.
• Рубрика «WordPress» — остальные материалы по платформе.

LLM Summary

• Тема: выбор бесплатного PHP-решения для внутренней базы знаний с вики, задачами, форумом, файлами и правами.
• Сравниваемые платформы: Tiki Wiki CMS Groupware (LGPL-2.1-only, 30.2), HumHub (AGPL-3.0-only или коммерческая, 1.19.4), WordPress 7.1.4 с bbPress 2.6.21 (GPL), phpBB 3.3.19 (GPL-2.0-only, 4.0 в альфе).
• Что проверено и когда: версии, лицензии, звёзды и размер репозиториев — 11.11.2026 через GitHub API, GitLab API, api.wordpress.org и файлы LICENSE.
• Покрытие требований: Tiki и WordPress+плагины закрывают вики, задачи и форум; HumHub — соцсеть с модулями Wiki/Tasks; phpBB — форум, вики и задачи только имитацией.
• Ключевые команды проверки: curl к api.wordpress.org/core/version-check, api.github.com/repos/<owner>/<repo>/releases/latest, GitLab API проектов, wp plugin list.
• Установка: WordPress — wp core download + wp plugin install bbpress --activate; остальные три — распаковка архива и веб-мастер.
• Требования: PHP 8.1+, MySQL 5.7+/MariaDB 10.3+, Nginx/Apache, HTTPS, 1–2 ГБ памяти.
• Ограничения: ни одна из четырёх не ведёт учёт оборудования; REST API у phpBB 3.3 нет, у HumHub он отдельным модулем; поиск без внешнего индекса ограничен.
• Риски эксплуатации: множество независимых циклов обновлений в связке WordPress; AGPL при доработке HumHub; бэкап без каталога вложений бесполезен.
• Ссылки: репозитории humhub/humhub, phpbb/phpbb, gitlab.com/tikiwiki/tiki и внутренняя статья о плагинах форумов для WordPress.

Промт для агента (установка и настройка)

Источник шагов — README репозиториев github.com/humhub/humhub и github.com/phpbb/phpbb, документация WordPress (developer.wordpress.org) и страница плагина bbPress в каталоге WordPress.org; файлов AGENTS.md у этих проектов нет, поэтому шаги собраны из README и перечисленных страниц.

Задача: развернуть внутреннюю базу знаний на бесплатном PHP-стеке, выбрав один из четырёх вариантов.

1. Собрать требования письменно: вики, задачи, форум, файлы, права, API. Отметить обязательные.
2. Определить, нужен ли учёт оборудования: если да — вынести в отдельную систему, не в вики.
3. Проверить актуальные версии: api.wordpress.org/core/version-check, GitHub releases, GitLab tags.
4. Выбрать вариант по матрице: Tiki (всё в одном), HumHub (соцсеть и задачи), WordPress+bbPress (экосистема), phpBB (только форум).
5. Подготовить сервер: PHP 8.1+, MySQL 5.7+/MariaDB 10.3+, Nginx/Apache, HTTPS, 1–2 ГБ памяти.
6. Установить ядро: для WordPress — wp core download/config create/core install; для остальных — архив и веб-мастер.
7. Включить модули: bbPress и плагин базы знаний для WordPress; Wiki и Tasks для HumHub; расширения для phpBB.
8. Создать структуру разделов: рубрики/пространства/форумы — до наполнения контентом.
9. Настроить роли: читатель, автор, модератор, администратор; проверить на тестовом пользователе каждой роли.
10. Настроить квоты и права на файлы; проверить загрузку документа и фото под каждой ролью.
11. Настроить поиск и проверить его на пяти реальных вопросах сотрудников, а не на слове «тест».
12. Настроить бэкап: ежедневный дамп базы плюс каталог вложений; один раз восстановить на копии.
13. Закрыть сайт от внешнего доступа (интранет или VPN) и включить HTTPS.
14. Завести регламент обновлений: кто обновляет ядро, плагины и модули и когда проверяет совместимость.