カテゴリー: MediaWiki

MediaWikiでショートURLを使う

最終更新：2016/09/06

MediaWikiを運用するようになってからかなり経つけど、記事のURLは初期設定のままで、

http://vanguardflight.xii.jp/w/index.php?title=Page_title

といったように表示されていた。編集するユーザーも管理者も一人しかいない無名のマイナーウィキだから、それでも別に困ってなくて先延ばしになってたんだけど、どうせならウィキペディア日本語版のようなショートURLにしたい。

例によって、MediaWiki公式サイトの説明はわかりにくい。大抵のWebサーバーで使われているApacheを実装していて、mod_rewriteというモジュールを利用可能であれば、MediaWikiが動いているほとんどすべてのサーバーでショートURLを利用できると書いてある。

一方で、rootの権限がどうのこうのと書いてあるので、ローカルホストにアクセスする権限がないと無理なのかと思って真面目に調べてなかった。ところが、よく読むとリモートサーバーでも利用可能と書いてあるし、更には、「そのくらいのことができないようなリモートサーバーにお金を払う価値はない」とまで書いてあってかなり強気。

さくらインターネット公式サポートサイトによると、Apacheを実装しているし、mod_rewriteも利用可能と書いてある。mod_rewriteそのものの設定を変更するにはサーバー管理者の権限がないといけないんだけど、共有サーバーを使っているユーザー側でも.htaccessで設定できる。

.htaccess

.htaccessを配置すべき場所は、MediaWikiのディレクトリが存在しているディレクトリ。つまり、home/[user-name]/www/wというディレクトリにMediaWikiをインストールしているとしたら、home/[user-name]/wwwに.htaccessを置けばいい。

.htaccessに記述すべき内容はわずか2行。

RewriteEngine On
RewriteRule ^/?wiki(/.*)?$ %{DOCUMENT_ROOT}/w/index.php [L]

1行目のRewriteEngine Onは、mod_rewriteを有効にする設定。

2行目は、URLをどのようにリライトするかというルール。正規表現で記述されているのでちょっとわかりにくい。簡単に言うと、http://example.domain.com/wiki/Page_titleというURLを受け取ったら、それを内部的にはhttp://example.domain.com/w/index.php?title=Page_titleに置き換えながら、ブラウザのアドレスバーにはhttp://example.domain.com/wiki/Page_titleが表示され続けるということ。

最後の[L]は「ここで.htaccessは終わり」という意味。

LocalSettings.php

$wgScriptPath = "/w";
$wgArticlePath = "/wiki/$1";
$wgScriptExtension = ".php";

初期設定では$wgScriptPathと$wgScriptExtensionしかないんだけど、その間に$wgArticlePathという環境変数を追加する。

補足

なお、独自ドメインを使用している場合でもショートURLを利用できる。独自ドメインが/wwwディレクトリの更に下の階層に設定してあって、例えばhome/[user-name]/www/directory/wにMediaWikiをインストールしてあっても問題ない。

また、独自ドメインの直下（上の例で言うと、home/[user-name]/www/directory）にindex.htmlやindex.phpで始まるような普通のウェブサイトを配置していて、そこに上記の.htaccessを設置してもそのウェブサイトは何の問題もなく表示される。同様に、独自ドメインに/wpといったディレクトリを作って本記事のブログのようなWordPressを設置してMediaWikiと並列で運用していても問題ない。

唯一ダメなのは、/wikiというディレクトリが実際に存在している場合。MediaWiki公式サイトのインストール・ガイドにも「wikiというディレクトリ名だけはやめたほうがいい」と書いてある。もし、そこにMediaWikiをインストールしてしまった場合でショートURLを使いたい場合は別のディレクトリに移動させないとならない。

参考記事

MediaWikiの見出しをサンセリフ・フォントに戻す

最終更新：2016/09/06

最近のトピックではないんだけど、2014年4月頃にリリースされたMediaWiki 1.22.5以降からCSSが見直され、記事見出し（見出しレベル1）と見出しレベル2のフォントがサンセリフ・フォント（ゴシック体）からセリフ・フォント（明朝体）に一律に変更された。

MediaWiki公式サイトではTypography refreshという記事でどういった経緯や理由でフォントを変更することになったのか説明されている。元に戻す方策を示してくれているわけではないので、無理して全部読む必要はまったくなく、要は「とにかく見出しをセリフ・フォントに変えたよ」ということを伝える記事に過ぎない。

ラテン文字を主に使用する英語圏の人にとってはある程度説得力のある話なんだろうけど、日本語のように全角文字と半角文字を混ぜて書くことがある言語では問題になることがある。また、元は海外製のInternet Explorerをはじめとするブラウザに潜在的な不具合があって、日本語では通常使われない文字が表示されたりする問題などがウィキペディア日本語版のプロジェクトで指摘された。ラテン文字を主流とする他言語の人から見たら判別不能な『漢字』という特殊な文字を使っている日本語と韓国語（朝鮮語）と中国語がごっちゃになってしまっていることが原因のようだ。詳しいことは当該議事録を参照（長文）。

色々な修正方法が検討されたんだけど、もっともシンプルな解決方法は次のようなCSSをMediaWiki:Vector.cssに追加する。Vectorスキンを標準の外装にしていない場合は、更に上位のMediaWiki:Common.cssか対応するスキンのCSSを適宜変更する。

div#content h1, div#content h2, div#content #firstHeading {
 font-family: sans-serif;
}
html, body {
 font-family: sans-serif;
}
div#content .mw-editsection {
 font-family: sans-serif;
}

ひとまず、これで標準記事名前空間と付随する名前空間の見出しはサンセリフ・フォントに戻せる。

ただ、この方法でもログインや個人設定のページといった特別ページの一部はセリフ・フォントのままになってしまう。ブラウザの要素解析機能を使ってセレクタやクラスを丹念に調べれば対処可能なんだろうけど、もっとも重要な標準記事名前空間の記事名に問題が出なければよしとして、これ以上深入りはしないことにした。

［2016年3月12日追記］

深入りしないことには決めたが、やはり気にはなるので、要素解析をやってみた。標準記事名前空間（付随する名前空間含む）と個人設定の特別ページの見出しのクラスとセレクタは同じだった。

