Why building a company knowledge base based on mediawiki is a good idea

Recently, Confluence and sharepoint have almost completely ruled the knowledge base market. The systems are excellent, I don’t argue, but I personally don’t have enough flexibility and, in general, I somehow didn’t grow together: the sharepoint wiki-opportunities stayed somewhere at the 2005 level (I’m not talking about working with office documents, all good). Due to their peculiarities, with the growing number of articles, confluence was inexorably turned into a dump in which it was impossible to find anything necessary ( but maybe the problem was in me ).

Without detracting from the dignity of these systems, I would like to talk about the possibilities that Mediawiki has as a corporate knowledge base. Of course, mediawiki is not suitable for everyone - there is no fashionable integration with jira / tfs / etc, transferring documents with pictures from the Microsoft Office package gives a lot of inconvenience, and it itself is written in PHP, which has recently served as a deterrent factor for some IT people . Nevertheless, the platform is more alive than all living things and a fair amount of people are working on its development, since the Wikimedia Foundation's family of projects is based on it.

By itself, the wiki is pretty stingy with the possibilities, but for her there are a lot of extensions written. Most of the interesting functionality lies in the extensions, so that a good part of the article will be about them. And yes, I can not fail to note that there is a special corporate version of Mediawiki - BlueSpice , which I did not use, and therefore I cannot judge its adequacy.

First, about the mediaiwki chips

Before talking about extensions, it is worth mentioning what the general features of mediawiki itself are. If your account has a thousand Wikipedia edits, it’s unlikely that you will learn something new from this part, you can safely skip it.

