今回はこのプラグインを使ってトラブルを解決した話をします。
ワードプレスを襲った悲劇に対する原因の特定、トラブルシューティングの手順と復元作業のやり方、定期的なバックアップの重要性などについてまとめました。
手順さえ間違えなければとても簡単な方法です。
目次
突然一部の記事が閲覧不能に…
昨日ふと気づくと、カテゴリ「Windows」の記事が閲覧できなくなっていました。
なぜかどの記事を開いても、そのカテゴリの最新の記事で使用したアイキャッチ画像だけが表示されてしまって本文が出てきません。
そこでいろいろググッて対処法を探し、1つのプラグインに辿り着きました。
ページを表示する時に使ったPHPファイルを表示するプラグイン「Helpful Information」
インストールして有効化すると、サイトを表示した際に出てくるツールバーにHelpful Informationの項目が追加されます。
Googleアナリティクスプラグインと同じような使い方ですね。
で、さっそくこのプラグインで問題が起きているページを調べてみました。
このような表示になります。
1行目には使用しているテーマファイルが表示されます。
2行目に、ページ表示に使ったPHPファイルが表示されています。
3行目には投稿タイプが表示されます。今回調べたいのはカテゴリ「Windows」のついた投稿（post）です。
その下には更に詳細な項目が並んでおり、ページ表示時にインクルードしたPHPファイルなども全て表示できるようです。
WordPressでサイトを作る場合、「投稿（個別記事）」は「single.php」を使って表示されます。
「固定ページ」は「page.php」を使って表示されます。
ところがどういうわけか、問題が起きているカテゴリ「Windows」がついた記事は読み込まれるPHPファイルが「attachment.php」でした。
ここでなんとなくピーンときました。これはデータベースが狂ったな、と。
実は数日前、カスタム投稿タイプの導入作業をしてて操作を間違い、カテゴリ表示に不整合を出しちゃったことがあったんですよね。
慌ててカスタム投稿タイプを消しプラグインを削除したものの、その時にデータベースに変更が入ったまま残っちゃったんじゃないかなと思います。
そこで、正常な時にバックアップされたデータベースを使って復元作業を行いました。
復元（リストア）作業はバックアップから始まる
こことても大事なところです。
テクノロジー観測所は定期的に全テータをバックアップできるプラグイン「BackWPup」を使っています。
なのでバックアップデータはあるんですが、だからといってすぐに復元してはいけません。
定期バックアップのため、取得したタイミングは「不具合が起きる直前」ではなく、バックアップ取得後～不具合発生までの間に新規投稿した記事もいくつかあります。
まずはこの"差分"を把握することと、もしもリストア作業中にデータが失われてしまった場合に備えて、作業前の状態に戻せるよう現時点のバックアップを最初に取得しましょう。
大きな作業をする時は必ず作業前の状態にいつでも戻せるようにするのが鉄則です。
幸いデータベースのバックアップは数秒でできます。（あまり大きくないサイトの場合）
バックアップができたらリストア作業に取り掛かります。
今作ったばかりの「最新版バックアップファイル」と、リストアに使う「古いバックアップファイル」を両方ダウンロードします。
phpMyAdminに接続
エックスサーバーを使っている場合、サーバーパネルからサイトのデータベース（mySQL）を管理するphpMyAdminに接続できます。
phpMyAdminにはログイン認証がかかっているはずです。この認証IDとパスワードは、WordPressインストールディレクトリ内の wp-config.php に書いてあります。
サーバーパネルからログインパスワードを簡単に変更できます。
しかし、変更した場合は必ず wp-config.php 側も書き換える必要があります。
パスワードが wp-config.php と異なっているとサイト自体を表示できなくなります。
phpMyAdminに接続したら、左カラムからデータベースを選択します。
するとテーブルの一覧がズラッと出てくるので、今度は右カラムから「インポート」タブを選びます。
インポート設定などがありますが特に何もいじらずに、そのページに向かってバックアップしたデータベース（SQLファイル）をドラッグ＆ドロップします。
インポートが完了すると画面に出てきます。
BackWPupで作成されたデータベースのバックアップは設定次第ではZIPなどに圧縮されています。その場合解凍して、中身のSQLファイルをアップロードします。
なお、SQLをアップロードする際はテーブルごと置き換えるような動作になるため「一旦既存のDBを消してからアップロードする」といった作業は不要でした。そのままアップロードで適用できます。
データベース（SQL）を古いもので上書き（復元）した時点でいくつかの記事は削除されます。
（そのバックアップファイルが作成された時点より後に投稿したもの）
削除される記事がある場合、下記の方法で記事のバックアップを取っておく必要があります。
投稿記事の指定バックアップが可能なプラグイン「WP CSV Exporter」
直接ダウンロードする場合はこちら。
インストールして有効化すると、ダッシュボードメニューの「ツール」の中に「CSVエクスポート」という項目が追加されます。
このプラグインは、WordPressのバックアップをCSV形式で取得できます。ワードプレスの標準機能を使うとXMLで全件取得になりますが、CSV Exporterでは条件を指定して該当する記事のみを抽出、バックアップが可能です。
プラグインの製作者様のブログにわかりやすい解説が載っています。
https://www.kigurumi.asia/imake/3972/
WP CSV Exporterの使い方
「ツール」より「CSVエクスポート」を選ぶとこのような画面になります。
上部のタブよりエクスポートしたいジャンルを選びます。今回は投稿記事なので「投稿」タブです。
そして、エクスポートしたいものにチェックを入れます。タイトル、本文、抜粋（使っているなら）、アイキャッチ画像などがあります。
なお、今回の作業ではサーバーデータには手を加えないため、DBの復元によって記事本文が削除されたとしても、使用した画像は全てサーバー側に残っています。よってアイキャッチ以外はバックアップはしません。
このプラグインの優れているところがここで、バックアップ対象を期間指定できます。
作成日を「復元に使用するバックアップファイルが作成された日以降」にしておけば、差分のみをエクスポートできます。
エクスポートに成功したら、データベースの復元（インポート）作業を行います。
また、WP CSV ExporterでエクスポートしたCSVファイルは、「Really Simple CSV Importer」でインポートできる形式になっていると製作者様のブログに書いてあります。
なのでCSVのインポートはReally Simple CSV Importerを使います。ダウンロードはこちら。
無事復元に成功
こちらで紹介した方法で投稿記事個別に追記していたカスタムCSSだけ一部消えていましたが、それ以外は全部復元できたようです。
復元後にサイト内を一通り調べて見て、異常が見当たらないようなら再度BackWPupでその状態をバックアップしておくと良いでしょう。
コメント