div#content.mw-body h1#firstHeading.firstHeading

同じならばMediaWiki:Vector.cssに記述したCSSが反映されてもよさそうなものだけど、個人設定の特別ページのレベル1（h1）とレベル2（h2）の見出しに最後に適用されているスタイルは次のようなもの。これが問題になっている。

.mw-body h1,.mw-body h2 {
	font-family:"Linux Libertine",Georgia,Times,serif;
	line-height:1.3;
	margin-bottom:0.25em;
	padding:0
}

確かに、これなら見出しがセリフ・フォントになってしまう。実際、ブラウザの要素解析機能を使って font-family のプロパティを一時的に解除してみるとサンセリフ・フォントに戻る。

標準記事名前空間の見出しでも同様のスタイルが設定されているんだけど、MediaWiki:Vector.cssにサンセリフ・フォントに戻すプロパティを設定してあるので、それが読み込まれて強制的に上書きされている。ところが、個人設定の特別ページではユーザー設定のMediaWiki:Vector.cssをStyleSheetとして読み込んでいるコードが見当たらない。どのスタイルシートを呼び出して適用するか決定しているのはMediaWiki本体だから、いくらMediaWiki:Vector.cssを変更しても画面の表示に反映されないのは当たり前ということになる。

どうも、問題のスタイルはどこかのファイルにまとめて記述してあるものではなく、MediaWikiがその都度「load.php」という名前のスクリプトに引数を渡してリソース・ローダー（ResourceLoader）と呼ばれるモジュールが自動的に生成するものらしい。PHPやJavaScriptのソースコードもひととおり検索してみたけど、該当する箇所が見つからなかった。リソース・ローダーの説明もざっと読んでみたけど、確かに凄い機能を持ったモジュールなのはわかる。凄いけど、高度すぎてまったく手に負える感じがしない。仮に、どこかを改変して問題を解決できたとしても、MediaWikiがアップグレードされた時に上書きされてしまうので書き戻す手間が発生するし、最悪、誤動作して本当に手に負えなくなってしまう可能性さえある。よっぽどのことがない限りMediaWikiの本体には手を着けたくないので、個人設定の特別ページの見出しについては諦める他にない。

MediaWikiのWikiEditorを設定する

最終更新：2016/09/06

Extension:WikiEditorは記事を編集するために必要なツール群をGUIで選択できるようにしたMediaWikiの拡張機能。MediaWiki公式サイトの原文では Enhanced Editing Toolbar と書かれていて、日本語では「改良型編集ツールバー」と呼ばれている。開発中に使われていたであろう仮名の betatoolbar という用語がしばしば環境変数名で出てくる。MediaWiki 1.18以降は標準でバンドルされていて、特に意識しなくても自動的にインストールされている。

機能そのものは存在していても、デフォルトでは有効になっていないので、初期設定では次の画像のようなちょっとしたツールバーしか表示されない。かなり前からウィキペディアを編集したことがある人にとっては懐かしいかもしれない。

WikiEditor000

改良型編集ツールバーを有効にするには、個人設定（Preferences）で個別に設定するか、LocalSettings.php ですべてのユーザーが一律に有効になるように設定する。

require_once "$IP/extensions/WikiEditor/WikiEditor.php";
# Enables use of WikiEditor by default but still allows users to disable it in preferences
$wgDefaultUserOptions['usebetatoolbar'] = 1;

# Enables link and table wizards by default but still allows users to disable them in preferences
$wgDefaultUserOptions['usebetatoolbar-cgd'] = 1;

# Displays the Preview and Changes tabs
$wgDefaultUserOptions['wikieditor-preview'] = 1;

# Displays the Publish and Cancel buttons on the top right side
$wgDefaultUserOptions['wikieditor-publish'] = 1;

3行目は、改良型編集ツールバーを有効にする設定。編集画面の上に次の画像のようなツールバーが表示される。頻繁に使うマークアップの入力を補助してくれる他、各言語に特有の文字を挿入できたり、マークアップの記述方法を忘れた時のためのヘルプを参照できたりする。wikitable のクラスを持った表を一発で挿入してくれるのは便利。個人設定の編集タブにある「改良型編集ツールバーを有効にする」をチェックしても同様の結果を得られる。

WikiEditor001

6行目は、内部リンクと外部リンクおよび表の挿入、検索と置換に関するウィザードを有効にする設定。個人設定の編集タブにある「リンクや表の挿入、および検索と置換のためのウィザードを有効にする」をチェックしても同様の結果を得られる。

なお、無効に設定すると、次の画像のように改良型編集ツールバーのアイコンが若干変わる。リンクのツールが外部リンク用のものと内部リンク用のものに分かれ、検索と置換アイコンがなくなる。

9行目は、プレビューと差分をページをリロードすることなく見られる機能を追加する設定。比較プレビュー（side-by-side preview）という名前がつけられている。改良型編集ツールバーを有効にしていれば、その上に更に次の画像のように「ウィキテキスト」「プレビュー」「差分」というタブが追加される。個人設定の編集タブにある「比較プレビューを有効にする」をチェックしても同様の結果を得られる。

WikiEditor002

なお、ウィキペディア日本語版ではプロジェクトの方針として必ず1回は従前のプレビュー機能を使って自分の編集に間違いがないか確認することを推奨しているため、この機能が使えないように設定されている。

12行目は、次の画像のように、改良型編集ツールバーに「投稿」ボタンと「中止」ボタンを追加する設定。個人設定の編集タブにある「段階的投稿を有効にする」をチェックしても同様の結果を得られる。

WikiEditor003

『段階的投稿（step-by-step publishing）』の意味がよくわからないんだけど、投稿ボタンは基本的にテキスト・ボックスの下にあるものだけで十分だと思うので、使いどころはあまりないかもしれない。

上の比較プレビューと同様に、ウィキペディア日本語版では拙速な編集を防ぐ目的で最低1回はプレビューを実行してからでないと投稿できないようになっているため、この機能は使用できないように設定されている。

関連記事

MediaWikiに編集支援ツールを追加する

最終更新：2016/09/06

ウィキペディア日本語版を編集していると、テキスト・ボックスの下に次の画像のような編集支援ツールが表示される。

Edittools000

