6

As a long-time MediaWiki user, I would like to start a new wiki project because I really appreciate MediaWiki maturity and very flexible and powerful capabilities. But I have doubts that I want to take all of MediaWiki infrastructure on board for the new project.

Let's say, I would really like to have a VCS backend to have all wiki edits in one place. As far as I know, MediaWiki supports RBDMS backends only. I've recently came across an old question asked about four years ago. After playing a while with Gitit and Ikiwiki, I feel that Gitit is a better choice allowing integration with GIt or Mercurial, and it's not a static compiler unlike Ikiwiki. Gitit seems to be a much lighter solution than MediaWiki, however I'm afraid it's not even a 10% powerful comparing to MediaWiki: I couldn't compare revisions through the web interface, not sure if I can use categories or templates that are crucial to me, just a few plugins. But I really love the idea of having a VCS backend, because I can sync with the backend locally, can easily export it and use all Git or Mercurial features.

I do remember there is a Git remote helper for MediaWiki that is a bridge-like solution between MediaWiki API over HTTP and Git. I tested it as well, and I had a strong feeling that this Git extension is very raw and seemed to work very slow causing even restart Git cloning in some cases (probably due to the real wiki performance, not sure), and probably might cause another issues. I had never managed to get a full history dump unfortunately.

Is there a way of using Git or Mercurial as a real MediaWiki backend?

EDIT:

I seem to look for an easy Wiki full data replication solution (must have: articles, talk pages, templates, files; optional: probably user database (assuming the VCS stores the user info itself, or maybe something like Mercurial ACL, whatever) and other minor things that aren't tightly related to the wiki content per se) along with an easy to migrate infrastructure.

closed as off-topic by Stephen Ostermiller Jun 20 '15 at 22:05

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking for recommended external websites, tools, resources, and software are off-topic as they tend to attract opinionated answers and spam. Recommendations for software are permitted on Software Recommendations, but be sure to read their quality guidelines before posting there." – Stephen Ostermiller
If this question can be reworded to fit the rules in the help center, please edit the question.

  • @StephanOstermiller This question is not about asking a software recommendation. It's about configuring a concrete CMS to do what I wanted it to do, simply speaking fine-tuning. – Lyubomyr Shaydariv Jun 21 '15 at 13:47
  • I too am not ready to migrate from Mediawiki to Markdown for the sake of it. I see nothing wrong with Mediawiki and have been using it for years. – Sridhar Sarnobat Jun 17 '16 at 20:13
2

I think there isn't (using off-shelf software) for the following reasons.

Sql and git are very different storage systems by design.

Sql is about storing lots of deeply interconnected data in a single big lump of a file. Thus allowing efficient indexing and searching.

Git is about storing programming text in many small files with the unwritten assumption that the content of those files is as independent as possible. Thus allowing easier merging because changes in one file should generally not effect other files (in an ideal world at least).

MediaWiki's design is tightly integrated into using a RDBMS as storage and MySQL in particular. They could have choose any number of other storage systems but they choose this one and that choice likely effects many parts of the system. As mentioned on their wiki, there was a project underway up to about 2 years ago to develop a git backend feature but that appears to have been abandoned.

If the developers don't support it then your only other option is to use something that looks like an SQL server to MediaWiki but is actually a bunch of loose "text" files that can be managed by a (D)VCS such as git.

ODBC connectors exist to support collections of flat files on most if not all platforms but their capabilities may not be complete enough to pose as an sql server. The problem is that MediaWiki is not expecting any 3rd parties to alter it's data tables in any way so accepting a patch to those files from a 3rd party would have to be done in such as way as to not break that internal consistency of the database.

That is certainly possible for some, especially for simple, applications but it is very much application dependent and MediaWiki is fairly complex.

You have the weigh the specific benefits of using one of the available "build for git" style wiki's vs the features they don't have compared to MediaWiki.

  • 1
    Thank you very much for the greatly detailed answer. The idea of mine was rather to avoid the big LAMP stack and make the wiki data(base) migration and replication as easy as possible. The Gitit solution seems to be the most lightweight, but it lacks dozens of features I used to use at my current long-live MediaWiki project. I would love this mediawiki.org/wiki/Git-remote-mediawiki Git extension to work fine, but it has many flaws behind it and I could never make it work nicely. It just would be nice to have an easy synchronization mechanism. – Lyubomyr Shaydariv Jun 18 '15 at 18:16
  • 1
    I'm aware of MediaWiki dumps as well, but I don't have a feeling it's what I really want. Actually speaking, it's not. Well, one of the scenario I have in my head is as follows: someone edits a few pages, and then I can easily pull all changes from the remote server, or I edit a few pages and then just push to publish them letting other users have a web interface if they find it easier. Like a regular software development process. – Lyubomyr Shaydariv Jun 18 '15 at 18:25
  • 1
    I asked this question at the MediaWiki support desk, and they say what you actually said: MediaWiki wasn't designed for it. (BWT, they're also aware of your answer :) ) Unfortunately. From my understanding, MediaWiki has a sort of an overkill of having its own versioning system, and it's tightly bound to RDBMS like MySQL (yep, Git is younger). I wouldn't call it the best choice, but this is what I cannot judge because I'm not a MediaWiki developer. Thus I cancel the further Gitit/MediaWiki+Git investigation, and stay with MediaWiki hoping I'll make it rock with Semantic MediaWiki. Thanks! – Lyubomyr Shaydariv Jun 20 '15 at 20:36
  • 1
    I didn't notice that I've mentioned SMW myself. :D It can't help, sure. I've just discovered it yesterday and still being excited about it. :) Well, I think that putting semantics into a wiki should be a more valuable feature than just data migration/replication that is just a tech maintenance and doesn't really extend wiki capabilities from the user's perspective. Mentioning SMW had to be a side note only not related to the question. – Lyubomyr Shaydariv Jun 21 '15 at 17:32
  • 1
    Here is the question crossposted to the MediaWiki Support Desk: mediawiki.org/w/index.php?title=Thread:Project:Support_desk/… – Lyubomyr Shaydariv Jun 21 '15 at 17:34
2

MediaWiki has a storage abstraction layer that makes this technically possible (the linked page talks about using external databases but it's actually not limited to that; see the documentation of the ExternalStore class for details). You would have to write your own ExternalStoreMedium subclass. The wiki would still have an RDBMS backend, of course, but the page text would be stored in git instead.

In practice, I strongly doubt this would make things simpler for you.

Not the answer you're looking for? Browse other questions tagged or ask your own question.