3 ms·

Can anyone with experience with multiple wiki platforms compare this with XWiki and/or MediaWiki. I may be asked to update $WORK's wiki, which is currently Moi

• jraph 5y ago
  Future XWiki employee (should start in March!). Feel free to reach out to XWiki [1] [2], they'll be happy to answer your question and address your specific needs. They are nice. Feel free to contact me if you'd prefer but I'll be less competent than them for obvious reasons. I don't know many things about XWiki yet, but the main difference between MediaWiki and XWiki is probably the X in XWiki (eXtensible). XWiki is more like a development platform to build a website, a blog, or a collaborative platform (internal or public) that you can tailor to your needs. What you put as contents is highly customizable / scriptable and several Wiki syntaxes are supported. The XWiki syntax can be extended to support your custom features if needed. There are a lot of apps [3] to extend XWiki (some are paid, but open source anyway so you can compile them yourself). LDAP is supported. XWiki will also provide support or specific developments if needed. MediaWiki is developed for Wikipedia first. That's what you can read on XWiki's website anyway. But if you don't need anything that MediaWiki doesn't already provide and like its UX, it can't be a wrong decision to go for it. Many people outside Wikimedia use it and the UX is familiar to everybody, and that's huge. Both tools can be self hosted (and MediaWiki is quite easy to install), MediaWiki is mostly in PHP, XWiki is in Java. XWiki can be hosted for you by XWiki SAS. They'll also help handle migrations from Confluence and are currently handling a lot of them, and I'm sure they will be interested by hearing about migrations from other tools too. I guess WikiMatrix would be a good starting point [4]. XWiki also have comparisons to common collaborative platforms on their websites including MediaWiki. They are obviously biased, but don't lie neither. You might want to check them out. I hadn't encountered Bookstack, before. The UI seems quite clean. I hope we'll have the pleasure to meet and discuss at some point! The UK is not far, we are neighbors. Hmm, neighbours! edit: by the way, you might be interested by XWiki's online presentation at FOSDEM on the 5th of February [5], as well as any other presentation in the collaboration and content management devroom, because not everything collaboration is a wiki :-) [6] [1] https://www.xwiki.org/ https://www.xwiki.org/ [2] https://www.xwiki.com/ https://www.xwiki.com/ [3] https://xwiki.com/en/offerings/products/business-apps https://xwiki.com/en/offerings/products/business-apps [4] https://www.wikimatrix.org/compare/moinmoin+mediawiki+xwiki+bookstack https://www.wikimatrix.org/compare/moinmoin+mediawiki+xwiki+... [5] https://fosdem.org/2022/schedule/event/collabxwiki/ https://fosdem.org/2022/schedule/event/collabxwiki/ [6] https://fosdem.org/2022/schedule/track/collaboration_and_content_management/ https://fosdem.org/2022/schedule/track/collaboration_and_con...
  • zozbot234 5y ago
    There is a "semantic" extension to MediaWiki that makes it easier to support many enterprise use cases with data visualizations, custom queries (potentially referencing information from multiple wiki pages) and the like. It is somewhat widely used for wikis other than Wikipedia, that can simply defer to the Wikidata project for those needs.
    • jraph 5y ago
      I didn't know! Linking for whoever would like to look into this. https://en.wikipedia.org/wiki/Semantic_MediaWiki https://en.wikipedia.org/wiki/Semantic_MediaWiki
    • RheingoldRiver 5y ago
      SMW works okay but if you have technical ability, I'd recommend Cargo (https://www.mediawiki.org/wiki/Extension:Cargo https://www.mediawiki.org/wiki/Extension:Cargo) instead. It's a somewhat limited SQL wrapper (limited - e.g. subqueries aren't supported, which can be annoying on occasion but tbh I've only missed them maybe 3 or 4 times, wiki queries tend not to be too complicated) which is roughly equivalent to SMW in maybe 50% of use cases I've encountered, inferior in maybe 2%, and significantly better in the rest. It definitely has a bit of a higher learning curve than SMW, especially for non-developers, and even for developers there's some kinda weird stuff going on with it (e.g. they have this HOLDS syntax sugar and list-type fields as an answer to SMW's ability to express one-to-many relations a bit more naturally than sql can; also there's this cargo_attach parser function that I forget to do 80% of the time and that's why my tables don't rebuild properly). Anyway if anyone does use MediaWiki and is choosing between these extensions I'm happy to talk to you about them, this is what I do for my job & I have several years experience with both (though my SMW experience is somewhat outdated, since I switched to Cargo several years ago, and only recently have started using SMW again, and that only tangentially).
