Manual:Upgrading/ja



ファイル転送
ファイル転送の方法を選択してください:


 * wget
 * SCP または WinSCP でセキュアなコピー
 * SSH File Transfer Protocol (SFTP)
 * FTP クライアントを使用.
 * ホスティング会社がウェブブラウザ経由で使用できるファイルマネージャーを用意しているかもしれません. ご自分が契約しているプロバイダーを調べましょう.
 * その他の方法. これらのプロトコルの一覧は List of file transfer protocols にあります

準備
を読みましょう.


 * 1) 要件を確認する
 * 2) リリースノートを読む
 * 3) 既存のファイルとデータベースをバックアップする
 * 4) 新しいファイルを展開する
 * 5) 拡張機能をアップグレードする
 * 6) 更新スクリプトを実行してデータベースをチェックする
 * 7) アップグレードをテストする

システム要件の確認
MediaWiki の要件は以下の通りです:


 * PHP +
 * 以下のうちいずれか 1 つ:
 * MySQL + (または同等の MariaDB)
 * PostgreSQL +
 * SQLite +
 * Oracle +

PostgreSQL をお使いの場合は、 もお読みください.

詳細情報については、 および をお読みください.

リリースノートを読む
配布用のtarballやGitからチェック・アウト/エキスポートしたファイルの中には、大文字で始まるファイルが沢山ありますが、その中の１つに  （wiki）があります. ファイルを開くなら「今」です. 今回のリリースでなにが変わっているのかを見てみましょう.

保留中のジョブの一掃
性能向上の理由で、データベースのいくつかの動作は先延ばしされており、ジョブキューで管理されています. それらのジョブはデータベースに格納され、実行すべき動作に関する情報をパラメーターに記録します. 新しいバージョンでジョブのパラメーターの指定方法が変更になり、ジョブの実行が失敗することを避けるために、wikiをアップグレードする前に、保留中のジョブを実行するように強く推奨します. を使用して全ての保留中のジョブを実行し、アップグレードを実行する前にジョブキューを一掃します.

既存のファイルとデータベースをバックアップする

 * 完全な説明: 

アップグレード・スクリプトは良く管理され安定していますが、上手く行かない可能性はあります. データベース・スキーマを更新処理する前に、Wikiの完全なバックアップをしましょう. データベースとファイルのバックアップを両方とも行います.

ウィキはコンテンツです. データベースから表示しています. （キャラクターセットの設定は正確に. 最初に LocalSettings.phpを確認しましょう）. SQLデータベース・ダンプの他にXMLダンプを作成するのは良いアイデアです.
 * MySQLの場合、 コマンドでSQL dumpとXML dumpを使用します.

mysqldump --user=wikidb_user --password=wikidb_userpassword wikidb > file.sql mysqldump --user=wikidb_user --password=wikidb_userpassword wikidb --xml > file.xml
 * PostgreSQLの場合、databaseのダンプ作成には を使います. 以下のように入力してください:

pg_dump --create -Fc wikidb > file.db.dump
 * SQLiteの場合、バクアップ作成にはMediaWikiスクリプトを使用します.

php wikifolder/maintenance/sqlite.php --backup-to file
 * 画像と他のメディアファイル（ ディレクトリの内容とカスタムロゴ /skins/common/images/wiki.png）
 * 設定ファイル. 例えば や （もしあれば）.
 * MediaWikiのプログラムファイル. 全てのスキンや拡張機能、とくにユーザーが修正を加えたもの.

tarball パッケージの使用
FTPやコマンドラインを使って、新しいファイルを設置することが出来ます. もし可能ならコマンドラインを使いましょう！FTPを通して数千のファイルを一つづつアップロードするよりもコマンドラインの方がだんぜん速いです.

FTP コマンドかグラフィカルか
コマンドラインからサーバへ接続できない場合、MediaWikiより.tar,gzファイルをダウンロードし、7zipで解凍することもできます.

