为什么建立基于MediaWiki的知识库不是一个坏主意

最近，Confluence和sharepoint已几乎完全占领了知识库市场。 这些系统非常出色，我并不认为，但是我个人没有足够的灵活性，并且无法以某种方式共同发展：SharePoint Wiki仍处于2005年的水平（我对处理Office文档一无所知，这一切都很嗡嗡声），并且由于融合的功能，越来越多的文章无情地变成了垃圾场，在这里找不到您需要的任何东西（ 但也许是我的问题所在 ）。

在不削弱这些系统优点的情况下，我想谈一谈Mediawiki作为企业知识库所具有的机会。 当然，mediawiki并不适合所有人-它与jira / tfs / etc没有时尚的集成，从Microsoft Office软件包中传输带有图片的文档很不方便，而且它本身是用PHP编写的，最近这对某些IT专家来说是一种威慑力。 但是，该平台比所有现有平台都更活跃，并且只要Wikimedia Foundation的一系列项目都基于该平台，那么就有很多人在致力于该平台的开发。

Wiki本身对这种可能性非常谨慎，但是已经为它编写了大量扩展 。 大多数有趣的功能都在扩展中，因此本文中将有很多关于扩展的内容。 是的，我不得不指出，有一个特殊的Mediawiki公司版本-BlueSpice ，我没有使用过，因此我无法判断它是否足够。

首先，关于mediaiwki本身的芯片

在讨论扩展之前，值得一提的是MediaWiki本身通常具有什么功能。 如果您在帐户上对Wikipedia进行了数千次修改，则不太可能从此部分中学到任何东西，可以放心地跳过它。

第一类也是最有形的东西- 类别 。 可以将页面添加到类别中，可以将类别本身添加到类别中。 与文件结构（不用符号链接）不同，页面/类别可以一次位于多个类别中。 随着文章数量的增加，类别的使用阻碍了混乱的发展。 特别是如果您定期浏览未分类文章和未分类类别的列表

命名空间 。 维基的意识形态说，一切都是页面（甚至是类别或图像）。 为了分隔不同类型的页面，添加了名称空间的概念。 如果需要，可以添加自己的名称空间来区分不同类型的知识（例如，用于产品信息，实用程序，指南，过程说明和其他服务信息的单独名称空间）。

Wiki还支持模板 -以后可以包含在其他页面中的Wiki页面。 模板支持使用参数，这不仅将参数转化为简单的文本插入：如果需要，您可以使用模板语言编写简单的脚本。 顺便说一句，他们说模板语言可以由Turing完成 。

除了模板之外， Scribunto扩展还允许在Wiki中使用lua模块 。 模块和模板一起使您无需编写扩展即可实现许多功能。

例如， 导航表是基于此二人组构建的。 导航表就是这个东西，通常可以在页面底部看到它：


尽管它们不是标准功能，但它们已将自己确立为导航和恢复订单的便捷方式，现在几乎在任何地方都可以使用。

我不得不提及Mediawiki：Common.css和Mediawiki：Common.js文件，这些文件使您可以对Wiki进行一些自定义-最好将扩展名用于大功能。

编者

Wiki最重要的部分之一就是编辑器。 如果没有可视化编辑器，则实现Wiki非常困难，因为只有非常主动的人才会同意学习Wiki标记。

视觉编辑器

相对较新的扩展-VisualEditor解决了文章可视化编辑的问题。 他有自己的门框，但对于大多数任务，他已经足够了。 在最明显的问题中-没有最方便的图像插入。

可视编辑器的外观与Parsoid的出现密切相关， Parsoid是Mediawiki语法和html之间的转换服务。 由于mediawiki语法是随机开发的，并且没有严格定义，因此该任务极其艰巨。 在官方博客的精彩文章中阅读更多内容。

在与VisualEditor集成的扩展中，您可以选择Graph来编辑图形，选择Math来编辑数学公式，以及SyntaxHighlight来突出显示代码片段的语法。

维基编辑

WikiEditor是一个简单的Wikitext编辑器。 通过Wikitext编辑器可以更方便地完成一些棘手的事情，在某些地方仍不支持可视化编辑。 尽管如此，WikiEditor使得使用Wikitext更加容易，并且自定义它非常简单 。

编辑冲突

过去使用Mediawiki的任何人都记得编辑冲突的每个解决方案是多么痛苦。

默认情况下启用了beta的TwoColConflict大大简化了解决方案。 如果发生冲突，您可以查看发生冲突的地方，并选择所需的有争议片段的版本。 如果两个版本都不完整，则可以补充其中之一。 在业务中看起来像这样：



您可以在测试页上自行尝试。

用于添加相同内容的表格

PageForms扩展允许您使用表单将统一的内容添加到Wiki。 在我的实践中，我使用表单向Wiki添加注册表项，数据库表和其他类似的典型内容。



当使用语义Mediawiki或其类似物时，此扩展揭示了其强大功能。 语义媒体科学允许您将页面属性或具有属性的对象添加到页面。 属性设置如下（例如，德国页面）：

[[ ::]] 

然后可以使用Ask请求或通过api获得这些属性和对象。