• KennyBlanken 5y ago
  Mediawiki is page focused, needing a lot of tweaking to make it act like something other than a completely open public page editor. Trying to collect pages is annoying ugly; about the best you can do is with "categories." Mediawiki tries to do too much with document metatags and whatnot. Mediawiki is ugly/outdated looking (IMHO) and requires lots of php config file editing. Bookstack has a lot more inherent document organization stuff (ie: books>chapters>pages etc), it's easy as hell to administer, and it looks gorgeous out of the box.
  • RheingoldRiver 5y ago
    > Trying to collect pages is annoying ugly; about the best you can do is with "categories." With vanilla mediawiki, sure. If you use Cargo or SMW, you can do pretty much anything you want, especially with Cargo. Add in Lua (Scribunto extension) and you have effectively a full extra layer in your stack. (There's also DPL (Dynamic Page List extension) as an option; if what you're doing is easy enough to express, and you're just trying to build lists of pages, you may be able to get away with just doing DPL queries and nothing else beyond that.) It might be more technically complex than you want it to be, but it's definitely not limited to categories.
    • trynewideas 5y ago
      I enjoy Cargo and DPL, they're powerful and great tools for automatically aggregating and filtering content, and I used both of them a lot at a MW that I was an admin on for several years. But it still isn't easy to build an ordered, hierarchical, book-like structure with book-like output, which was a constant request. It wasn't just technically complex (no users wanted to learn how to do it, they wanted one person to do it for them), it also didn't do the one thing most people wanted it to do. The Collection extension did that, though, but Wikimedia's weird behavior around it and their multiple failed attempts at choosing a tech stack for output — OCG/ZIM, PoD/PediaPress, Electron (not that one)/Proton — much less the next step of building that functionality into a usable feature in MW, turned me off from trying. I need to dig into BookStack (I imagine like most wiki flavors, it'll lack the templating features in MW that I rely on), but the fact that it's built on the book/chapter paradigm from the ground up instantly catches my eye.
• dvdkon 5y ago
  I'm currently helping set up a wiki for students of a STEM faculty, and we've settled on MoinMoin (v2, that is). We're broadly building on a previous MediaWiki setup, which we've found to be too "Wikipedia-oriented". I've looked at a few very extensible and featureful wikis (XWiki, Tiki Wiki, TWiki, Foswiki), but for our usecase, they seemed overwhelmingly big (I know, I'm not easy to please). They're all almost application development/scripting platforms, which isn't necessarily a bad thing, but it would mean we'd have to learn a lot more if we wanted to modify parts of them. Of the four mentioned, XWiki looked like the most "polished", its conceptual model and code looked maintainable and it has a great number of actively developed plugins. If I'm not mistaken it even allows writing pages in Markdown, which was one of our criteria. I also looked into taking a very lightweight wiki (LOC in the high thousands) and adapting it to our needs, but found that most of those didn't have a code model that would lend itself well to doing things like swapping out a custom format for Markdown, we'd basically be rewriting half the wiki at that point. Even DokuWiki, a relatively large project, is too blasé about running regexes on page contents for my taste. We looked into BookStack, but didn't think its content model would work too well for our idea of a wiki as a "social" site. Maybe it's just the terminology, though. In the end, we ended up running MoinMoin 2. It's in a perpetual beta state, but it is actively maintained. The main reason was its code quality: It's small enough that understanding how it all fits together is quick, and it's structured so that adding functionality or swapping out one part of it is easy (as much as it could be for software that's over a decade old, anyway). We're programmers anyway, so we decided to go with the ability to change the wiki to our liking over initial polish. So far, I've made a new theme, wrote a script for migrating from MediaWiki, changed out the Markdown parser and added SSO with CAS. The changes aren't public yet, but will be soon. So far I'm happy with our decision, but note that my search was heavily subjective, you very likely have other requirements and preferences. EDIT: By the way, the criteria were loosely: - Modifiability (I wanted a custom theme, needed a non-traditional SSO option and could see us getting ambitious about custom functionality) - Hierarchy + ideally tags for organising - Ability to export some pages into a print version (annually published leaflet/book for new students) - Permission system (which we hopefully won't need to use) - Storing pages in Markdown (helps with converting for print too) - Macros (I'm a fan, easy-to-write extensions would be just fine)
  • 5y ago