MediaWiki как корпоративная вики: любовь заканчивается на первой таблице

MAATRIX

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

Почему выбор вообще падает на MediaWiki

Аргументы в пользу MediaWiki реальные, и их стоит проговорить до того, как переходить к недостаткам.

Бесплатность без ловушек. MediaWiki распространяется под GPL, нет ни ограничений по числу пользователей, ни платных тарифов «Pro» с урезанными фичами в бесплатной версии — это не freemium-модель, а полноценный опенсорс. В отличие от Confluence, где лицензия считается по головам, или Notion, где команда упирается в лимиты бесплатного плана, MediaWiki не выставит счёт, когда в компании появится сотый сотрудник.

Проверенная на экстремальных нагрузках надёжность. Тот же код (с доработками для масштаба) держит Википедию — один из самых посещаемых сайтов в мире. Для внутренней базы знаний компании на 50–500 человек нагрузка будет исчезающе малой долей от того, что движок выдерживает на проде Wikimedia Foundation. Стабильность самого ядра — не вопрос.

Сообщество и документация. У MediaWiki огромная база расширений (тысячи штук в официальном каталоге), активные форумы и подробная документация на mediawiki.org. Если возникла проблема — почти наверняка кто-то её уже решал и написал об этом.

Отсутствие вендор-лока. Данные хранятся в обычной MySQL/MariaDB, экспорт и миграция хорошо документированы, формат хранения (вики-разметка) — открытый текстовый стандарт, который переживёт любую смену движка. Это важно, если через пять лет вы захотите куда-то переехать: дамп MediaWiki читаем и пригоден для миграции, а не заперт в проприетарном формате.

Всё это правда. Проблема в том, что перечисленные плюсы — про движок как инженерную систему, а не про опыт нетехнического сотрудника, который открывает вики в первый раз.

Установка: LAMP/LEMP-стек и первые полчаса

Установка MediaWiki — стандартная задача для любого, кто ставил PHP-приложение на сервер. Понадобится веб-сервер (Nginx или Apache), PHP с нужными расширениями, СУБД (MySQL или MariaDB) и сам дистрибутив с mediawiki.org.

Минимальный набор пакетов на Ubuntu/Debian:

apt update
apt install nginx php php-fpm php-mysql php-xml php-mbstring \
  php-intl php-apcu php-gd mariadb-server unzip

Создаём базу и пользователя для вики:

CREATE DATABASE mediawiki CHARACTER SET utf8mb4;
CREATE USER 'mwuser'@'localhost' IDENTIFIED BY 'СЛОЖНЫЙ_ПАРОЛЬ';
GRANT ALL PRIVILEGES ON mediawiki.* TO 'mwuser'@'localhost';
FLUSH PRIVILEGES;

Дистрибутив скачивается с mediawiki.org — берите актуальную LTS-ветку, а не первую попавшуюся версию: у LTS дольше цикл поддержки и патчей безопасности, что критично для корпоративного использования на годы вперёд.

cd /var/www
tar -xzf mediawiki-*.tar.gz
mv mediawiki-* wiki
chown -R www-data:www-data wiki

Дальше — веб-установщик по адресу http://ваш-сервер/wiki, который проверит окружение, попросит данные для подключения к базе и в конце сгенерирует файл LocalSettings.php — его нужно скачать и положить в корень вики. Это главный конфигурационный файл: здесь задаётся название вики, права доступа, список подключённых расширений и почти все прочие настройки.

Альтернатива — официальный Docker-образ mediawiki, который удобно поднять вместе с MySQL через docker-compose: меньше ручной возни с PHP-расширениями, но вам всё равно придётся руками монтировать LocalSettings.php и папку extensions/ для кастомизации. Голая установка на этом этапе занимает от силы 20–30 минут и работает. Разочарование начинается дальше — когда в эту голую вики приходит первый нетехнический сотрудник.

Первое разочарование: редактор по умолчанию