从获得的属性中，您可以派生表，构建图并做许多其他很酷的事情 。 例如，在我的情况下，基于通过表单添加的表，构建最简单的数据库模式。 而且，该方案不能针对整个产品，而可以针对特定类别。 并且在图中，除了显而易见的FK / PK链接之外，还可以反映隐式链接，而这些是标准制图工具无法看到的。

对于注册表项，将从相同的属性中提取密钥信息，以便可以将其用于生成具有给定值的.reg文件。

类别树

PageForms支持添加带有类别树的字段的功能，因此只需单击所需的复选框即可将页面添加到所需的类别。

另一方面，当我们已经对文章进行了分类时，它们可以树的形式显示在任何页面上：



该树是动态加载的，因此，如果有人突然需要它们，则可用于大量文章和循环类别。

LDAP / AD授权

Ldap身份验证扩展支持域授权，对某些组的访问限制以及MediaWiki用户组到ldap组的映射。 您可以一次配置多个域。 就设置而言，这很繁琐，但幸运的是，互联网上有很好的说明 。

粒度访问权限

这里一切都不好。 如果任务是限制未经授权的用户访问，那么这很简单。 如果有必要在这些用户之间区分具有特殊访问权限的单独组，那么这将很困难。

有许多不同的扩展名，但是它们不能解决根本的问题：mediawiki并不是作为CMS创建的。 为了支持访问权限，您将必须修补Mediawiki代码，并手动添加

 $title->userCan('read') 

在没有权利验证的情况下不应给予的一切。 所有扩展都一样：对于添加的每个扩展，您都必须手动添加所有必要的检查。

就我自己而言，我以自制的扩展程序解决了该问题，该扩展程序基于PermissionACL的思想以及针对不同扩展程序和mediawiki本身的补丁包。 幸运的是，我不需要高级ACL；可以对几个组进行足够的原始检查。

为了支持图像，您必须将文件访问权包装在Img_auth.php中 。 后者使用了来自mediawiki的文件流，后者不知道如何提供部分内容 （在mediawiki 1.31时），因此，为了支持视频播放，您将必须附加另一个文件流。

视频支持

视频支持不包含在标准软件包中，但通过安装TimedMediaHandler扩展可以轻松解决。 普通的视频播放器，没什么特别的。 将视频插入页面与插入图像完全相同。

搜寻

搜索使Confluence惹恼我的一件事。 标准的Mediawiki搜索更加糟糕，但是幸运的是，存在第三方扩展。 在搜索扩展中，最受欢迎的是CirrusSearch和SphinxSearch 。 我从未使用过后者，但是我很紧密地了解了后者，顺便说一下，它也用在Wikimedia Foundation项目中

CirrusSearch在elasticsearch的基础上工作，要使扩展起作用，您还必须安装一个中间接口-Elastica扩展。

CirrusSearch支持大量参数，并且正在积极开发中。 例如，我很高兴CamelCase搜索从分支1.32开始。

我喜欢的另一点是添加同义词字典的功能。 该词典可以很好地使用公认的内部公司行话，缩写词，典型的错字或各种音译。 但是必须首先编写字典，这可能不是最简单的任务。 如果您不为特定公司精简词典，则可以按照WordNet的精神尝试现有的词典，但事实并非如此，因为它们适合您。

该扩展不支持在LocalSettings 配置级别添加同义词，但这并不难通过编辑扩展代码来解决-请参阅AnalysisConfigBuilder.php和有关为Elasticsearch设置同义词的说明 。

如果需要，您可以通过InputBox扩展名将搜索行添加到主页，然后根据说明将自动完成功能固定到该行 。



顺便说一句， AdvancedSearch将帮助整理搜索页面的外观，它不会像复选框风扇的受害者。

分析工具

当然，这听起来很荒谬，但是即使对于每月有一百个人访问的内部知识库，分析也非常有用。 它使您能够了解用户如何与界面交互，他们正在寻找什么，他们阅读了什么，使用了什么。 如果计划包括进一步发展知识库，那么统计数字将无价之宝。

对于Intranet，有一个非常值得扩展的Matomo （ex Piwik）。 集成的相应扩展是MatomoAnalytics 。



Matomo收集有关搜索查询，点击量来源，下载量，点击率（您可以在页面本身上看到点击率并带有重叠的统计信息）和许多其他指标的统计信息。 既可以参考特定用户也可以匿名收集统计信息，以免混淆任何人。

其他

除了上述内容，还有许多扩展功能可以使生活更轻松。 例如， GuidedTour用于指导初学者使用界面的基础知识， Popups用于在悬停上预览文章， MultimediaViewer用于更舒适地查看全尺寸图像等等。

结果如何？

列出的绅士扩展集涵盖了创建知识库的大部分需求，但并非全部。 Mediawiki不适合作为通用的统一知识库。 但是其他人作为通用系统的表现也很差-共享点，汇合，老式的Outlook文件夹，这需要半小时的搜索时间等。 MediaWiki的背景以其自定义功能和出色的可伸缩性而著称。

与所有这些优点相反，mediawiki不断需要文件切割功能来满足特定公司的需求，因此，其管理员应该有充分的心理准备来理解php，js和lua代码。 但是，如果不感到害怕，并且如果您同意将Office文档的工作与在不同平台上的Wiki文章分开工作，那么将MediaWiki作为知识库可能是一个不错的主意。