Почему строить базу знаний компании на основе mediawiki — недурная затея

В последнее время Confluence и sharepoint стали почти безраздельно править на рынке баз знаний. Системы отличные, не спорю, но лично мне не хватает их гибкости да и в целом как-то не срослось: вики-возможности sharepoint остались где-то на уровне 2005 года (про работу с офисными документами молчу, с ними все гуд), а Confluence в силу своих особенностей с ростом числа статей неумолимо превращался в свалку, в которой невозможно найти что-либо нужное (но, может, проблема была во мне ^[1]).

Не умаляя достоинства этих систем, хотелось бы рассказать о том, какие возможности есть у Mediawiki ^[2] в роли корпоративной базы знаний. Само собой, mediawiki подойдет не всем — в ней нет модной интеграции с jira/tfs/etc, перенос документов с картинками из пакета Microsoft Office доставляет кучу неудобств, да и сама она написана на PHP, что в последнее время служит отпугивающим фактором для некоторых айтишников. Тем не менее, платформа живее всех живых и над ее развитием работает изрядное количество людей, коль скоро на ней базируется семейство проектов фонда Викимедиа ^[3].

Сама по себе вики довольно скупа на возможности, но для нее написано огромное множество расширений ^[4]. Большая часть интересного функционала кроется именно в расширениях, так что изрядная часть статьи будет именно про них. И да, не могу не отметить, что есть специальная корпоративная версия Mediawiki — BlueSpice ^[5], которой я не пользовался, а потому не могу судить об ее адекватности.

Сперва про фишки самой mediaiwki

Прежде чем говоритиь о расширениях, стоит упомянуть о том, какие вообще особенности есть у самой mediawiki. Если на вашем счету тысяча правок на википедии, то вряд ли вы узнаете что-то новое из этой части, ее можно смело пропустить.

Первая и одна из самых ощутимых плюшек — категории ^[6]. Страницы можно добавлять в категории, сами категории можно добавлять в категории. В отличие от файловой структуры (забудем про симлинки), страница/категория может находиться сразу в нескольких категориях. Использование категорий препятствует росту хаоса с ростом числа статей. Особенно если просматривать периодически списки некатегоризованных статей и некатегоризованных категорий

Пространства имен ^[7]. Идеология вики гласит о том, что все является страницей (даже категория или изображение). Для того, чтобы отделять страницы разных типов, была добавлена идея пространств имен. При желании можно добавлять свои пространства имен, чтобы отделять знания разного типа (к примеру, отдельные пространства имен для информации о продукте, утилит, гайдов, описания процессов, иной служебной информации).

Также вики поддерживает шаблоны ^[8] — вики-страницы, которые впоследствии можно включать в другие страницы. Шаблоны поддерживают работу с параметрами, что превращает их в нечто большее, чем простые текстовые вставки: при желании на языке шаблонов можно написать несложный скрипт. К слову, говорят, что язык шаблонов может быть полным по Тьюрингу ^[9].

В дополнение к шаблонам расширение Scribunto ^[10] позволяет использовать lua-модули внутри вики. Модули вместе с шаблонами позволяют реализовать многие вещи, даже не обращаясь к написанию своих расширений.

К примеру, навигационные таблицы ^[11] построены на базе этого дуэта. Навигационная таблица — это, например, вот эта штука, которую обычно можно увидеть внизу страницы:

Они хоть и не являются стандартным функционалом, но зарекомендовали себя как удобное средство навигации и наведения порядка и используются сейчас почти повсеместно.

Не могу не упомянуть Mediawiki:Common.css ^[12]и Mediawiki:Common.js ^[13] файлы, позволяющие добавить небольшую кастомизацию вики — для больших вещей лучше использовать расширения.

Редакторы

Одна из самых важных частей вики — это редактор. Крайне сложно внедрить вики, если в ней нет визуального редактора, потому как учить вики-разметку согласится только очень инициативный человек.

Visual Editor

Сравнительно свежее расширение — VisualEditor ^[14] решает проблему с визуальным редактированием статей. У него есть свои косяки, но для большинства задач его хватает. Из самых заметных проблем — там не самая удобная вставка изображений.