MediaWiki用のマークアップや記号などが並んでいて、それらをクリックするとマークアップを半自動で入力してくれる他に括弧の間にカーソルを移動してくれたりもする、なかなかの優れもの。マークアップしたい語句を先に選択してからクリックしてもちゃんと括弧の中に入れてくれる。ウィキペディアを何度も編集したことがあって、ウィキ文法のマークアップを覚えている場合はなくてもそれほど困らないけど、手動で入力するには少々面倒なマークアップもあるので、あればあったで結構便利。でも、インストールしたばかりのMediaWikiにはこの機能は実装されていない。

この編集支援ツールを利用するには、CharInsertというエクステンションと、MediaWiki:Edittoolsというシステム・メッセージが必要になる。

Extension:CharInsertの実装

Extension:CharInsertのスナップショット（現時点で安定動作する最新版）をMediaWiki公式サイトからダウンロードし、適当なローカル・フォルダに解凍する。/extensionディレクトリに/CharInsertディレクトリを作成し、そこへFTPクライアントでアップロードする。

一応、MediaWikiのバージョンに合わせてスナップショットを選ぶようになってはいるんだけど、このエクステンションについてはメンテナンスをした覚えがない。MediaWiki 1.24が最新だったくらいのかなり古いバージョンを使っているけど、MediaWiki 1.26.2の時点で特に問題は起きてない。

LocalSettings.phpに次の1行を追加する。MediaWiki 1.25以降の場合は別の記述方法もあるみたいだけど、この記述でもちゃんと動作する。以前からMediaWikiを運用している人にとってはこちらのほうが馴染みのある書き方かも。なお、MediaWiki 1.26.2で動作確認済み。

require_once "$IP/extensions/CharInsert/CharInsert.php";

MediaWiki:Edittools

Extension:CharInsertは、MediaWiki:Edittoolsを参照するように設計されているので、自分のウィキにMediaWiki:Edittoolsという名前のページを追加する。内容は、ウィキペディア日本語版のMediaWiki:Edittoolsのソースを表示させて、まるごとコピー&ペーストする。まずはこれで試験運用してみるといい。

ちなみに、MediaWiki公式サイトのMediaWiki:Edittoolsは非常に凝っていて、ドロップ・ダウン・リストから言語を選んで各言語に特有の記号を選べるようになっているんだけど、システム・メッセージとは別にウィキ上で動作するJavaScriptのページを用意しなければならないなど実装が結構大変なので、マークアップの記述を省力化できれば十分だと思う。

小技として、次の1行をMediaWiki:Edittoolsのどこかに追加しておくと便利。自分のウィキで説明するまでもない基本的な事柄の説明をしてくれているウィキペディア日本語版の記事に転送する。

<span style="margin-left:1ex;white-space:nowrap"><charinsert>[[Wikipedia:ja:+|]]</charinsert></span>

「ウィキペディアというプロジェクトの、日本語版の記事へ」という意味のマークアップで、クリックすると縦線の前にカーソルを移動するか、選択した語句をマークアップするようになっている。記事名を記述すると、パイプが効いてWikipedia:ja:という部分は表示されない。長々とした外部参照URLを記述しなくても済むのでマークアップもすっきりして見やすくなる。

関連記事

MediaWikiをアップグレードしたら画像が表示されなくなった問題

最終更新：2016/09/06

今までMediaWiki 1.24を使っていたんだけど、ふと何気なく自分のウィキを見てみたら、ウィキメディア・コモンズから呼び出している画像が表示されなくなっていた。MediaWikiの公式サイトを調べてみたら、InstantCommonsという機能に変更があって、HTTPS接続じゃないとコモンズから画像を引っ張ってこれなくなったそうだ。比較的最近のバージョンじゃないとダメみたいなので、最初は何の気なしに気軽にアップグレードを始めてみた。

この記事を書いている時点の最新版はMediaWiki 1.26.2だったので、いつものようにアップグレードをしてみたんだけど、今度はコモンズの画像だけじゃなくて、ローカルに保存されているはずの画像も呼び出せなくなってしまった。画像をクリックして直接表示させようとしても、Internal Server Errorが出てしまって表示できない。

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, support@sakura.ad.jp and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.

慌ててしまった私は、1.24に戻すことを考えたんだけど、これがまた非常に面倒で、MediaWikiのソフトウェアはともかく、データベースを復元できない。最新版ではデータベース内のテーブルから削除されてしまったフィールドもあったりして、さくらのレンタルサーバーの管理ツール（phpMyAdmin）を使ってもバックアップ・ファイルからインポートされている気配もない。

そもそもXML形式でバックアップしていたのがいけなかった。XML形式でのデータベースの復元は最新のMySQL 5.6でようやく実装されたものらしく、MySQL 5.5を指定している私のデータベースではそもそも無理という結論になった。一晩かかってもデータベースを復元できなかったので、その方向は諦めた。

そこで、ひとまず1.26にアップグレードはして、画像が出ない状態に戻した。そのうえで調べてみると、どうもMediaWikiのバグ・フィクスの影響で、MediaWikiの画像を保存しておく/imagesディレクトリの.htaccessに問題があるらしいことがわかった。さくらのレンタルサーバー非公式FAQによると、Optionsが使えない設定になっているそうだ。

MediaWiki 1.26.2 の .htaccess

