クライントサイトで行ったWordPressのバージョンアップ手順

クライントサイトで行ったWordPressのバージョンアップ手順

クライアントサイトのWordPressバージョンアップを行った際の作業工程の記録です。極めて慎重に作業を行った場合の例といて参考ください。

目次

要件定義・依頼内容のフィックス

  • Webの性質上「必ずできる」はあり得ないという事を前提条件に作業を行う
  • Webサーバーはクライアント管理
  • データベースも絡むのでログインアカウントの共有を依頼
  • サーバーの仕様の確認、サイト構築環境のリサーチ、テスト環境の構築の可否などもろもろ確認
  • バックアップは全ファイル取り、いつでも復旧できるような状態にする

大まかな作業の流れ

  1. バックアップ(Webサーバー・データベース)
  2. テスト環境構築
  3. バージョンアップ
  4. 動作確認
  5. バックアップデータの納品

Webサイト構築環境

Webサーバー

KDDI Web Communications CPI 専用サーバー(MySQL 5.0)

対象サイト

  • 医療系ポータルサイト:WordPress バージョン3.6.1
  • 医療系ポータルサイト(グローバルサイト):WordPress バージョン3.6.1
  • クリニックサイトA:WordPress バージョン3.3.1
  • クリニックサイトB:WordPress バージョン3.5.1

全4サイト

作業手順

1.データバックアップ

Webサーバー内とデータベースのバックアップを行います。Webサーバー内はルートディクトリから丸々ローカルに保存。データベースはちょっと面倒ですが、1つにまとまったデータと各テーブルごとのデータのバックアップを取ります。

テーブルごとにバックアップを取る理由は、1つにまとまったデータが大きすぎると、インポート時に全て上がりきらない現象が起こる時があるからです。面倒ですが、各テーブルごとのデータのバックアップを取り、sqlデータも該当する名前にリネームして保存します。

  1. phpMyAdminログイン
  2. 使用中データベース選択
  3. エクスポート
  4. 全選択
  5. 構造の「DROP TABLE / VIEW / PROCEDURE / FUNCTIONを追加」にチェック
  6. 「ファイルに保存する」にチェック
  7. 実行

更に、

  1. phpMyAdminログイン
  2. 使用中データベース選択
  3. エクスポート
  4. 1つの項目を選択
  5. 構造の「DROP TABLE / VIEW / PROCEDURE / FUNCTIONを追加」にチェック
  6. 「ファイルに保存する」にチェック
  7. 実行

これをテーブル分行う。

クライントサイトで行ったWordPressのバージョンアップ手順

2.公開中のWebサーバーにテスト環境を構築

「現在公開中のWebサーバーで検証をするのはリスクがある」と考える方もいますが、公開中のWebサーバーでテスト環境を構築する理由はデータベースのバージョンの違いにより再現性の相違を防ぐためです。WordPressのようなデータベースを使ったCMSは可能な限り同じ環境で検証することが望ましいと考えます。

  1. Webサイト用のルートディレクトリに「test」ディレクトリを作成
  2. 「test」ディレクトリ内にバックアップを取ったルートディレクトリ内のファイルをアップロードする

3.新規データベース作成

公開中のサイトが使用しているデータベースと同じ場所に、テスト環境用のデータベースを新規作成します。
※2つ以上のデータベースが利用できるWebサーバーに限るやり方

新規作成したデータベースにphpMyAdminでログインして、バックアップを取った公開中のサイトのデータベースをインポートする。公開中サイトが使用しているデータベースと見比べながら大きな相違がないかを確認。

1つにまとまったsqlデータが大きすぎてエラーになってしまう場合は、テーブルごとに取ったバックアップファイルをインポートする。

クライントサイトで行ったWordPressのバージョンアップ手順

インポートしたデーターベースのオプションテーブルを一部編集する。「wp_options」の「siteurl」。サイトURLをテスト環境用に書き換えます。このデータベースを使用するWordPressはどこのディレクトリを参照しているかを指定する設定です。

「http://www.sample.com/」 → 「http://www.sample.com/test」

クライントサイトで行ったWordPressのバージョンアップ手順

クライントサイトで行ったWordPressのバージョンアップ手順

クライントサイトで行ったWordPressのバージョンアップ手順

4.テスト環境の設定

「test」ディレクトリにアップロードしたWordPressファイルの設定を行います。

「wp」のように、WordPressファイルをディクトリにまとめて管理している場合、「test」ディレクトリ直下にある「index.php」は「require(‘./wp/wp-blog-header.php’);」となり、「test」ディレクトリからの相対パスになる。

「test」ディレクトリにWordPressファイルをそのまま管理している場合の「index.php」は「require(‘./wp-blog-header.php’);」となる。

次に「wp-config.php」に先ほど新規で作成したデータベースの情報を入力する。入力前はバックアップの状態なので、公開中のサイトで使用しているデーターベース情報が記述されている。今回のCPI 専用サーバーの場合は「DB_NAME」だけの変更になる。

5.テスト環境のWordPress管理画面にログイン

