Manual:Upgrading/ja

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


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

準備
を読みましょう.


 * 1) 要件を確認する
 * 2) RELEASE-NOTES ファイルを読む
 * 3) UPGRADE ファイルを読む
 * 4) 既存のファイルとデータベースをバックアップする
 * 5) 新しいファイルを展開する
 * 6) 拡張機能をアップグレードする
 * 7) 更新スクリプトを実行してデータベースをチェックする
 * 8) アップグレードをテストする
 * 9) 過去にインストールしたバージョンに由来する残ったファイルを除去する

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


 * PHP +
 * 以下のうちいずれか 1 つ:
 * MariaDB +
 * MySQL +
 * PostgreSQL +
 * SQLite +

バージョン1.36から2世代前のLTSリリースバージョンからのアップグレードしかサポートされなくなります（T259771参照）. さらに古いバージョンのMediaWikiを使用している場合は、アップグレードにいくつかの段階を踏む必要があります. すなわち、1.23 以前から 1.36 にアップグレードする場合は、まず 1.23 ウィキを 1.27 (または 1.35) にアップグレードする必要があり、その後 1.27 (または 1.35) から 1.36 にアップグレードできるようになります.

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

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

リリースノートを読む
配布物の tarball 内、または Git からチェックアウト/エクスポートされたファイルの中に、ファイル名が大文字のファイルがいくつかあり、そのうちのひとつに  (ウィキ) が含まれています. ファイルを開くなら「今」です. 今回のリリースでなにが変わっているのかを見てみましょう. UPGRADEファイルに書かれた説明も読んでください.

保留中のジョブの一掃
性能向上の理由で、データベースのいくつかの動作は先延ばしされており、ジョブキューで管理されています. それらのジョブはデータベースに格納され、実行すべき動作に関する情報をパラメーターに記録します. 新しいバージョンでジョブのパラメーターの指定方法が変更になり、ジョブの実行が失敗することを避けるために、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クライアントアプリケーションでディレクトリとファイルをサーバへアップロードしてください.

cPanel File Manager
cPanel is a popular interface provided by many web hosts. This method is efficient because the files are uncompressed on the server itself.


 * Navigate to the directory that holds your wiki folder.
 * Upload the mediawiki-1.xx.x.tar.gz file. You may need to hit "Reload" to see it.
 * Extract the mediawiki-1.xx.x.tar.gz file. Reload again.
 * Confirm that the mediawiki-1.xx.x folder is present.
 * Delete the tar.gz file.
 * Copy all necessary skins, extensions, image folders, customizations, and the LocalSettings.php into the new folder. (see below)
 * When you are ready to run update.php, rename your old wiki folder and your new wiki folder. (e.g. "w" becomes "w1.34" and then "mediawiki1.35.0" becomes "w") This step is easily reversible if you run into problems.

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

（Open）Solaris の利用者は gtar を使用するか、または:

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

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

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

Git の使用
を使用する場合は、ファイルをクリーンな場所にエクスポートし、前の節で説明したように、古いカスタマイズ済みのファイルを新しい場所にコピーします.

Composer で使用している外部の PHP ライブラリやウィキメディアのウィキ ファームを保守するために提供されているコレクションもインストールする必要があるでしょう. インストールや外部ライブラリの更新の詳細はGit ダウンロードの説明文書ドキュメントで見つけることができます.

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


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

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

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

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

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

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

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

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

もし多くの拡張機能が欲しいなら、Gitからダウンロードするのが最良の選択かもしれません. もしあなたがGitを持っていなくてもたくさんの拡張機能をアップグレードしたいのなら、mwExtUpgraderを使うことを検討するのがよいかもしれません.

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

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

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

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

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

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

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

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

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

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

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

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

$ php update.php

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

PHPのバージョンが古すぎます、MediaWiki には新しいバージョンが必要です（your PHP version is too old and that MediaWiki needs a newer version）というメッセージが表示されるかもしれません. そのメッセージが表示された後、更新は中止されます. Reason for this error is that the command line can use another PHP version than that one which you have when you execute MediaWiki from the web server. When you get this message you should check, if you can execute a newer PHP version on the shell by using a different command: That might e.g. be php5 or php56. If another version is available and - if so - under which name, depends on the setup of your server. If it does not work, ask your hoster; they will surely know.

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

What to do if php update.php fails to do anything, resulting in a quick pause and then return to command prompt
This can be caused by a malfunctioning extension or skin.

If this causes update.php to work, uncomment half of that half (so 1/4 of the extensions). If this does NOT cause update.php to work, uncomment the first half but comment out the second half, and then comment out half of the second half, etc. Repeat until update.php works to find the one that is failing.
 * Check that all extensions and skins called for in LocalSettings.php are present
 * Check that extensions are using the correct registration method (wfLoadExtension vs. require_once)
 * Comment out the first half of the extensions in LocalSettings.php.

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 を実行する.

以下に例を示します:

 $ command -v 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)   をもう一度実行します