# Protect against bug 28235
<IfModule rewrite_module>
	RewriteEngine On
	RewriteCond %{QUERY_STRING} \.[^\\/:*?\x22<>|%]+(#|\?|$) [nocase]
	RewriteRule . - [forbidden]
	# Fix for bug T64289
	Options +FollowSymLinks
</IfModule>

MediaWiki 1.24.2 の .htaccess

# Protect against bug 28235
<IfModule rewrite_module>
	RewriteEngine On
	RewriteCond %{QUERY_STRING} \.[^\\/:*?\x22<>|%]+(#|\?|$) [nocase]
	RewriteRule . - [forbidden]
</IfModule>

Options +FollowSymLinksという部分を#でコメントアウトして、/imagesディレクトリに保存する。

自分のウィキをリフレッシュしてリロード（Ctrl+F5）してみたら、無事に画像が表示された。ウィキメディア・コモンズの画像も表示されるようになっていた。おそらく、内部的にはローカルの画像を探す振りをしながらウィキメディア・コモンズにアクセスしにいっていて、ローカルの設定に影響を受けてしまってるのではないかと推測。

これ以降、アップグレードする度に同じ問題が起こることが考えられるので、備忘録を残しておくことにした。とにかく、MediaWikiをアップグレードして何か問題が起こっても、ダウングレードは最終手段と考え、慌てず騒がず同じ問題に行き当たった人が書いた記事がないか探してみるべきだと痛感した。

関連記事

参考記事

MediaWikiのキャッシュを有効にする

最終更新：2016/09/06

MediaWikiをインストールしてから結構経ったけど、キャッシュを有効にしてなかったことに今更気がついた。ページひとつ更新するにも結構待つし、ファイルをまとめて10個くらいアップロードするとなるとかなりの時間になる。

そこで、多少なりともレスポンスが速くなればいいなぁ、と思い、サーバー側のキャッシュを有効にしてみることにした。MediaWiki公式サイトの説明をざっくり読んでみてからネットを検索したらいくつか記事が見つかった。

具体的には、LocalSettings.phpの次の設定を追加又は変更する。

$wgMainCacheType = CACHE_ANYTHING; /* default: CACHE_NONE; */
$wgUseFileCache = true;
$wgCacheDirectory = "$IP/cache";
$wgShowIPinHeader = false;
$wgEnableSidebarCache = true;

この記事を書いている時点で最新バージョンのMediaWiki 1.24.2では、$wgUseFileCacheを true にすると、$wgShowIPinHeaderは自動的に false になるので設定する必要はないんだけど、念のため。

$wgCacheDirectoryは特別な理由がない限り、"$IP/cache"でいいと思う。英語用のキャッシュが約620KB、日本語用のキャッシュが約708KBくらい生成されてたけど、思ったよりは大きくはなかった。しばらく運用してみてどのくらいになるのか観察することにする。

試しに、いくつかファイルをアップロードしてみたけど、目に見えてレスポンスが良くなった。日本語版ウィキペディアの記事を更新するくらいのレスポンスにはなったように思う。ベンチマークで厳密に計って比較したわけではないけど、体感的に速くなったと感じられれば目的は達成。こんなことなら、もっと早くキャッシュを有効にしておくべきだった。

参考記事

MediaWikiのアップグレード手順

最終更新：2016/09/06

いつの間にか、MediaWikiが1.23にアップデートされていた。1.22でもとりあえず困ってはいないんだけど、セキュリティの問題もあるし、いざという時にメンテナンスできないと困るので、練習のつもりでアップグレードに挑戦してみることにした。

MediaWikiの公式サイトにもアップグレード・マニュアルはあるんだけど、あらゆるバージョンや環境のことを網羅しようとした書き方になっているので、わかりやすいとは言えない。

さくらのレンタルサーバにMediaWikiをインストールしているという前提で、ざっとまとめてみた。おおまかに言うと、手順は次のとおり。

  1. 現在のデータベースのバックアップ
  2. 現在のMediaWikiのバックアップ
  3. 新しいMediaWikiのダウンロード
  4. 新しいMediaWikiの展開
  5. 新しいMediaWikiを現在のMediaWikiに上書き
  6. データベースを新しいMediaWikiに適合させる

具体的なコマンドは次のような感じ。SSHにログインを参考にSSHシェルにログインして実行する。

mysqldump -h [host-name] -u [user-name] --password=[your-pass] --xml [dbname] > backup.xml
cd www
tar cvzf mediawiki.backup.tar.gz [wiki-directory]
wget http://download.wikimedia.org/mediawiki/1.23/mediawiki-1.23.1.tar.gz
tar xvzf mediawiki-1.23.1.tar.gz
cp -a mediawiki-1.23.1/* /home/[user-name]/www/[wiki-directory]/.
cd [wiki-directory]/maintenance
php update.php

［2016年2月13日追記］

MediaWikiのダウンロードの方法が変わって、HTTPS接続でないとデータを取得できなくなった。また、普通にダウンロードしようとすると証明書関連の問題でアクセスを拒否されることがあるので、--no-check-certificateオプションを追加した（チェックを省略するので、自己責任で！）。また、XML形式でのバックアップはSQLデータベースサーバーに書き戻す時に問題が多々発生することがわかったので、SQL形式でバックアップするように少し見直した。

mysqldump -h [host-name] -u [user-name] --password=[your-pass] [dbname] > backup.sql
cd www
tar cvzf mediawiki.backup.tar.gz [wiki-directory]
wget https://releases.wikimedia.org/mediawiki/1.26/mediawiki-1.26.2.tar.gz --no-check-certificate
tar xvzf mediawiki-1.26.2.tar.gz
cp -a mediawiki-1.26.2/* /home/[user-name]/www/[wiki-directory]/.
cd [wiki-directory]/maintenance
php update.php

［2016年3月13日追記］

更にバックアップまわりを見直し。mysqldumpに--default-character-setと--hex-blobの各オプションを追加した。

--hex-blobオプションは、バイナリカラムを16進数表記でダンプする。例えば、'abc'という文字列のバイナリは0x616263という文字列に変換される。ファイルサイズは大きくなるけど、特殊な文字を使っている場合のデータの欠落を防止することができる。

SQL形式のバックアップ・ファイルからデータベースにインポートできれば、元の状態を完全に復元できる。ただし、MySQLのバージョンが違っていたり、MediaWikiのバージョンが違っていてデータベース構造が変わっていたりすると復元できない可能性が高い。サーバーの引っ越しのためというより、同一サーバー、同一MySQL、同一MediaWikiにおける原状復帰のためのバックアップ・ファイルと割り切ったほうがいい。

念のため、MediaWikiのメンテナンス・スクリプトであるdumpBackup.phpを使用して全記事の全部の版をXML形式でダンプしておくコマンドを追加した。--fullオプションが全名前空間の全記事の全部の版を指定している。

このダンプでバックアップできるのは各種名前空間を与えられた文字だけのページだけで、画像などのメディア・ファイルはバックアップされない。また、データベース全体を復元させることはできないので、rebuildrecentchanges.phpといった別のメンテナンス・スクリプトを実行してテーブルに反映させる必要がある。手間はかかるが、MediaWikiのバージョンが変わっていても復元できる可能性が高いという利点がある。

mysqldump -h [host-name] -u [user-name] --password=[your-pass] --default-character-set=binary --hex-blob [dbname] > backup.sql
cd www/[wiki-directory]
php maintenance/dumpBackup.php --full > backup.xml
cd ..
tar cvzf mediawiki.backup.tar.gz [wiki-directory]
wget https://releases.wikimedia.org/mediawiki/1.26/mediawiki-1.26.2.tar.gz --no-check-certificate
tar xvzf mediawiki-1.26.2.tar.gz
cp -a mediawiki-1.26.2/* /home/[user-name]/www/[wiki-directory]/.
cd [wiki-directory]/maintenance
php update.php

dumpBackup.phpでダンプしたバックアップは、importDump.phpというメンテナンス・スクリプトで書き戻すことができる。--dry-runオプションをつけることで、XMLの解析だけして実際にはデータベースには反映せず、MediaWikiで受け付けられるバックアップ・ファイルかどうかをテストすることができる。

cd www/[wiki-directory]
php maintenance/importDump.php --dry-run < dumpBackup.xml

実行すると、次のようにメッセージが表示される。

100 (131.18 pages/sec 207.26 revs/sec)
200 (219.45 pages/sec 283.09 revs/sec)
300 (229.85 pages/sec 286.54 revs/sec)
400 (279.63 pages/sec 334.86 revs/sec)
Done!
You might want to run rebuildrecentchanges.php to regenerate RecentChanges

参考記事

iPad/iPhoneでMediaWikiのロゴが英語版ウィキペディアになってしまう問題

最終更新：2016/09/06

ある時から、自分のウィキをiPadやiPhoneで表示しようとすると、MediaWikiのロゴがオリジナルのものから英語版ウィキペディアのものに変わってしまって、不思議に思っていた。PCで表示する分にはどのブラウザでも正常に表示される。しかも、iOSに標準でインストールされているSafariだけではなく、Chromeでも同じ問題が起こる。PC版のブラウザと違って要素解析ができないので、しばらく原因がわからず問題を放置していた。ところが、MediaWikiのサポートデスクの該当スレッドを注意深く読んでみると、最後のほうに#p-logoというidセレクタをもう一度確認してみよう、という一文があった。

当初は「iOSのバージョンが古いんじゃない？」とか「単純にキャッシュの問題じゃないの？」といった回答が多かったので、そういうものなんだろうかと思って最後まで読んでなかった。

原因は、ウィキペディア風の外観にするためのMediaWiki:Common.cssをコピーして移設したことにあった。最後のほうに、モバイル端末向けの表示用に次のようなCSSが記述されている。確かに、英語版ウィキペディアのロゴ・ファイルをダイレクトで呼び出しているので、iPadやiPhoneでロゴが変わってしまうのは当然だった。

/* [[MediaZilla:35337]] */
@media (-webkit-min-device-pixel-ratio: 1.5), (min--moz-device-pixel-ratio: 1.5), (min-resolution: 1.5dppx) {
        #p-logo a {
                background-image: url("//upload.wikimedia.org/wikipedia/commons/thumb/b/b3/Wikipedia-logo-v2-en.svg/204px-Wikipedia-logo-v2-en.svg.png") !important;
                background-size: 136px auto;
        }
}
@media (-webkit-min-device-pixel-ratio: 2), (min--moz-device-pixel-ratio: 2), (min-resolution: 2dppx) {
        #p-logo a {
                background-image: url("//upload.wikimedia.org/wikipedia/commons/thumb/b/b3/Wikipedia-logo-v2-en.svg/270px-Wikipedia-logo-v2-en.svg.png") !important;
                background-size: 135px auto;
        }
}