The first and one of the most tangible buns - categories . Pages can be added to categories, the categories themselves can be added to categories. Unlike the file structure (let's forget about symlinks), a page / category can be in several categories at once. The use of categories prevents the growth of chaos with the increase in the number of articles. Especially if you periodically view lists of uncategorized articles and uncategorized categories

Namespaces Wiki ideology says that everything is a page (even a category or image). In order to separate the pages of different types, the idea of ​​namespaces was added. If desired, you can add your own namespaces to separate knowledge of different types (for example, separate namespaces for product information, utilities, guides, process descriptions, and other proprietary information).

Also, wiki supports templates - wiki pages that can later be included in other pages. Templates support working with parameters, which turns them into something more than simple text inserts: if you wish, you can write a simple script in the template language. By the way, they say that the template language can be Turing complete .

In addition to templates, the Scribunto extension allows the use of lua modules inside the wiki. Modules along with templates allow you to implement many things, even without writing to your extensions.

For example, navigation tables are based on this duet. The navigation table is, for example, this thing, which you can usually see at the bottom of the page:


Although they are not standard functionality, they have proven to be a convenient means of navigation and restoring order and are used now almost everywhere.

I can not fail to mention Mediawiki: Common.css and Mediawiki: Common.js files that allow you to add a little customization to the wiki - for larger things it is better to use extensions.

Editors

One of the most important parts of a wiki is the editor. It is extremely difficult to implement a wiki if it does not have a visual editor, because only a very enterprising person will agree to learn wiki markup.

Visual editor

Relatively fresh extension - VisualEditor solves the problem with visual editing of articles. He has his own shoals, but for most tasks it is enough. Of the most notable problems - there is not the most convenient insertion of images.

The appearance of the visual editor is closely linked with the advent of Parsoid , a conversion service between Mediawiki syntax and html. This task turned out to be extremely nontrivial due to the fact that the mediawiki syntax developed chaotically and was not strictly defined. You can read more in the beautiful post of the official blog .

Among the extensions that integrate with VisualEditor, you can select Graph for editing graphs, Math for editing mathematical formulas, and SyntaxHighlight for highlighting the syntax of code fragments.

Wikieditor

WikiEditor is a simple wikitext editor. Some tricky things are still more convenient to do through the wikitext editor, in some places visual editing is still not supported. Be that as it may, WikiEditor makes it easy to work with wikitext, and it's also quite simple to customize it .

Editing Conflicts

Anyone who used Mediawiki in the past remembers how painful each resolution of editing conflicts became.

TwoColConflict with beta enabled by default greatly simplifies problem solving. In the event of a conflict, you can look at the places where there is a conflict, and select the desired version of the disputed fragment. If both versions are not complete, then you can add one of them. Somehow it looks like this:



You can try it yourself on the test page .

Forms for adding the same type of content

The PageForms extension allows you to add content of the same type to wikis using forms. In my practice, I used forms to add registry keys, database tables, and other similar generic things to the wiki.



This extension reveals its power when using Semantic Mediawiki or its analogs. Media semantic allows you to add page properties or objects with their properties to a page. Properties are set approximately as follows (on the example of the Germany page):

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

These properties and objects can then be obtained using the ask request or via api.

From the properties you can display tables, build graphs and do many other cool things . For example, in my case, on the basis of the tables added through forms, the simplest schemas of the database are built. In this case, the scheme can be built not for the whole product, but for a specific category. In addition to the obvious FK / PK connections, the scheme can also reflect implicit links that cannot be seen by standard charting tools.

For registry keys, key information is pulled out of the same properties so that, based on it, it is possible to generate a .reg file with a specified value.

Category Tree

PageForms supports the ability to add a field with a category tree, so to add a page to the necessary categories, it will be enough just to click on the necessary checkboxes.

On the other hand, when we already have articles categorized, we can display them on any page in the form of a tree:



The tree is loaded dynamically, so that it works for a large number of articles, and for looped categories, if these are suddenly needed by someone.

LDAP / AD authentication

The Ldap Authentication extension supports domain authorization, restriction of access for certain groups, and mapping of mediawiki user groups to ldap groups. You can configure multiple domains. Pretty tedious in terms of configuration, but, fortunately, there are some pretty good instructions on the Internet .

Granular access rights

Here everything is bad. If the task is to restrict access to unauthorized users, then this is easy. If among these users you need to select separate groups with special access rights, then it is difficult.

There are many different extensions, but they do not solve the fundamental problem: mediawiki was not created as a CMS. To support access rights, you will have to patch the Mediawiki code, adding manic

 $title->userCan('read') 

in all that should not be given without checking the rights. The same applies to all extensions: for each added extension, you will have to manually add all the necessary checks.

For myself, I solved the problem with a self-made extension, built on the idea of PermissionACL and packs of patches for different extensions and mediawiki itself. Fortunately, I did not need an advanced ACL, and primitive checks were enough for several groups.

To support the same for images, you will have to wrap the calls to the files in Img_auth.php . And the latter uses a media streamer from mediawiki, which is not able to render partial content (at the time of mediawiki 1.31), so to support video playback, you will have to attach another file streamer.

Video support

Video support is not included in the standard distribution , but is trivially solved by installing the TimedMediaHandler extension. Normal video player, nothing special. Inserting a video on a page is absolutely similar to inserting an image.

Search

One of the things that annoys me personally in Confluence is the search. The standard Mediawiki search is even worse, but fortunately there are third-party extensions. Of the search engine extensions, the most popular ones are CirrusSearch and SphinxSearch . I never used the last one, but I got to know the first one very closely, which, by the way, is also used in projects of the Wikimedia Foundation.

CirrusSearch is based on elasticsearch , for the expansion to work, you will have to install an intermediate interface - the Elastica extension.

CirrusSearch supports an insane number of parameters and is developing quite actively. For example, I was very pleased that in the 1.32 branch I started searching for CamelCase.

Another point that I liked was the ability to add a dictionary of synonyms. The dictionary works well with well-established internal corporate jargon, abbreviations, typical typos or various transliterations. But you need to write the dictionary first, which may not be the easiest task. If you do not sharpen the dictionary for a particular company, you can try existing dictionaries in the spirit of WordNet , but not the fact that they fit you personally.

The extension does not support adding synonyms at the LocalSettings config level, but it is easy to solve by editing the extension code - see AnalysisConfigBuilder.php and the instructions for setting up synonym elasticsearch .

If you wish, you can add a search line to the main page via the InputBox extension, after which you can attach autocompletion to the instructions .



By the way, AdvancedSearch will help put in order the look of the search page, with it it will not look like a victim of a checkbox fan.

Analytics

It sounds ridiculous, of course, but the analyst is extremely useful even for the internal knowledge base, which is visited by a hundred people a month. It allows you to understand how users interact with the interface, what they are looking for, what they read, what they use. If the plans have a further development of the knowledge base, the statistics will be invaluable.

For intranets, there is an extremely decent expansion of Matomo (ex Piwik). The appropriate extension for integration is MatomoAnalytics .



Matomo collects statistics on search queries, traffic sources, downloads, link clicks (you can see the frequency of link clicks superimposed on the page itself) and many other metrics. Statistics can be collected both with reference to specific users and anonymous, so as not to embarrass anyone.

Other

In addition to the above, there are quite a few extensions that simply make life easier. For example, GuidedTour for newbies learning the basics of working with interfaces, Popups for previewing articles on hovering over a link, MultimediaViewer for more comfortably viewing full-size images and much, much more.

What is the result?

The listed gentleman's set of extensions covers a significant part of the need to create a knowledge base, but not all. Mediawiki is not suitable as a universal single knowledge base. But as a universal system, all the others also do poorly - sharepoint, confluence, outlook old school folders, the search for which takes half an hour, etc. Mediawiki on their background is distinguished by its customization capabilities and excellent scalability.

In contrast to all the advantages mentioned above, mediawiki constantly requires that the file be doped out of the functional for the needs of a particular company, so its administrator should be morally ready to understand php, js and lua code. But if it doesn't scare and if you agree to share work with office documents and work with wiki articles across different platforms, mediawiki as a knowledge base can be a pretty good idea.