テスト構築したWordPressの管理画面にログインします。データベースは公開中のものを使用しているので、ログインIDとパスワードは公開中のものと同じです。

ログインするとWordPressがデーターベースの更新を求めてきますので、そのまま更新します。更新後、再びログイン画面に切り替わりるので、同じログインID・パスワードでログインします。

6.管理画面の設定

WordPress管理画面の設定。一般で「サイトのアドレス (URL)」を「http://○○○.com」から「http://○○○.com/test」に変更。「WordPressのアドレス (URL)」は、phpMyAdminで修正したので、「http://○○○.com/test」(「wp」ディレクトリでWPファイルをまとめている場合は「http://○○○.com/test/wp」)となっており、変更は不要かと思います。

データベースは公開中のものを使用しているので、ログインすると公開中のサイトの管理画面と同じ状態になっているはずですが、念のためテーマとプラグインを確認します。

7.公開中のサイトとテスト構築したサイトを比較

ここまで行えば、公開中のサイトとテスト構築したサイトは全く同じ状態になっていることになります。サイトのレイアウトや機能だけでなく、管理画面の機能など細かく確認します。

8.テスト環境のWordPressをバージョンアップ

テスト環境で問題なくバージョンアップが行えるかを検証します。使用しているプラグインを全て停止して、WordPressの管理画面から行える自動バージョンアップでWordPressを最新の状態に更新します。

自動バージョンアップが何らかの原因で止まってしまう場合

  • 「wp-content」フォルダのパーミッションが厳しい → 755 or 777に変更する
  • プラグインとバッティングしている → 全てのプラグインを停止してから再度自動更新

それでもエラーになる場合は手動でバージョンアップを行う。下記以外を削除して、WordPress日本語公式サイトから最新のWordPressファイルをダウンロード、テスト環境にアップロードを行う。

  • 「.htaccess」 → 自動生成される場合有
  • 「index.php」 → 1番上の階層の、仕様が変わっていれば最新の物に作り変える
  • 「wp-content/plugins」 → プラグインが格納されているディレクトリ
  • 「wp-content/themes」 → テーマが格納されているディレクトリ
  • 「wp-content/uploads」 → アップロードした画像が格納されているディレクトリ
  • 「wp-config.php」 → DB情報などの記録用

ダウンロードはこちらから → WordPress日本語公式サイト

9.プラグインも最新のものに更新する

WordPressバージョンアップのタイミングでプラグインも最新のものに更新する。プラグインを最新の状態に更新すると、設定などがリセットされたり、そもそも動作しなくなる場合も稀にある。不具合がでたプラグインは、バックアップ時に取った古いプラグインに戻すなどして、十分にテストサイトで検証をする。

最新のプラグインを使用することが好ましいが、どうしても正確に動作がしない場合は古いままのプラグインを使用する。代替案は後日検討。

10.バージョンアップ前サイトとバージョンアップ後サイトの検証

WordPressバージョンアップによって機能しなくなった部分はない。アーカイブ、パンくず、サムネイルなど。管理画面側も確認する。カスタムフィールドを使った投稿機能、パンくずプラグイン、お問い合わせフォームなど。

プラグイン同様に、問題あれば修正、修正不可の場合は「妥協する」もしくは「バージョンアップは諦める」をクライアントと調整。代替案の提案、最悪サイト自体の作り直しも視野に入れて提案。

※古いバージョンのWordPressはスパムの標的になります。「動くからいいや」ではハッカーにサイトが乗っ取られる危険性も考えられます。

11.最終バックアップ

稼働しているサイトであれば、検証中にもデータは更新されています。バージョンアップによる主要データ上書きはまず考えられませんが、念には念を入れてもう一度バックアップを取ります。もちろんWebサーバー内とデータベースの両方です。

12.公開サイトのWordPressバージョンアップ

テスト環境で十分に検証・確認を行ったら、同様に公開中のサイト、つまり本番環境のバージョンアップを行います。テストサイトでは全く同じ環境で問題なかったので、公開中のサイトもほぼ問題なくバージョンアップが出来るという認識でOKです。

しかし、そこはWeb。予期せぬトラブルは付き物なので、もし修正が必要になったら柔軟に対応する。最悪の場合、バックアップデータを用いて復旧作業(ロールバック)も行う場合もあります。アクセスが少ない深夜などに、公開中の本番環境での検証を行うといいでしょう。

13.クライント確認とバックアップデータ納品

問題なければクライアントに確認してもらう。自社のサイトだからこそ気付く不具合もあります。日々の更新業務に支障がないかなど管理画面の確認も重要。

確認依頼と同時に、11の最終バックアップで保存したデータを納品します。かなり大きなデータになると思いますので、「firestorage(ファイヤーストレージ)」といったオンラインストレージなどを利用するといいでしょう。

発生トラブルリスト

バージョンアップ後の管理画面アイコンの文字化け

プラグイン「WP Multibyte Patch」のアップデートで解決。更新マークが表示されない場合はプラグインを一度削除するといい。

プラグイン「Breadcrumb NavXT」更新で英語エラーが表示される