ローカルで解凍したあとは、FTPクライアントアプリケーションでディレクトリとファイルをサーバへアップロードしてください.

コマンドライン
カレントユーザーがウィキをインストールするディレクトリに対する完全な書き込み権限を所有していない場合は、 でコマンドを実行する必要があるかもしれません. tarballパッケージを解凍すると、新しいバージョン用の新規ディレクトリが作成されます. 古いバージョンをインストールしたディレクトリから設定ファイルや画像ディレクトリをコピーします.

$ cd /path/to/your/new/installation/ $ wget https://releases.wikimedia.org/mediawiki//mediawiki-.tar.gz $ tar -xvzf mediawiki-.tar.gz $ rm mediawiki-.tar.gz

（Open）Solaris ユーザーは gtar を使用するか、または

$ gzip -dc mediawiki-.tar.gz | tar xf -

その他のファイル
tarballを展開した後、古いバージョンをインストールしたディレクトリから新しい方へ幾つかのファイルやフォルダをコピーします.


 * 、ユーザーが行った構成設定が入っているファイルです.
 * ディレクトリ（古いバージョンの場合は ディレクトリ）. 初期設定では、ウィキにアップロードした全てのファイルが入っています. 所有権と権限を変更してください. と （ウェブユーザーが"apache"の場合）を実行します.
 * ディレクトリ内の拡張機能. 出来れば拡張機能も新しいバージョンを取得すべきです. 古い拡張機能が新しいバージョンのMediaWikiで動く保証はありません.
 * custom logoを使用している場合は、バックアップからファイルを復元する必要があります. 1.24以前は 、1.24以降は か （ユーザーの設定による）. それからLocalSettings.php に例えば を追加します.
 * ディレクトリからカスタム・スキン.
 * 古いバージョンでインストールしたファイルや拡張機能に加えた修正.
 * .htaccess ファイル（Apacheを使用し、何かルールを定義した場合）

完了したら、新しいフォルダをウェブサーバーの公開フォルダにします. もしくは古いインストールディレクトリの名前を変更して、新しい方を古い方の名前に変更します.

Git の使用
Gitを使用する場合、ファイルを全く新しい場所にエキスポートしてから、カスタマイズ済みのファイルを新しい場所に前述のようにコピーします.

MediaWiki 1.25以降を使用している場合、Composerで使用している外部のPHPライブラリやWikimedia wiki farmを維持管理するために提供されているコレクションもインストールする必要があるでしょう. インストールや外部ライブラリのアップデートの詳細はGit ダウンロード・ドキュメントで見つけることが出来ます.

パッチの使用
小型パッチは通常マイナーなバージョン・アップグレードに使用されます. the dumps siteからパッチファイルを手動でダウンロードして抽出して、以下のwgetの指示に従います. 増分パッチなので、バージョンをスキップすることは出来ません.


 * 1) MediaWikiディレクトリへ cd で移ってください. (一般的にLocalSettings.phpがある場所となります. )
 * 2) バッチファイルをダウンロードし、 gunzip で解凍してください.
 * 3)  を使って変更されることを確認します（例えば  ）
 * 4) 以上がよろしければ、 無しで patch を実行してください.
 * 「特別:バージョン情報」を確認すると、新しいバージョン番号になっているはずです.

エラーを引き起こす可能性がある残留ファイル
古いバージョンをインストールしたディレクトリに新しいバージョンを解凍した場合、幾つかの古いファイルが問題を引き起こすかもしれません.

プロファイリングを使用しないのに、MediaWikiのルートフォルダに ファイルがある場合、 の参照エラーが表示されるかもしれません. 削除するか、名称を変更すれば、 ファイルはこのエラーを解決できます. MediaWikiのルートフォルダにある ファイルは将来のプロファイリングのテンプレートとして役立ちます.