ウィキペディアのロゴはウィキメディア財団が著作権を持っているので、まったく無名のウィキだけど、このまま放置しておくのは賢明ではない。これを、次のように書き換える。

/* [[MediaZilla:35337]] */
@media (-webkit-min-device-pixel-ratio: 1.5), (min--moz-device-pixel-ratio: 1.5), (min-resolution: 1.5dppx) {
        #p-logo a {
                background-image: url("//[domain]/[wiki-directory]/images/b/bc/Wiki.png") !important;
                background-size: 136px auto;
        }
}
@media (-webkit-min-device-pixel-ratio: 2), (min--moz-device-pixel-ratio: 2), (min-resolution: 2dppx) {
        #p-logo a {
                background-image: url("//[domain]/[wiki-directory]/images/b/bc/Wiki.png") !important;
                background-size: 135px auto;
        }
}

～/images/b/bc/ というディレクトリは、ウィキにファイルをアップロードするとMediaWikiが自動的に生成するもので、画像などの格納に使うもの。各自の環境によって異なるので、目的の画像を自分のウィキで表示させた上で右クリックしてURLを確認する。管理者権限を有するユーザーが削除しない限り、新しいバージョンのファイルをアップロードしても過去のバージョンは残るため、URLが一意に定まることを利用する。

このように指定しておけば、ロゴを変更したくなった時は、FTP転送ではなく、ウィキからHTTP経由でアップロードしてデータベースを書き換えてやることで簡単に対応できるし、将来MediaWikiがバージョンアップした際にアップグレードした場合でもロゴのファイルを上書きされなくて済む。MediaWiki:Common.cssはそもそもデータベース上に存在するものなので、MediaWikiのソフトウェアのアップグレードには直接影響を受けない。

MediaWikiにExtension:Scribuntoをインストール

最終更新：2016/09/06

さくらインターネットのレンタルサーバでMediaWikiを動作させている前提で、Extension:Scribuntoをインストールする。Scribuntoは、Luaという言語で書かれたスクリプトを実行する環境をMediaWikiに追加設定する拡張機能。シンプルに使う分にはなくても特に困らないけど、Wikipedia英語版やWikimedia Commonsからテンプレートをインポートしたい場合はかなりの確率で必要になる。

Lua 5.1.4

