Explore key insights and lessons learned from starting with enterprise MediaWiki. This blog offers valuable advice, best practices, and the dos and don'ts for beginners, drawing from firsthand experiences to guide you through your MediaWiki journey.
Last month, I had the opportunity to travel to Austin, Texas, for the Enterprise MediaWiki Conference Spring 2023 (EMWCon). There, I gave a presentation providing an introduction to "Enterprise MediaWiki", the field in which WikiTeq specializes. Below, the presentation is reproduced based on my notes. You can also find a video of the actual presentation at the bottom.
My first impression of the MediaWiki software came from a story that my parents told me. A family friend was running the Boston marathon in 2013, the year of the Boston marathon bombing. While thankfully they were not injured by the bomb, they were forced to stop running. As a result, this family friend was unable to complete the race, but they came close – agonizingly close. So, what did their friends do? Edit the [[Marathon]] Wikipedia article to change the official race distance so that the friend had indeed finished the race.
Obviously, this was considered vandalism, and the change was reverted. IP editors reinstated it, and it went back and forth until an admin stepped in and protected the page from editing:
Until then, I’m sure I had seen the "anybody can edit" slogan, but I had never internalized that "anybody" included me or people that I knew. Nor did I realize that it wasn’t just a display of (editable) content – pages could be protected from editing, meaning that not all editors are created equal.
At some point, probably in high school, I began to be more curious about how Wikipedia worked. And what I found was that almost everything was done publicly, not just the wiki and its changes, but also the technical functionality and all of the MediaWiki software, which was open source. I became a lurker on Phabricator (the bug tracker used by MediaWiki), Gerrit (where the MediaWiki code lives), wikitech-l (a developer mailing list), and a few other places, just wanting and seeing how changes were implemented. I also idled in a few IRC channels related to MediaWiki and Wikipedia. To be clear, I was editing anonymously because that is one of the great things about both Wikipedia and MediaWiki – it doesn’t matter who you are in real life, just what you do. People are judged on the content of their edits or code patches.
At the start of this year, I got my first introduction to "Enterprise MediaWiki" when I was hired as a "Technical Project Manager" at WikiTeq. I had initially assumed that "Enterprise MediaWiki" was just MediaWiki for use in business, but I have since found that it includes a whole lot more, and that is what I want to share with you today:
A shared understanding of what words mean is necessary to be able to use them effectively. Accordingly:
Enterprise MediaWiki, as I understand it, provides hosting, development, maintenance, a help desk, and anything else MediaWiki-related that the clients want, and that we (WikiTeq or other businesses) can provide.
Observing the conversations on Phabricator and the modifications in code on Gerrit provided me with insights on what to anticipate. Although the English Wikipedia and other Wikimedia Foundation wikis typically receive updates weekly, the majority of wikis adhere to the stable versions of MediaWiki released every six months. Some opt exclusively for the "long term support" editions that are published every few years.
Furthermore, while MediaWiki core will continue to work out-of-the-box in each new version, extensions also need to be updated to be usable on newer versions of MediaWiki, and those extension updates can be problematic. For example, I spent a while updating the Semantic Watchlist extension to work in MediaWiki 1.39 (and with Semantic MediaWiki version 4), and there were more than a few pain points. For one thing, sometimes things are removed entirely from MediaWiki core. For functions that are removed, PHP provides helpful errors, but for "hooks" (one of the biggest ways for extensions to interact with the core software), there is no error when a hook is removed, it simply never runs, leaving the extension code unreachable. There has been some discussion to address this, see https://phabricator.wikimedia.org/T261091.
The various Wikimedia Foundation wikis generally "look" the same. The English Wikipedia, German Wikibooks, and French Wikiversity all have the same default skin (Vector), a similar bundle of extensions installed, and otherwise look recognizable. Even Wikidata, which is designed around structured data rather than wikitext articles, looks similar. Part of the reason for this is that new extensions must go through a series of steps, including a security review, before being enabled.
For example, an extension currently in the process of being deployed to the Wikimedia Foundation wikis is the RealMe extension, which would allow editors to include rel="me" links (details) to their user pages via a new preference. Prior to deploying this extension, the WMF security team conducted a detailed review, and a performance review has also been requested.
On the other hand, one of the extensions that WikiTeq customers commonly use is the Widgets extension, which allows embedding arbitrary HTML, CSS, and JavaScript within wiki pages. Since the goal of the extension is to include arbitrary HTML, it would likely never pass a security review to be deployed on WMF wikis.
Furthermore, two sets of extensions, SemanticMediaWiki and BlueSpice, are commonly used by enterprise MediaWiki clients – neither of these is available on WMF wikis.
Another way that WikiTeq clients (and wikis in general) can differ is in their appearance and default skin. Below are two screenshots of the main page of a MediaWiki wiki using the site’s default skin and styles – unlike the various WMF wikis, there is almost no similarity between the two.
On the English Wikipedia, there is a clear distinction between developer requests and what is the domain of on-wiki help pages and forums. The things that get to Phabricator are requests for features from developers, bug reports about the software itself, etc. – things that are generally not resolvable with on-wiki changes.
At WikiTeq, on the other hand, we serve not only to provide hosting, maintenance, development, etc., but also serve as a help desk. I got approval to share a few (anonymized) examples of some of these requests:
iframe elements. We helped them use the Widgets extension to provide an easy wrapper for this tag, and sent them documentation on how to use it to add additional iframe elements in the future.Don’t get me wrong, I love my job and enjoy learning about all of these new technologies, extensions, and workflows. But it is not exactly what I was expecting when I got hired. From what I have gathered, "Enterprise MediaWiki" essentially means "MediaWiki-focused Enterprise", changing to match what each client wants, from hosting, to extension development, to on-wiki changes and features.
Here’s what we've been up to recently.
Knowledge management is the art and science of turning organizational know-how into a valuable, shared resource. It ensures that insights don’t remain locked in individual minds or scattered files, but instead become accessible, reusable, and continuously improved. As a result, teams can make better decisions, solve problems faster, and drive sustainable innovation.
Struggling with knowledge management in your organization? Our latest blog, Overcoming Knowledge Management Challenges: Strategies for Success, is here to help! From breaking down silos to ensuring up-to-date, accessible information, we explore common hurdles and provide actionable strategies to enhance your KM practices. Discover how you can foster a knowledge-sharing culture, improve accessibility, and measure the impact of KM initiatives to drive organizational success.
Get our latest blogs and news delivered straight to your inbox.
We use cookies to provide and improve our services. By using our site, you consent to cookies.
Learn more