MediaWiki 1.23ではコアスキンファイルの自動発見メカニズムを旧式化しました. このバージョンにアップグレードしたら、 ディレクトリ内の 、 、 、 ディレクトリや ディレクトリ内のサブフォルダを削除してください. それらのフォルダを見つけると、MediaWikiは注意喚起のために警告ログを記録します. （似たような理由でカスタムスキンの調整も必要かもしれません）. 詳細はご覧ください.

MediaWiki 1.24 はコア・スキンファイルのパスを変更しました. このバージョンにアップグレードしたら、 ディレクトリ内の 、 、 、 に古いファイルが存在しないようにして下さい. 詳細はをご覧下さい.

拡張機能のアップグレード
拡張機能の中にはMediaWikiの新しいバージョンで動くようにアップデートされている物があります. そのような拡張機能は必ず最新版にアップグレードしてください. 中には拡張機能をカスタマイズするために手動アップデートを実行する必要がある物があるかもしれません.

ディファレントtarballsは拡張機能の一部セット（サブセット）であり、 ユーザーのMediaWikiコア・リリースに応じて正しい機能を選択して、ユーザーのアップグレードを助けるバージョニングを行います.

拡張機能ディストリビューター は古いMediaWikiで動作する拡張機能のスナップショットが欲しい人に役立ちます.

もし多くの拡張機能が欲しいなら、Gitからダウンロードするのが最良の選択かもしれません. If you don't have Git but you want to upgrade a lot of extensions, you might consider using mwExtUpgrader.

今までのLocalSettings.phpの適用
今まで使用してきた古いバージョンの を使う場合、新しいバージョンが を使用できるように を修正する必要があるかもしれません.

外装の登録
MediaWiki 1.24から VectorやMonobookやModernやCologneBlueのような同梱されたスキンはMediaWiki のコアの一部ではなくなりました. それらを使用するためには に明示的に設定する必要があります. もしそうしないとMediaWiki はスキンがインストールされていないと警告します.

以下の設定は、1.24より前のバージョンからアップグレードして、以前同梱されていたスキンの1つを使用したい場合に に追加する必要があるものです.

このコードはMediaWiki 1.25より適用されました. MediaWiki 1.24を使用する場合、以下のコードを実行してください:

他のスキンは新しいskin registrationシステムに未だ適用されていないと思われるので、問題が生じた場合は、スキンごとに適切な登録方法をドキュメント・ページで参照してください.

拡張機能の登録
MediaWiki 1.25より、新しい 拡張機能の適用 システムが使われています.

以前は $LocalSettings.php で以下のようにインクルードしていたと思われます:

1.25より、以下のように置き換わります:

拡張機能は新しい拡張機能登録システムを使用するように作られています. 適合しない拡張機能は古い方法を使ってインストールすべきです. 詳細は各拡張機能のページのインストール指示を参照してください.

その他の変数
幾つかの変数は旧式になり、廃止された物もあります. の中にそれらの変数があっても、何の効果もありません. 新しいバージョンでは新しい変数が追加されたり、既存の変数の型が変更になっている事があります. MediaWikiは変数をまずデフォルトで使用してみて、型が変わっている場合は、後方互換性で使用します. どのような場合でも、リリースノートより変更点を見てください.

更新スクリプトの実行
MediaWiki データベースの更新には２つの方法があります. １つはコマンドラインから行うもの、１つはウェブブラウザから行うものです. もしサーバーにシェルアクセスが出来るなら、コマンドラインによる更新をお勧めします. その理由はタイムアウトやコネクション・リセットによる更新処理の中断のリスクを減らすことが出来るからです.

スクリプトはMediaWikiが必要とする依存ファイルが見つからない場合はダウンロードを試みます.

コマンドライン
サーバーのコマンドラインやSSHシェル他を使用しましょう. SSH経由でサーバーに接続してコマンドラインを使用しましょう. ローカルのMicrosoft Windowsのパソコンの場合は、PuTTYでSSHを使いましょう. コマンドラインやシェルで、 ディレクトリを移動してupdate scriptを実行しましょう.