Web ブラウザー

 *  も参照してください

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


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

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

更新のテスト
アップグレードが完了したら、ウェブブラウザでwikiを見て、以下の操作が期待通りに出来るか確認しましょう:


 * 複数のページの閲覧
 * 複数のページの編集
 * ファイルを１つアップロード
 * Special:Versionを開いて、表示されるバージョンが正しいか、拡張機能があるかを確認します.

Remove leftovers from old installations
If you have copied your previous installation to another folder on the server, be sure to remove it or make it completely inaccessible from the web. It is very important to not leave old installations accessible from the web, since it completely defeats the purpose of upgrading, and leaves your server open to attacks.

よくある質問


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

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

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

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

あなたが外装を修正したり、カスタム外装を使用している場合は、それらが新しいバージョンのMediaWikiで動くように調整しなければならなくなる可能性が高いでしょう.

本当に古いバージョンからどのようにアップグレードすれば良いでしょうか？一段階で済みますか？何段階もかかりますか？
It depends: If you are upgrading from MediaWiki 1.4 or older, you should upgrade to MediaWiki 1.5 first. If you are upgrading from a Latin-1 wiki, use upgrade1_5.php (found in MediaWiki 1.5) to convert the relevant parts of the database to UTF-8 ( needs to be set to true in your for this to work). Next, run update.php, and then set the option in LocalSettings.php to the encoding previously used by the wiki (e.g. windows-1252). This is basically how Wikipedia and other Wikimedia Foundation sites were upgraded from MediaWiki 1.4 to 1.5 – see the settings page for enwiki and some related notes at Wikitech. You may need to upgrade to MediaWiki 1.4 before running the upgrade1.5 script. （例えばMySQLの）Latin-1のウィキのデータベース・ダンプを行いたい場合、 テーブルの の型が であることを確認してください. では文字エンコーディングの問題を避けられません.

MediaWiki 1.5 以降から 1.35 にアップグレードする場合は、古いバージョンから最新の安定バージョンに1ステップでアップグレードできます. 数多くの報告や自動テストが非常に上手く行くと指示しています. あなたがもしそれを信じられないなら、メーリングリストのこの投稿を読んで下さい. しかし注意して頂きたいことは、もしあなたが古い版から更新するならば、直前の版から更新する時よりもPHPエラーに遭遇する場合が多くなります. バージョンをスキップしていなければ、とにかくこれらのエラーを受け取っていたでしょうが、エラーは個々の更新に関連付けられていたでしょう. Instead, if you update several versions at once, you'll get the same set of errors all at the same time. この場合、更新が更に難しくなるでしょうが、あなたが飛ばした途中の版に更新すれば、その不具合が起きないことをお忘れなく！

If you are upgrading to MediaWiki 1.36 or later, only upgrades from the last two LTS releases will be supported (T259771). This will mean that for very old versions, that you first upgrade to MediaWiki 1.35 and then upgrade to 1.36.

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

長い回答：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 に以下の変数を挿入して、データベースを読み取り専用にする. アップグレード処理の間に利用者が編集しようとすると、このメッセージが表示されます:


 * 1) * This no longer works since MediaWiki 1.27, which also prevents running the update script. A workaround for versions since MediaWiki 1.27 can be found in . See also.
 * 1) 更新スクリプトまたはウェブ アップデーターを新バージョンのディレクトリで実行する.
 * 2) 古いバージョンのディレクトリ内の images サブ ディレクトリから新バージョンのディレクトリに画像をコピーする.
 * 3) 古いバージョンのディレクトリと新バージョンのディレクトリを交換する.

アップグレードする理由

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

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

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

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

Allow to block range of IPs. Added ability to search for contributions within an IP ranges at Special:Contributions. The was introduced. Add default edit rate limit of 90 edits/minute for all users. The "watch" feature can be enhanced with expiry dates.
 * 以降、編集内容を保存前にプレビューできるようになりました (差分表示と同じように).
 * 以降、取り消しボタンを利用できるようになりました.
 * 以降、Special:NewPagesの巡回ははるかに簡単になりました.
 * 以降、改名 (移動) できるようになりました.
 * 以降、自動的に二重リダイレクトを修正することができるようになりました.
 * 以降、 が利用可能になりました.
 * 適切なキャッシングがある場合、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では、セッション管理が改訂され、利用者認証管理も完全に近代化されました. InstantCommons no longer requires local files.
 * Since, the cache for rendered HTML of article pages improved.
 * Since, the Action API was reworked and improved. Also, user group assignments may now be done for a selectable period.
 * Since, the blocked users cannot change their email.
 * Since, some extensions are now part of the core, like , ,.
 * Since, MediaWiki supports over 350 languages.
 * Since, MediaWiki supports "partial blocks", where IPs and accounts can be restricted from editing particular pages or namespaces.
 * Since, more extensions part of the core: (for Lua modules), ,.
 * Since (a stable long-term support release),  is part of the core.

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

関連項目

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