プラグイン「Breadcrumb NavXT」を更新すると「Your settings are out of date. Migrate now.」というエラーが画面上に表示されるが、「Migrate now」をクリックでOK。

プラグイン「Breadcrumb NavXT」更新で謎のプラグインが追加される

プラグイン「Breadcrumb NavXT」を更新すると「Breadcrumb NavXT 5.0 Migration Compatibility Layer DO NOT ACTIVATE」というプラグインが勝手に追加されるが、この謎のプラグインは停止、「Breadcrumb NavXT」は有効にすれば問題ない。

アーカイブページの本文抜粋の不具合

「the_excerpt();」で該当ページの文章を抜粋している場合で、バージョンアップ後、この本文抜粋が無効になっている。この場合はプラグン「WP Multibyte Patch」を有効にすれば日本語のカウントをしてくれ、しっかり本文が抜粋される。

原因不明の公開中サイトの「404 Not Found」

ディクトリを作って公開中のサイトに影響しないようWordPressやデータベースのテスト環境構築していたはずが、急に公開中サイト(本番環境)の下層ページが、全て「404 Not Found」になった。テスト環境のWordPressログインURL、もしくはサイトURLが何かしら影響したかと思われる。「.htaccess」を削除しても、Webサーバー内テスト環境を全て削除しても、テストデータベースを削除しても直らない。しかし、公開中サイトのWordPress管理画面から「パーマリンクの設定」を変更なしで保存(更新)したら復旧した。

テスト環境で一度ログアウトしたらログインできなくなる

データベースを再度インポートして更新すればログイン出来るようになる。phpMyAdminでバックアップの「wp_options.sql」をテスト環境用データベースにインポート。phpMyAdminで「siteurl」からログインURLを変えればOK。

ログインしようとしたら本番公開中のURLに切り替わる

「wp-config.php」のデータベース名の確認。テスト環境の「index.php」の確認。phpMyAdminの「wp_options」→「siteurl」の確認。

テスト環境の管理画面での操作は限られている

  • 外観「テーマ編集」は管理画面から出来ない
  • プラグインの一括停止は出来ない

WordPressの自動バージョンアップで「本当に実行していいですか ?」「もう一度お試しください。」となる

プラグインとバッティングしている。全てのプラグインを停止してから行う。また、ディレクトリのパーミッションが厳しいので「755」もしくは「777」にするといける場合がある。

プラグイン「Breadcrumb NavXT」でエラー

「Breadcrumb NavXT was just updated from a pre-5.0 version, please go to your plugins page and activate “Breadcrumb NavXT”. Also, deactivate the “Breadcrumb NavXT 5.0 Migration Compatibility Layer” plugin to make this message disappear.」のようなエラーが表示される。「Breadcrumb NavXT」が止まって「Breadcrumb NavXT 5.0 Migration Compatibility Layer DO NOT ACTIVATE」が動いている状態。「Breadcrumb NavXT 5.0 Migration Compatibility Layer DO NOT ACTIVATE」を停止して「Breadcrumb NavXT」を有効にすると解決。

今回の作業で参考にしたサイト

WordPressログイン関連の参考

参考サイト:http://wordpress.siyouyo.com/establishment/tukaikata/2669/
管理画面からWordPressのログインURLを変更すると、ログインできない状態になってしまう。修正方法の1つとして「wp-config.php」に「define(‘WP_SITEURL’, ‘http://●●●.●●’);」を追加すると指定したURLでログイン出来るようになる
しかし、管理画面からWordPressのログインURLの変更は出来なくなる。もう1つの修正方法は「phpMyAdmin」の「wp_options」→「siteurl」を修正する。

データベースのエクスポートで容量エラー

参考サイト:http://rensabanet.com/wordpress-tips/tukai/11733/
データベースのエクスポート時にあまりにも大きいsqlデータはインポートできない。保存方法を「zip」「gzip」「bzip」と圧縮するといい。圧縮してもダメな場合はエクスポートをテーブルごとに行うといい。

WordPressファイルからWordPressバージョンの確認

参考サイト:http://45395.org/cms/wordpress/wp-version-check/
「wp-includes」の「version.php」から確認できる。

phpMyAdminからwordpressのユーザー情報を確認する

参考サイト:http://www.seotemplate.biz/blog/wordpress-tips/11026/
「phpMyAdmin」→「wp_users」で確認できる。

WordPressをまとめてルートディレクトリをすっきりさせる

参考サイト:http://wpdocs.sourceforge.jp/WordPress_を専用ディレクトリに配置する

まとめ

自分が管理するWordPressサイトならバックアップも取らずにガンガン更新するのですが、お客さんのサイトとなると慎重にならざるおえません。特に、今回のサイトのような月間数十万PVもある大規模サイトであれば尚更。サイトが停止する事は許されないので、綿密な検証作業がほとんどになってますね。今回でWordPressのバージョンアップに関する作業テンプレートが出来たので、次回からは更に時間短縮が見込めそうです。

いいね!のお慈悲を…

この記事が良かったらシェアをお願いします!

記事の感想はこちら