$ php update.php Linuxサーバーでエラーが表示されたら、ルートとしてコマンドを実行してください. sudo php maintenance/update.php. Windows (例えば)の場合は、まず最初にウェブサーバー（例えばApache）やデータベース（例えばMySQL）が起動しているか確認してください. それからupdate.phpを実行します（右クリックで「開く」を選択してPHP.exe）. スキーマのアップグレードが完了したら、コマンドプロンプトの結果ウィンドウは自動的に閉じるようです.

PHPのバージョンが古すぎます、MediaWiki には新しいバージョンが必要です（your PHP version is too old and that MediaWiki needs a newer version）というメッセージが表示されるかもしれません. このメッセージのあとで、アップデートは中止されます. このエラーの理由は、ウェブサーバー上でユーザーのMediaWikiを動かしているPHPとは別のバージョンのPHPをコマンドラインが使用できるからです. もしこのメッセージが表示されたら、シェル上でPHPの新しいバージョンを使用できるか、php5やphp56などのコマンドを実行して確かめてください. もし別のバージョンが利用可能なら、- if so - under which name, depends on the setup of your server. もし動かないなら、ホスティング会社に尋ねてください. たぶん知っています.

MediaWikiは既存のスキーマを検査して、新しいコードが動くように更新し、必要に応じてテーブルやカラムを追加します.

ALTER command denied to user エラー（類似エラー）の対処法
スクリプトが以下のようなメッセージと共に中断することがあります.

Error: 1142 ALTER command denied to user 'wiki'@'localhost' for table 'mytable' (localhost) ERROR: must be the owner of the mytable relation

これは（最上位ディレクトリにある）のとの設定を確認しなさいと言う意味です. そこにはスクリプトがデータベースに接続するために必要なユーザー名とパスワードの設定があります.

In some cases, an old $wgDBmwschema variable (for Postgres) seems to be read for the table name to update instead of $wgDBname, even when mysql is used. If this is the case, just get rid of the $wgDBmwschema definition in LocalSettings.php.

unexpected T_STRING エラーの対処法
コマンドラインからupdate.phpを実行している場合は、以下のようなエラーに出くわす可能性があります.

 syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or '}' \ in ~/maintenance/commandLine.inc on line 13

このエラーはPHP4でupdate.phpを実行している場合に起こります.

ホスティング会社がPHP4とPHP5の両方に対応している場合は、以下の手順を実行します.


 * 1) コマンドラインから「whereis php5」を実行する.
 * 2) PHP5のパスの場所を見つけたら、 php5/binディレクトリの内容をリスト表示する.
 * 3) PHPの実行ファイル（PHPまたはPHP5）が分かったら、完全なパスを入力してupdate.phpを実行する.

以下に例を示します:

 $ whereis php5 $ ls -la /usr/local/php5/bin $ /usr/local/php5/bin/php update.php

register_argc_argv is set to false エラーの対処法
以下のようなエラーが出力されると思われます:  Cannot get command line arguments, register_argc_argv is set to false


 * 1) ~/maintenance に行き、既存の'php.ini'を編集するか、作成してください.
 * 2) 以下のように行を追加します:

 register_argc_argv=true


 * 1) php update.php をもう一度実行します

Web ブラウザー

 *  も参照してください

