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.htmlindex.phpで始まるような普通のウェブサイトを配置していて、そこに上記の.htaccessを設置してもそのウェブサイトは何の問題もなく表示される。同様に、独自ドメインに/wpといったディレクトリを作って本記事のブログのようなWordPressを設置してMediaWikiと並列で運用していても問題ない。

唯一ダメなのは、/wikiというディレクトリが実際に存在している場合。MediaWiki公式サイトのインストール・ガイドにも「wikiというディレクトリ名だけはやめたほうがいい」と書いてある。もし、そこにMediaWikiをインストールしてしまった場合でショート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をアップグレードして何か問題が起こっても、ダウングレードは最終手段と考え、慌てず騒がず同じ問題に行き当たった人が書いた記事がないか探してみるべきだと痛感した。

関連記事

参考記事