Extension:Scribuntoは単体では動作しないので、Luaというプログラミング言語を解釈するインタープリターが必要になる。さくらインターネットではサーバのOSにFreeBSDを使用していて、SourceForgeで提供されているWindows用やMac用のLuaバイナリではうまく動作しない。Extension:Scribuntoのアーカイブに /extensions/Scribunto/engines/LuaStandalone/binaries という思わせぶりなフォルダが事前に用意されているけど基本的に役に立たない。そこで、Lua Download areaから lua-5.1.4.tar.gz のソースコードをダウンロードし、解凍後、makeして直接サーバにインストールする。

2016年3月7日現在、Luaの最新バージョンは5.3.2になっているが、Lua 5.2.xやLua 5.3.xを使用すると「ステータス1」を返してインタープリターがエラーを起こすことがある模様。なお、Lua 5.1.xではLua 5.1.5が最終バージョン。

具体的には、SSHにログインを参考にSSHシェルにログインし、コマンドラインから次の手順で行う。あからじめ/local/src/というディレクトリをサーバに作っておく（これだけはFTPクライアントでもできる）。

cd ~/local/src/
wget http://www.lua.org/ftp/lua-5.1.4.tar.gz
tar -zxvf lua-5.*
cd lua-5.1.4
make freebsd
make local
cd bin
ln -s lua lua-5.1.4

Extension:Scribuntoの実装

Extension:Scribuntoのスナップショット（現時点で安定動作する最新版）をMediaWiki公式サイトからダウンロードし、適当なフォルダに解凍する。/extensionディレクトリに/Scribuntoディレクトリを作成し、そこへFTPクライアントでアップロードする。

LocalSettings.phpに次の6行を追加する。Luaインタープリターはユーザーが指定できるもっともルートに近いところから順にパスを指定しなければならないので注意（他の環境変数のように$IP/～では始められないということ）。

require_once "$IP/extensions/Scribunto/Scribunto.php";
$wgScribuntoDefaultEngine = 'luastandalone';
$wgScribuntoEngineConf['luastandalone']['luaPath'] = '/home/[user-name]/local/src/lua-5.1.4/bin/lua-5.1.4';
$wgScribuntoEngineConf['luastandalone']['errorFile'] = '/home/[user-name]/www/[wiki-directory]/extensions/Scribunto/errorfile.log';
$wgScribuntoUseGeSHi = true;
$wgScribuntoUseCodeEditor = true;

メインページを再読み込みすると、「モジュール」、「モジュール・トーク」という名前空間が追加され、Luaで書かれたスクリプトを実行できるようになる。

なお、4行目はLuaインタープリターのエラーログの設定で、正常に動作するようになったらコメントアウトするなどして無効にしてもOK。5行目は、各種言語の文法（マークアップ）をハイライトするExtension:SyntaxHighlight_GeSHiを、6行目は、CSSやJavaScriptの編集を補助するExtension:CodeEditorをそれぞれLua言語で書かれたスクリプトモジュールでも有効にする設定。

もし、スクリプトを保存しようとした時に、

Script error: Lua error: Internal error: The interpreter exited with status 127
Script error: Lua error: Internal error: The interpreter exited with status 126

といったエラーメッセージが出る場合は、インタープリターのmakeに失敗しているか、パスが間違っている可能性がある。上の手順でインタープリターをmakeした場合は自動的に実行可能なパーミッションが与えられているので特に問題にならないけど、手順が間違っていないのにうまくいかない場合はインタープリターのバイナリファイルのパーミッションが「755」など全ユーザーが実行可能になっていることを確認する。

インタープリターが正常に動作しているかどうかテストするには、Wikipedia英語版にあるModule:Bananasという極シンプルなスクリプトを自分のWikiにコピーして同名で保存してみる。保存時に文法エラーがないかチェックされるので、正常に動作していれば、何事もなく保存できる。

{{int:Lang}}の問題を解決

メディアウィキ・コモンズからテンプレートを移入しようとすると、必ずと言っていいほど言語間の翻訳の問題が出てくる。メディアウィキ・コモンズは、各言語ごとに英語の原文を翻訳した膨大なシステム・メッセージを持っており、閲覧者の環境（またはプリファレンス・個人設定）に合わせて置き換えたうえで出力してくれる。ところが、そういった言語自動切換え機能を備えたテンプレートをそのまま実行（トランスクルード）しようとするとModule:FallbackやModule:Languagesといったモジュールでスクリプト・エラーが出る。これは、{{int:Lang}}というマークアップを使ってMediaWikiに標準で実装されていないシステム・メッセージを呼び出そうとしているから。MediaWikiは、Langというキーワードに結び付けられたシステム・メッセージを見つけられない場合は<Lang>という文字列を返してくる（詳しくはHelp:マジックワード参照）。これでは、ISO 639で定められた2文字の言語記号には当たらないのでエラーになって当然ということになる。

これを解消するには、自分のウィキにMediaWiki:Langというファイルを作り（作り方は標準記事名前空間と同じなので特に説明はしない）、「ja」（日本語）や「en」（英語）などとシンプルにISO 639で定められた2文字の言語記号を書いて保存する。

システム・メッセージの反映には少し時間がかかるので、すぐに確認したい場合は、エラーが出たテンプレートを編集モードで開いて何も変更せずにプレビュー機能を使い、スクリプト・エラーが出ないことを確認する（関係するテンプレートやモジュールを全部展開して解釈するので数十秒かかる）。遅くとも、一晩経てばシステム・メッセージは全体に反映されるようになっている。

モジュール名前空間の接頭辞変更

モジュール名前空間はデフォルトでは「モジュール」、「モジュール・トーク」となっている。私はUTF-8でのURLがわかりにくいという理由ですべての名前空間を英語に戻してしまったので、同様に英語に統一したい。そこで、/extension/Scribuntoディレクトリの直下にあるPHPファイルScribunto.namespaces.phpを次のように変更する。例は、日本語のWikiを対象とする場合。

なお、しつこいようだけど、UTF-8を編集できるエディタでないとファイルが破損するので、必ずUTF-8が編集できるエディタを使用する。

$namespaceNames['ja'] = array(
	828 => 'Module',
	829 => 'Module_talk',
);

参考記事

MediaWikiのインストール手順

最終更新：2016/09/06

現在、このWordPressのブログも含めて、さくらのレンタルサーバを使っているけど、せっかく最大容量が増えて30GBから100GBになったのに、1GBにも満たないほどしか使っていない。月額500円とは言っても少々もったいない気もする。