データベースがすでに巨大だったり、稼働率が高い場合は、ウェブアップデートを使用すべきではありません. その理由は例えばmaximum_execution_timeに達した時、更新処理はタイムアウトするからです. そういう場合は （Webではなく）コマンドラインからupdate.phpを使用すべきです. これはまったくもってユーザーのサーバーに「大きすぎるほど大きく」依存します（例えばパフォーマンスやロードやスクリプト実行をどのくらい許すかというPHPの最大実行時間など）. Wikiがウェブアップデートを使用するには大きすぎるのに、ユーザーのホスティング会社がコマンドライン・アクセスを許可しない場合は、Wikiを他のホスティング会社に移す必要があります. できればシェル・アクセスが出来る会社が良いです.


 * 1) データベース・メンテナンスを実行する前はいつでもバックアップしてください.
 * 2) ウェブブラウザのURLに を入力します. 例えば、ユーザーのウィキが にあるなら、 と入力して下さい.
 * 3) ユーザーの使用言語を選択し、「次へ」をクリックします.
 * 4) インストールされているウィキが検出されます. 画面に表示される指示に従ってアップグレードします. もし「アップグレードキー」を尋ねられた場合はファイルを開いてに割り当てられたキーを探して下さい.

ウェブ・アップデーターが作動しないように思える時があるかもしれません. 最初の言語選択画面が表示される代わりに、空のWikiページが表示されるかもしれません. この場合、ユーザーのウェブサーバーがRewriteルールを使用している可能性が高いです（特にshort URLs）. これはmw-configではウェブアップデーターを表示せず、頭文字が大文字のMw-config/の時は表示します. この場合、.htaccessファイルの名前をアップデートの時だけ変更してください. そうすればウェブ・アップデーターにアクセスすることが出来るでしょう.

更新のテスト
アップグレードが完了したら、ウェブブラウザでwikiを見て、以下の操作が期待通りに出来るか確認しましょう.
 * 複数のページの閲覧
 * 複数のページの編集
 * ファイルを１つアップロード
 * Special:Versionを開いて、表示されるバージョンが正しいか、拡張機能があるかを確認します.

よくある質問


アップグレードはどのくらい大変ですか?
もし修正したファイルがだけで、1.5以降からアップグレードするなら、作業はとても単純です. 人間の作業は数分だけです. データベース・スキーマの変更時間はユーザーのデータベースの大きさに比例します. 数百万ページのWikiなら数時間かかる可能性があります. しかし千ページ以下の典型的な大きさなら、通常は数秒で完了します.

例えば1.13.0から1.13.1のようにメジャーバージョンが同じの「マイナーアップグレード」では、スキーマの変更は全く必要ありません. ユーザーはファイルの更新だけで済みます. データベースの更新は必要ありません. 従ってインストーラー・スクリプトの実行は必要ありません.

1.4以前からのアップグレードは複雑になる可能性があります. その理由はUTF-8以外の文字セットへの対応が廃止され、大量の文章データを並べ替えるソート構造が変わったからです. ファイルの関連する節を読んで下さい.

あなたが私たちのソースコードを修正していて、修正を上書きされたくない場合は、アップグレードは複雑になります. diff、patch、MeldやWinMergeのようなツールが役に立つかもしれません. あなたが維持管理がなされていない拡張機能を使用している場合も、手間がかかる可能性があります. MediaWikiを更新する時は、拡張機能も一緒に更新しましょう.

あなたがスキンを修正したり、カスタムスキンを使用している場合は、それらが新しいバージョンのMediaWikiで動くように調整しなければならなくなる可能性が高いでしょう.
 * 毎度毎度「グローバル」CSSやJS（JavaScript）ファイルにパッチを当てる代わりに、単純にMediaWiki:Common.jsや MediaWiki:Common.css ページにコードを追加することも出来ます. それらがデータベースの一部になっていれば、アップグレード後に再利用されるので、今後はMediaWiki のコアファイルにパッチを当てなくて済みます.

