• includes/installer, mw-config, maintenance/install.php (Manual:install.php), Manual:Installation guide, INSTALL
  • Using maintenance/install.php (todo: test and make sure of the parameters; add some documentation to the file and its Manual entry):
    rm -rf LocalSettings.php database/* && mkdir -p database/ && chmod a+w database/
    php maintenance/install.php [wikiname] [username] --pass=[password] --dbtype=sqlite --dbpath=database/
    note: for now the --scriptpath parameter needs to be explicitly set for this to work out of the box. gerrit:133222 addresses this.
    todo: allow password not to be set in the command line, and get a prompt instead
    todo: fix timezone issue w/ installer.php. In both cases the default time zone of the wiki is not correct (it either is set to UTC or doesn't take DST into account), but in the installer.php-generated wiki trying to edit the main page gets an edit conflict because the new edit uses the actual local timezone and the history uses the server timezone (one hour later, in my case). Both LocalSettings.php are identical, however...
  • See also: MediaWiki-Vagrant
  • https://bitnami.com/stack/mediawiki

Portable mediawikiEdit

There doesn't seem to be an easy way to make mediawiki self-contained. (update: see Manual:Wiki on a stick)

  • I tried using an sqlite database and put it in the root folder of the wiki, but that has problems if you try to version-control the wiki itself, e.g. with git, to track changes to the configuration files, extensions, skins, images, etc. If you try to include the database in the repo, you start getting edit conflicts (??) if you clone the wiki. This seems to be because the cloned database is owned by the user who performs the cloning, so it isn't writable by the apache user (www-data). This allows the wiki to be readable, but not writable. Worse still, if you try to chmod the database so it's writable by all, the wiki stops working. Perhaps another way to tweak the database file's permissions will work better, but essentially this means that it will never be plug-and-play (put it in a php-enabled server and you're done).
  • There's also the issue that a wiki content is typically version-controlled, so tracking the database (which contains all the revisions of the wiki's pages) within git does seem redundant; not to mention the added clumsiness if you want to revert some configuration changes (involving, say, several files and/or directories) without reverting the content of the wiki (i.e., excluding the database file from the revert).
  • Alternatives seem to be TiddlyWiki (with the added benefit of being an entirely client-side app -- but how does it handle large amounts of content? all in a single file doesn't scale...), and git-based wikis like Gollum, Gitit or Olelo/Gitwiki (where the wiki content is stored as a git repo -- I need to check how the config is managed, whether they require a web and database server to work, and whether they can work in a plug-and-play fashion)
  • See also: OrganicDesign.co.nz/MediaWikiLite, phpdesktop ("for developing native desktop GUI applications using web technologies such as PHP, HTML5, JavaScript and SQLite.")

Useful stuffEdit

API + JavaScript (client-side apps)Edit


Languages and internationalizationEdit


  • WikiOverflow (deleted), Wikis@SE (deleted), MediaWiki IdeaTorrent (deleted; thread 1, thread 2). Also, according to my analysis at w:Talk:OSQA, a potential platform for this sort of thing could be w:Askbot.
  • Pitch wysihtml5 (also check for similar stuff?) against VisualEditor and suggest improvements to both
  • It could be interesting to make diffs flattrable. See Extension:Flattr.
  • For code review in gerrit, it would be nice to have a query url that shows only changes that haven't been reviewed before (in the "my changes" view, the CR column is often empty but there's already been a lot of discussion before, but a new patch reset the CR scores). Something like https://gerrit.wikimedia.org/r/#/q/reviewer:self+status:open+-is:reviewed,n,z should work, but according to the docs it covers both Code-Review and Verified scores, and the latter is pretty much always there as it's added by Jenkins, so the query shows nothing. One can build a query to show specifically patchsets with no Code-Review score, but that still doesn't fix the "previous discussion" issue above, which would enable one to find patchsets that haven't received any external feedback since being submitted. As an alternative to find unloved patches, one can amend that search query to show patchsets whithout CR that are over a year old (there are four such ones at the time of writing). Another approach is to limit to those who don't have a +2'er in the reviwers, by using -reviewerin:mediawiki in the query (the docs say reviewerin matches changes that have been, or need to be, reviewed by a user in the specified group).
    • Update: Krinkle on IRC says: the gerrit query command line API over ssh might have a way to filter for such things. Ask hashar or Reedy maybe next time they're on.
  • History of MediaWiki version control (see also MediaWiki history and Git/Conversion). Commits graph @ Ohloh. Commits graph @ GitHub (empty before 2009-11-14 although the graph does go all the way back to 2003-04-13, how come?).
  • It would be nice to remove the site subtitle (by default) from the html page title, as well as use use [] to enclose the site name, e.g. "Foo [Wikipedia]" instead of "Foo - Wikipedia, the free encyclopedia". This would make titles shorter, and would indicate the site name more intuitively. The fact that the square brackets aren't allowed in page titles also helps ensure no ambiguity is present.