Появление визуального редактора тесно свзяано с появлением Parsoid ^[15] — сервиса конвертации между Mediawiki синтаксисом и html. Задача эта оказалась крайне нетривиальной в силу того, что mediawiki синтаксис развивался хаотично и не был строго определен. Подробнее можно почитать в прекрасном посте официального блога ^[16].

Среди расширений, интегрирующихся с VisualEditor, можно выделить Graph ^[17] для редактирования графов, Math ^[18] для редактирования математических формул и SyntaxHighlight ^[19] для подсветки синтаксиса фрагментов кода.

WikiEditor

WikiEditor ^[20] — простой редактор викитекста. Некоторые хитрые вещи все еще удобнее делать через редактор викитекста, в некоторых местах все еще не поддерживается визуальное редактирование. Как бы то ни было, WikiEditor облегчает работу с викитекстом, а еще его довольно просто кастомизировать ^[21].

Конфликиты редактирования

Кто пользовался в прошлом Mediawiki, тот помнит, какой болью становилось каждое разрешение конфликтов редактирования.

TwoColConflict ^[22] со включенным по умолчанию бета-режимом сильно упрощает решение проблемы. В случае возникновения конфликта можно посмотреть на те места, где имеет место конфликт, и выбрать нужную версию спорного фрагмента. Если обе версии не полны, то можно дополнить одну из них. Как-то так это выглядит в деле:

Можно попробовать самому на тестовой странице ^[23].

Формы для добавления однотипного контента

Расширение PageForms ^[24] позволяет добавлять на вики однотипный контент при помощи форм. В своей пратике я использовал формы для добавления на вики реестровых ключей, таблиц БД и других подобных типовых вещей.

Это расширение раскрывает свою мощь при использовании Semantic Mediawiki ^[25] или его аналогов. Семантическая медиавики позволяет добавлять на страницу свойства страницы или объекты со своими свойствами. Задаются свойства примерно так (на примере страницы Германия):

[[Имеет столицу::Берлин]]

Эти свойства и объекты после можно получить при помощи запроса ask ^[26] или через api.

Из полученных свойств можно выводить таблицы, строить графики и делать много других крутых вещей ^[27]. К примеру, в моем случае на основе таблиц, добавленных через формы, строятся простейшие схемы бд. При этом схему можно строить не для всего продукта, а для конкретной категории. И в схеме можно отразить помимо очевидных FK/PK связей еще и неявные связи, которые не увидеть стандартными средствами построения диаграмм.

Для реестровых ключей из тех же свойств вытаскивается ключевая информация для того, чтобы на ее основе можно было бы генерировать .reg файл с заданным значением.

Дерево категорий

PageForms поддерживает возможность добавления поля с деревом категорий, так что для добавления страницы в нужные категории будет достаточно только кликнуть по нужным чекбоксам.

С другой стороны, когда у нас уже есть разложенные по категориям статьи, их можно отобразить на любой странице в виде дерева:

Дерево грузится динамически, так что оно работает и для большого числа статей, и для зацикленных категорий, если такие вдруг кому-то нужны.

LDAP/AD авторизация

Расширение Ldap Authentication ^[28] поддерживает авторизацию через домен, ограничение доступа для определнных групп и маппинг групп юзеров mediawiki на группы ldap. Можно настроить сразу несколько доменов. Довольно утомительная вопросах настройки, но, к счастью, в интернетах есть очень даже неплохие инструкции ^[29].

Гранулярные права доступа

Вот тут все плохо. Если задача стоит в том, чтобы ограничить доступ неавторизованным пользователям, то это просто. Если среди этих пользователей нужно выделить отдельные группы с особыми правами доступа, то это сложно.

Есть много разных расширений, но они не решают фундаментальную проблему: mediawiki не была создана как CMS. Для поддержки прав доступ придется патчить код Mediawiki, маниакально добавляя

$title->userCan('read')

во все, что не должно отдаваться без проверки прав. То же самое касается и всех расширений: для каждого добавленного расширения придется вручную добавлять все необходимые проверки.

Для себя я решил проблему самодельным расширением, построенном на идее из PermissionACL ^[30] и пачки патчей для разных расширений и самой mediawiki. К счастью, мне не был нужен продвинутый ACL, хватило и примитивных проверок для нескольких групп.