Открыв MediaWiki впервые, сотрудник видит форму редактирования с полем для вики-разметки — не WYSIWYG, а текстовый синтаксис вроде:

== Заголовок раздела ==
'''Жирный текст''' и ''курсив''.
* Пункт списка
* Ещё пункт
[[Ссылка на другую страницу]]
[https://example.com Внешняя ссылка]

Для человека, который последние десять лет работал в Google Docs, Word или Notion, это выглядит как шаг в прошлое. Разметка не сложная сама по себе, но она требует запоминания синтаксиса — а нетехническая команда его не запомнит и просто перестанет писать в вики, вернувшись к общему файлу в облаке.

Решение существует — расширение VisualEditor, которое даёт классический WYSIWYG-интерфейс поверх той же вики-разметки (страница сохраняется всё равно как вики-текст, редактор — это надстройка). Начиная с относительно современных версий MediaWiki движок Parsoid, отвечающий за конвертацию между вики-текстом и HTML для VisualEditor, встроен в ядро как PHP-библиотека — раньше это была отдельная Node.js-служба, которую приходилось разворачивать и поддерживать самостоятельно, и именно это было источником доброй половины проблем при внедрении VisualEditor. Сейчас порог входа ниже, но всё равно придётся:

// в LocalSettings.php
wfLoadExtension( 'VisualEditor' );
$wgDefaultUserOptions['visualeditor-enable'] = 1;
$wgVirtualRestConfig['modules']['parsoid'] = [
    'url' => 'http://localhost:8080',
    'domain' => 'localhost',
    'prefix' => 'localhost',
];

Расширение нужно скачать отдельно (той же версии, что и ядро MediaWiki — несовпадение версий ядра и расширений частая причина белого экрана после обновления), положить в extensions/VisualEditor, включить в конфиге и перепроверить права на редактирование для нужных групп пользователей. Ничего непреодолимого, но это уже не «поставил и работает» — это отдельный этап настройки, который в голой установке отсутствует, а честной документации именно под свежую версию не всегда легко найти с первого раза.

Вторая проблема: таблицы и структурированные данные

Вот где разочарование становится по-настоящему болезненным. Даже с включённым VisualEditor таблицы в MediaWiki — это по умолчанию просто HTML-таблица, вставленная в текст страницы. Она не связана с другими таблицами, в неё нельзя добавить вычисляемое поле, нельзя отфильтровать или отсортировать данные на лету средствами самого движка, нельзя собрать сводный список «все страницы, где статус = в работе» без ручного обновления вручную составленного списка.

В вики-разметке таблица выглядит так:

{| class="wikitable"
! Сервер !! IP !! Ответственный
|-
| web-01 || 10.0.0.5 || Иван
|-
| web-02 || 10.0.0.6 || Мария
|}

Работает, но любое изменение структуры — это правка синтаксиса построчно. Для команды, которая привыкла к базам данных внутри Notion или Airtable (фильтры, представления, связанные записи), это ощущается как откат на десять лет назад.

Решение — расширения для структурированных данных, и тут два основных кандидата:

С Cargo можно объявить таблицу прямо в шаблоне страницы:

{{#cargo_declare: _table = Servers
| Name = String
| IP = String
| Owner = String
}}

а потом собирать данные со всех страниц в единый фильтруемый список через {{#cargo_query: ...}}. Это уже реально похоже на лёгкую базу данных внутри вики — но это отдельная система, которую нужно спроектировать заранее (схема таблиц, поля, типы), а не просто «включить галочку». Для команды без опыта работы с MediaWiki-экосистемой это ощутимый порог входа: придётся либо самим разобраться в синтаксисе Cargo/SMW, либо звать того, кто уже это делал.

Права доступа, поиск и прочие нюансы корпоративного использования

Помимо редактора и таблиц, есть ещё несколько мест, где голая MediaWiki требует доработки напильником для комфортного корпоративного использования.

Права доступа. По умолчанию MediaWiki скорее открытая система (в духе энциклопедии), а не закрытая корпоративная вики. Чтобы закрыть чтение и правки только для сотрудников, нужно явно прописать в LocalSettings.php:

$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = true;

Более тонкая настройка — права по разделам/namespace (например, отдел кадров видит одни страницы, разработка — другие) — тоже возможна, но требует продуманной структуры namespace с самого начала и, как правило, дополнительного расширения вроде NamespacePermissions, потому что базовый механизм прав в MediaWiki рассчитан на модель «читатель/редактор/администратор», а не на гибкие ACL по отделам.

Поиск. Встроенный полнотекстовый поиск MediaWiki (на MySQL-бэкенде) слабый — он плохо справляется с релевантностью и почти не работает с русской морфологией без дополнительной настройки. Для вики хоть сколько-нибудь заметного размера практически обязательно ставить CirrusSearch — расширение на базе Elasticsearch/OpenSearch, которое использует сама Wikimedia. Это отдельный сервис, который нужно развернуть и поддерживать рядом — дополнительная память и ещё один процесс для мониторинга.

Аутентификация. Для входа сотрудников через корпоративный LDAP или SSO понадобится ещё одно расширение (LDAP Authentication или аналог) и его отдельная настройка — из коробки MediaWiki работает только с собственной локальной таблицей пользователей.

Обновления. MediaWiki обновляется чаще, чем кажется на старте, и мажорные обновления требуют прогона update.php, а иногда — синхронной замены версий у всех установленных расширений, иначе после обновления ядра вики может просто не открыться. Планируйте регламент обновлений заранее, а не по факту сбоя.

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

Когда MediaWiki оправдан, а когда лучше взять другое

MediaWiki имеет смысл выбирать не потому что «это же Википедия», а под конкретный профиль команды и задачи.

Берите MediaWiki, если:

• в команде есть кто-то технический, готовый поддерживать расширения и не боящийся PHP-конфигов;
• база знаний действительно большая и сильно связанная — тысячи страниц, перекрёстные ссылки, категории, шаблоны — где богатая экосистема расширений окупает порог входа;
• важна максимальная свобода от вендор-лока и долгосрочная стабильность формата данных на годы вперёд;
• нужна модель со строгим редакционным процессом (черновики, обсуждения, история правок с построчным diff) — здесь MediaWiki сильнее многих конкурентов из коробки.

Стоит присмотреться к альтернативам, если:

• команда преимущественно нетехническая и ей нужен привычный WYSIWYG без дополнительной настройки Parsoid/VisualEditor;
• структурированные данные (реестры, каталоги, списки с фильтрами) — центральный сценарий использования, а не редкое исключение;
• нет ресурса на сопровождение отдельного стека расширений (VisualEditor + Cargo/SMW + CirrusSearch + LDAP — это уже четыре взаимозависимых компонента поверх ядра).

Для второго случая стоит посмотреть на более современные self-hosted вики — например, сравнение BookStack и Wiki.js, где WYSIWYG или Markdown-редактор работают из коробки без отдельной установки Parsoid. Если компания как раз потеряла доступ к Confluence и нужен быстрый план переезда, разбор что поднять взамен Jira и Confluence даёт более широкий обзор вариантов, не только MediaWiki. А если задача — не столько вики, сколько поиск ответов по накопленным документам, есть смысл посмотреть на базу знаний с ИИ-поиском, которая решает проблему «поиск не находит то, что нужно» принципиально иначе — не структурой вики, а семантическим поиском по содержимому.

Отдельно от выбора движка стоит и вопрос СУБД под него: MediaWiki одинаково хорошо работает и на MySQL, и на MariaDB, и если сервер разворачивается с нуля, стоит сразу определиться — краткий разбор в статье про установку и настройку MariaDB на VPS покрывает практическую часть этого шага.

Частые вопросы