本当に古いバージョンからどのようにアップグレードすれば良いでしょうか？一段階で済みますか？何段階もかかりますか？
場合によります. MediaWiki 1.4以前からアップグレードする場合は、まず最初にMediaWiki 1.5にアップグレードすべきです. Latin-1のウィキからアップグレードする場合はupgrade1_5.php（MediaWiki 1.5にある）を使用して、データベースの関連部分をUTF-8をコンバートします（動作させるにはでにtrueを設定する必要）. 次にupdate.phpを実行し、LocalSettings.phpの オプションに以前のWikiで使用していたエンコーディングを設定します（例えばwindows-1252）. 以上は基本的にウィキペディアやその他のウィキメディア財団のウェブサイトがMediaWiki 1.4から1.5に更新した方法です. 詳しくは 関連設定ファイル（巨大ページにつき閲覧注意）やWikitechの関連するノートをご覧ください. あなたがupgrade1.5スクリプトを実行する前にMediaWiki 1.4に更新する必要があるかもしれません. （例えばMySQLの）Latin-1のウィキのデータベース・ダンプを行いたい場合、 テーブルの の型が であることを確認してください. では文字エンコーディングの問題を避けられません.

もし今使用しているバージョンがMediaWiki 1.5 以上なら、1ステップで最新の安定版へ更新できます. 数多くの報告や自動テストが非常に上手く行くと指示しています. あなたがもしそれを信じられないなら、メーリングリストのこの投稿を読んで下さい. しかし注意して頂きたいことは、もしあなたが古い版から更新するならば、直前の版から更新する時よりもPHPエラーに遭遇する場合が多くなります. とは言え、途中を飛ばさずに毎回更新していたとしても、それらのエラーが表示されることはあります. また途中を飛ばした場合は、不具合は一度に起こるでしょう. この場合、更新が更に難しくなるでしょうが、あなたが飛ばした途中の版に更新すれば、その不具合が起きないことをお忘れなく！

バックアップは第一にするべきですか?
簡潔な回答: はい.

長い回答：a) あなたは自分のデータをどのくらい高く評価するか、b) バックアップ作成がどのくらい大変か、c) あなたはMySQLの保守管理にどのくらい自信があるかによります.

アップグレードに失敗すると、あなたのデータベースは２つの版の間で矛盾した状態になるかもしれません. 更新中にPHPやMySQLエラーが発生すると、あなたのデータベースは一部だけ更新された状態になってしまうかもしれません. そのような状況でも、たくさん手作業をすれば、なんとか問題を修正できるかもしれません. しかしもっと簡単な方法があります. それはupdate.phpを実行して足踏みをする前にちょっとデータベースをバックアップすることであり、その後も継続的に行う事です. そうしないと不要な作業を何時間もすることになるかもしれませんよ.

復旧は複雑になりがちです. もしあなたがバックアップを怠って、更新関係の破損から復旧したいと助けを求めても、サポートフォーラムのボランティア達は好印象を持たないでしょう. よりよい対応は、あなたがご自分のバックアップで復旧して、MediaWikiプロジェクトの担当者に更新処理の不具合を報告することです.

自分のLocalSettings.phpを長持ちさせることは出来ますか？
はい、しかしユーザーは幾つかのマイナーな変更を行わなければならないかもしれません. のフォーマットは大部分が後方互換性です. LocalSettings.phpの互換性を壊すような変更はリリースノートの「後方互換性のない変更」節に文章化されて公表されます.

アップグレード中にwikiをオンラインに出来ますか？
一般的にはYESです. しかしGitは一時的に（数秒）Wikiを壊す可能性があります.

MediaWikiのマイナーリリース間のアップデートなら、行うべきことはソースファイルを更新するだけです.