Для поддержки того же самого для изображений придется завернуть обращения к файлам в Img_auth.php ^[31]. А последний использует стример файлов от mediawiki, который не умеет отдавать partial content ^[32] (на момент mediawiki 1.31), так что для поддержки воспроизведения видео придется приделывать другой стример файлов.

Поддержка видео

Поддержка видео не входит в стандартную поставку, но тривиально решается установкой расширения TimedMediaHandler ^[33]. Обычный видеоплеер, ничего особого. Вставка видео на страницу абсолютно аналогична вставке изображения.

Поиск

Одна из раздражающих меня лично вещей в Confluence — это поиск. Стандартный поиск Mediawiki еще хуже, но к счастью есть сторонние расширения. Из поисковых расширений самые популярные — это CirrusSearch ^[34] и SphinxSearch ^[35]. Последним я никогда не пользовался, но с первым мне довелось познакомиться очень плотно, он же, кстати, используется и в проектах фонда викимедиа

CirrusSearch работает на базе elasticsearch ^[36], для работы расширения придется еще поставить промежуточный интерфейс — расширение Elastica ^[37].

CirrusSearch поддерживает безумное число параметров ^[38] и довольно активно развивается. Например, меня очень порадовало, что в ветке 1.32 заработал поиск по CamelCase.

Еще один момент, который мне приглянулся — это возможность добавить словарь синонимов. Словарь хорошо работает с устоявшимся внутренним корпоративным жаргоном, аббривеатурами, типичными опечатками или различными транслитерациями. Но словарь нужно сперва написать, что может оказаться не самой простой задачей. Если не затачивать словарь под конкретную компанию, можно попробовать существующие словари в духе WordNet ^[39], но не факт что они подойдут лично вам.

Расширение не поддерживает добавление синонимов на уровне конфига LocalSettings ^[40], но это несложно решить правкой кода расширения — см AnalysisConfigBuilder.php ^[41] и инструкцию по настройке синонимов elasticsearch ^[42].

При желании можно добавить на главную страницу поисковую строку через расширение InputBox ^[43], после чего к нему можно прикрутить автодополнение по инструкции ^[44].

Кстати, AdvancedSearch ^[45] поможет привести в порядок вид страницы поиска, с ним она не будет выглядет как жертва любителя чекбоксов.

Аналитика

Звучит смешно, конечно, но аналитика крайне полезна даже для внутренней базы знаний, которую посещает в месяц сотня человек. Она позволяет понять, как пользователи взаимодействуют с интерфейсом, что ищут, что читают, чем пользуются. Если в планах есть дальнейшее развитие базы знаний, статистика будет просто бесценной.

Для интранета есть крайне достойное расширение Matomo ^[46] (ex Piwik). Соответствующее расширение для интеграции — MatomoAnalytics ^[47].

Matomo собирает статистику по поисковым запросам, источникам трафика, загрузкам, переходам по ссылкам (можно посмотреть частоту перехода по ссылкам с наложением на саму страницу) и множество других метрик. Статистику можно собирать как с привязкой к конкретным пользователям, так и анонимную, чтобы не смущать никого.

Прочее

Помимо перечисленного есть немало расширений, которые просто облегчают жизнь. Например, GuidedTour ^[48]для обучения новичков основам работы с интерфейсами, Popups ^[49] для предпросмотра статей по наведении на ссылку, MultimediaViewer ^[50] для более кофмортного просмотра полноразмерных изображений и многое-многое другое.

Что в итоге?

Перечисленный джентельменский набор расширений покрывает значительную часть потребностей при создании базы знаний, но не все. Mediawiki не годится в качестве универсальной единой базы знаний. Но в качестве универсальной системы также плохо справляются и все остальные — sharepoint, confluence, олдскульные папочки outlook, поиск по которым занимает полчаса и т.д. Mediawiki же на их фоне отличается своими возможностями кастомизации и отличной масштабируемостью.

В противовес всем перечисленным плюсам mediawiki постоянно требует допиливания напильником функционала под нужды конкретной компании, так что ее администратору стоит быть морально готовым разбираться в php, js и lua коде. Но если это не пугает и если вы согласны разделять работу с офисными документами и работу с вики статьями по разным платформам, mediawiki в качестве базы знаний может оказаться весьма недурной затеей.

Автор: Coob

Источник ^[51]