WordPressには数えきれないほどのプラグインやテーマがあってカスタマイズに自由度があるのが長所。ブログやCMSとしては十分なんだけど、HTMLの文法に制限されるためリンクや段落わけが気軽にできず、ひとつの題材を持った作品やデータベースを少しずつ育てていくという使い方にはあまり向いていないような気がする（あくまでも個人的な感想）。ついつい備忘録的なブログ記事を書いてしまっているのが現状。

そこで、少々敷居は高いけど、ウィキ文法が確立していて記事を編集しやすいウィキペディアで使用されているMediaWikiを導入してみることにした。MicrosoftのWebMatrix3を使用してローカルホストで実験してみた限りではそれほど難しくはなさそうだった。もちろん、ここにわざわざ備忘録を残すくらいなので、設定を半自動的にやってくれるWebMatrix3とは異なり、いくつかハードルにぶかったことは言うまでもない。

インストール要件

MediaWikiは、WordPressと同様に、ホスト側にPHPとSQLデータベースが動作する環境がなければならない。MediaWiki 1.20からPHP 5.3.2以上が必要となったため、WordPressの要件に合わせてPHP 5.2.17を使っている場合は注意が必要。さくらのサーバコントロールパネルの「PHPのバージョン選択」で簡単に変更できる。今回は、PHP 5.4.26に変更した。なお、同じサーバに同居しているWordPressには影響なかった。

データベース作成

いつも使っているウェブブラウザでさくらのサーバコントロールパネルにログインし、「データベースの設定」からデータベースを新規作成する。

既にデータベースを使用している場合は、データベース名を入力して文字コードを選択するだけで設定は終わる。まだデータベースをひとつも作っていない場合は、データベースユーザー名（普通は初期アカウント名）とデータベース接続パスワードを設定する。サーバコントロールパネルにログインするパスワードとは独立しているので、忘れないように記録しておく。文字コードは必ず「UTF-8」を選択する。MediaWikiの初期設定時に使うため、ホスト名も記録しておく。

MediaWikiソフトウェアのアップロード

MediaWikiの公式サイトからmediawiki-1.22.4.tar.gz（2014年3月26日現在）をダウンロードし、ローカルPCの適当なフォルダに解凍する。一般に普及しているFTPクライアント・ソフトウェアで/home/[user-name]/www/以下に作ったMediaWiki用のディレクトリにアップロードする。ディレクトリ名はなんでもいいけど、初期設定が済んでしまうと容易に変更できなくなるので、後で変更するつもりなら今のうちに。ここでは、ディレクトリ名を仮に[wiki-directory]とする。

ちなみに、ついつい使ってしまいそうな/wikiという名前のディレクトリはショートURLのために予約されているので、ショートURLを使うつもりであれば、使ってはいけない。なお、さくらのレンタルサーバーではショートURLを利用できる。詳しくは、MediaWikiでショートURLを使うを参照。

ここで一点だけ注意。それは、FTPクライアントの「アップロード時にファイル名をすべて小文字（大文字）にする」という設定をオフにするということ。MediaWikiのファイルには大文字・小文字を併用しているものがかなりある。MediaWikiの公式サイトのインストールガイドにも太字で Make sure the “Change file names to lowercase” option for upload is disabled. と書いてあるんだけど、リネームするのが面倒で普段は自分のWEBページを更新する時には小文字にしてアップロードするのが当たり前になっていたため、すっかり忘れていた。そのために初期設定からいきなり動かず、2700個くらいあるファイルのアップロードをやり直す羽目に。気をつけましょう。

MediaWikiの初期設定

ブラウザからhttp://[domain]/[wiki-directory]/index.phpにアクセス。インストール要件を満たしているかチェックされ、主にPHPのバージョンが要件に達していない場合は設定を見直して再度アクセスするように促される。要件を満たしていれば、次の図のように「set up the wiki」と表示されるので、それをクリックし、あとは画面の指示に従って入力する。あくまでも例示なので、設定の細部はお好みで。
MediaWiki-1.22.4

言語

あなたの言語 日本語
ウィキの言語 日本語
MediaWikiのインターフェースに使用する言語。

データベースに接続

データベースの種類 MySQL
データベースのホスト 記録しておいたデータベースのホスト名。
データベース名 記録しておいたデータベース名。
データベーステーブルの接頭辞 他のデータベースと識別するためのプリフィックス。MediaWiki専用にデータベースを作った場合は未入力でもいいけど、後で変更するのは手間なので、できればそういうものだと思って入力しておいたほうが無難。後でわかったことだけど、さくらのレンタルサーバーでは独立したデータベースを複数作ることができるので、プリフィックスを入力しなくてもまったく問題ない。
データベースのユーザー名 記録しておいたデータベースユーザー名。
データベースのパスワード 記録しておいたデータベースパスワード。

データベースの設定

ウェブアクセスのためのデータベースアカウント チェックボックスにチェック☑しておく。
ストレージエンジン InnoDB
データベースの文字セット バイナリ
データベースの文字セットをUTF-8にしたのだからUTF-8なのかと思ったら説明書きを読むとバイナリのほうが良さそう。

名前

ウィキ名 これから作成するWikiの名前（$wgSitename）。
プロジェクト名前空間 標準記事名前空間と区別してプロジェクト上のメタな事柄を書くための名前空間の接頭辞（$wgMetaNamespace）。ウィキペディアなら「Wikipedia:～」がそれにあたる。例えば、Wikipedia:著作権はウィキペディア上での著作権の取り扱いなどを書き、標準名前空間の著作権は「著作権とは何か」を書くための記事。
管理アカウント名前 Wikiにログインして管理するためのアカウント名。最初のユーザーでもある。
パスワード 上記アカウントのパスワード。

以上で、基本的な設定は終了。「私にもっと質問してください。」をチェックして続行すると、引き続き閲覧や編集が可能なユーザーグループを設定したり、著作権などの詳細な設定ができる（機会があれば追加する）。

初期設定が完了すると、LocalSettings.phpというPHPファイルのダウンロードが自動的に始まるので、一回ローカルPCに保存して、[wiki-directory]の直下にアップロードする。