注意: 以下はコマンドラインによる操作を想定しています. MediaWikiのメジャーリリース間のアップデートを行う場合に推奨される手順は以下の通りです.
 * 1) MediaWikiの新バージョンを新規ディレクトリに解凍します.
 * 2) 新しいバージョンのディレクトリの準備: 古いバージョンのディレクトリから設定済みのLocalSettings.phpをコピーし、インストール済みの拡張機能やカスタムスキン（もしあるなら）をコピーします. LocalSettings.phpの 設定を確認して、もし必要ならロゴファイルを古いバージョンのディレクトリから新しい方にコピーします.
 * 3) 新しいバージョンのリリースノートに、LocalSettings.phpに行う必要のある変更がないか調べます.
 * 4) 古いバージョンのディレクトリのLocalSettings.phpに以下の変数を挿入して、データベースを読み取り専用にする. アップグレード処理の間に利用者が編集しようとすると、設定されたメッセージが表示されます
 * 5) * これはMediaWiki 1.27以降では動きません. アップグレード・スクリプトも動作しません. を参照してください.
 * 6) アップデート・スクリプトまたはウェブアップデーターを新バージョンのディレクトリで実行する.
 * 7) 古いバージョンのディレクトリ内のimagesディレクトリから新バージョンのディレクトリに画像をコピーする.
 * 8) 古いバージョンのディレクトリと新バージョンのディレクトリを交換する.

アップグレードする理由

 * 新リリースの通知を受けるために mediawiki-announce を購読しましょう. 

普通のアップグレードなら十分に簡単で、ご利用のバージョンから最新バージョンへひとっ飛びに、ウェブブラウザーでアップグレードも可能だからです.

最近のリリースではあなたのウィキやホストを荒らし行為から守り安全に保つためのセキュリティ修正を受け取れる一方で、旧版のリリースでは ( を見れば分かるように) 受け取れません. このセキュリティ修正はアップグレードを決意するのに十分な理由となるはずです.

新しいメジャーリリースはあなたが使いたくなるような新しい機能を備えています. 詳細はリリース・ノートをご覧ください. 非常に古いバージョンからアップグレードすることを、あなたの上司に納得させるための根拠はこれです：


 * 1.5 以降、編集内容を保存前にプレビューできるようになりました (差分表示と同じように).
 * 1.9 以降、取り消しボタンを利用できるようになりました.
 * 1.12以降、Special:NewPagesの巡回ははるかに簡単になりました.
 * 1.13以降、改名（移動）できるようになりました.
 * 1.14以降、自動的に二重リダイレクトを修正することができるようになりました.
 * 1.16以降、が利用可能になりました.
 * 適切なキャッシングがある場合、1.17以降でははページの読み込み速度を大幅に最適化するようになりました.
 * Since 1.17, category sorting makes sense! (especially for non-English letters); extended to 68 languages after.
 * Since and, users of all languages and genders are correctly addressed by the interface and logs (before 1.15, no gender at all).
 * で外装システムが改造され、既存の外装の一部を自分の外装で再利用しやすくなりました.
 * 1.20以来、差分は読みやすくなりました.
 * In 1.21 and 1.23, email notifications become clearer and more predictable, making your wiki more effective.
 * 1.22以降、荒らしとの戦い（パトロール）はそれほど時間がかからなくなりました.


 * 1.24では、より良いセキュリティを可能にするためにパスワードの保存が改善されました.


 * 1.25以降、最近の更新の強化


 * 1.26では、「ResourceLoader」メカニズムが改良されました


 * 1.27では、セッション管理が改訂され、利用者認証管理も完全に近代化されました.


 * Since 1.29, the Action API was reworked and improved. Also user group assignments may now be done for a selectable period.

2014年以前にで 最も要望が多かった不具合の修正一覧 もご覧ください.

同様にMediaWiki 1.18で、私たちは改良された編集エディタや荒らし防止ツールのConfirmEditやNukeのような必要不可欠な拡張機能を同梱し始めました. 最新版で私たちはより多くの拡張機能を追加しつづけます. 

関連項目

 * Greg Sabino Mullaneのブログでポイント・リリース（マイナーな更新）に関する詳細を知ることが出来ます.
 * Project:Support desk 上手く行かない場合や助けが必要な場合
 * (バックアップに失敗した場合)
 * (バックアップに失敗した場合)
 * (バックアップに失敗した場合)
 * (バックアップに失敗した場合)
 * (バックアップに失敗した場合)