LocalSettings.phpは、DefaultSettings.php（これは変更禁止）を元に、これまで設定した基本データを反映した設定ファイル。暗号化されていないパスワードなどがそのまま書かれているので、他のユーザーに見られてしまうと困る。FTPクライアントの属性変更コマンド（chmodコマンド）で必ず属性（パーミッション）を「700」か「600」に設定して不特定多数が閲覧できないようにしておく。

ちなみに、LocalSettings.phpはいつでも変更できるため、初期設定を変更したくなった場合はUTF-8を編集できるエディタで変更して再アップロードしてブラウザをリロードすると反映される（とは言ってもデータベース関連はいじらないほうが無難だし、いじる必要はそうそう発生しない）。

起動

LocalSettings.phpが[wiki-directory]に存在している状態で、再び http://[domain]/[wiki-directory]/index.phpにアクセスすると普通ならばおなじみのMediaWikiのメインページが表示されるわけだけど、私はこんなエラーメッセージに阻まれた。

Fatal exception of type MWException Error

どうやら、拡張機能で適当に追加したLocalisationUpdate.phpというファイルが悪さをしているらしい（MediaWiki:当該トラブルシュートスレッド）。そこで、何をするファイルなのかはよくわからないので、ひとまず次のようにコメントアウトして、ようやく起動した。

# Enabled Extensions. Most extensions are enabled by including the base extension file here
# but check specific extension documentation for more details
# The following extensions were automatically enabled:
require_once "$IP/extensions/Cite/Cite.php";
require_once "$IP/extensions/Gadgets/Gadgets.php";
# require_once "$IP/extensions/LocalisationUpdate/LocalisationUpdate.php";
require_once "$IP/extensions/Nuke/Nuke.php";
require_once "$IP/extensions/ParserFunctions/ParserFunctions.php";
require_once "$IP/extensions/Renameuser/Renameuser.php";
require_once "$IP/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.php";
require_once "$IP/extensions/WikiEditor/WikiEditor.php";

サイドバー

MediaWikiには主要なリンクやツールをまとめたサイドバーというものがある。WordPressのウィジェットとは比べるべくもない簡素な見た目のツール群だけど、これが一定の規則に基づいたキーワードを元にJavaScriptで自動的に生成されているらしく、/[wiki-directory]/skins/common/に格納されているすべてのスキンの根本のCSSであるcommonElements.cssを変更してもリンクの色が変わらない。生成されたソースを見てもよくわからない。

とても人力で解析できそうには思えなかったので、FireFoxの要素解析ツールを使って構造を調べてみた。<a>タグのエレメントに直に割り当ててあったリンク色も上書きしていて複雑なIDとクラスの構造になっていた。その結果を反映したものが次のCSS。これをMediaWikiのサイト上からMediaWiki:Common.cssに反映する。色はお好みで。

div#mw-panel
div.portal
div.body ul li a { color: #003BC8; }

div#mw-panel
div.portal
div.body ul li a:visited { color: #003BC8; }

名前空間

現在、日本語版の名前空間接頭辞はカタカナや漢字に訳されている。一般的にはこのほうがわかりやすいんだろうし、多言語に対応するために英語版の接頭辞も使えるようになっているけど、UTF-8のマルチバイト文字をURLにするとどこの名前空間なのかわかりにくいので私はあまり好きではない。そこで、システムメッセージは日本語のまま（$wgLanguageCode = "ja";）にしておいて、名前空間の接頭辞だけを英語版仕様に戻すというワガママ仕様にすることにした。

具体的には、/[wiki-directory]/languages/messages/MessagesJa.phpというファイルを変更し、同じディレクトリにあるMessagesEn.phpから$namespaceNamesをコピーして移入する（システムに直接影響するので、下手に手動入力しないほうが無難）。日本語化されていた接頭辞も念のためエイリアス（別名）として残しておいた。

$namespaceNames = array(
	NS_MEDIA            => 'Media',
	NS_SPECIAL          => 'Special',
	NS_MAIN             => '',
	NS_TALK             => 'Talk',
	NS_USER             => 'User',
	NS_USER_TALK        => 'User_talk',
	# NS_PROJECT set by $wgMetaNamespace
	NS_PROJECT_TALK     => '$1_talk',
	NS_FILE             => 'File',
	NS_FILE_TALK        => 'File_talk',
	NS_MEDIAWIKI        => 'MediaWiki',
	NS_MEDIAWIKI_TALK   => 'MediaWiki_talk',
	NS_TEMPLATE         => 'Template',
	NS_TEMPLATE_TALK    => 'Template_talk',
	NS_HELP             => 'Help',
	NS_HELP_TALK        => 'Help_talk',
	NS_CATEGORY         => 'Category',
	NS_CATEGORY_TALK    => 'Category_talk',
);

$namespaceAliases = array(
	'ノート'               => NS_TALK,
	'利用者‐会話'         => NS_USER_TALK,
	'$1‐ノート'           => NS_PROJECT_TALK,
	'画像'                 => NS_FILE,
	'画像‐ノート'         => NS_FILE_TALK,
	'ファイル‐ノート'     => NS_FILE_TALK,
	'MediaWiki‐ノート'    => NS_MEDIAWIKI_TALK,
	'Template‐ノート'     => NS_TEMPLATE_TALK,
	'Help‐ノート'         => NS_HELP_TALK,
	'Category‐ノート'     => NS_CATEGORY_TALK,
	'メディア'             => NS_MEDIA,
	'特別'                 => NS_SPECIAL,
	'トーク'               => NS_TALK,
	'利用者'               => NS_USER,
	'利用者・トーク'       => NS_USER_TALK,
	'$1・トーク'           => NS_PROJECT_TALK,
	'ファイル'             => NS_FILE,
	'ファイル・トーク'     => NS_FILE_TALK,
	'MediaWiki'            => NS_MEDIAWIKI,
	'MediaWiki・トーク'    => NS_MEDIAWIKI_TALK,
	'テンプレート'         => NS_TEMPLATE,
	'テンプレート・トーク' => NS_TEMPLATE_TALK,
	'ヘルプ'               => NS_HELP,
	'ヘルプ・トーク'       => NS_HELP_TALK,
	'カテゴリ'             => NS_CATEGORY,
	'カテゴリ・トーク'     => NS_CATEGORY_TALK
);

参考記事