WorsPressをWebMatrixに引っ越し
WebMatrixとAzureの連携が便利で、ローカルで構築したWordPressが簡単にデプロイしたりダウンロードしたりできるんでハマりつつあんだけど、それならばと他のレンタルホストで稼働中のWordPressをいかに手軽に引っ張って来れるか試してみた。
今回はロリポップで動いてるWordPressをパソコンに引っ張ってみる。 *1
結論から言うと、移行には失敗。 それどころか、WebMatrixで管理していた他のサイトまで潰してしまった。 いったい何が起こったのか。
- サイト証明を破壊した
- サイトの削除時にDBを消した
デプロイに必要な情報が記述されたサイト証明は、新規でサイトを作った際に管理ポータルからダウンロードして適用する必要があるみたい ( たぶん、ローカルではなくAzureに作った時は違うのかもしれないけど ) 。これをしないと前回のデプロイ先にデプロイされてしまうとか。後述するけど、今回はロリポップからダウンロードするために先にロリポップの設定をして、後にサイト情報をデプロイ先のAzureに書き換えたのでこの可能性が高い。
うまくいかないサイトいじっているウチにWebMatrixに新規サイトが名前の重複で出来なくなってしまった。そこで、WebMatrixからいったん全部のサイトを消すようにしたら、データベースのテーブルもまっさらに。WebMatrixでもローカルでもひとつのMySQLを共有してテーブル名のprefixで競合対策している。ローカルくらいDBは建て放題だろうという思い込みがいけなかった。
ヒューマンエラー、操作ミスなんである。
しばらくは自分を呪うことにしよう。
予定していた超省力手順を記すとこんなかんじ。
まず事前準備としてこれだけやっておく。
- バックアップのプラグインを適用しておく
- プラグインデータベースのバックアップを実行しておく
プラグインからデータベースを復帰できるやつね。 でないと、SQLのツールが必要で面倒そうだし。 事前準備ができたら手元のパソコンにサイトを構築する。
- WebMatrixの新規サイトでアプリギャラリーを選択
- CMSからWordPress Japanese Packageを選択
- サイト名をつけて「次へ」
- ライセンスの同意とか順次進める
- アプリケーションのパラメータを適当に設定
- WordPressのインストール
- 完了するとブラウザが起動
- WordPressの初期設定で管理者アカウントを設定
いったんここでWordPressはブラウザを最小化でもして放置しWebMatrixに戻る。 PCに引っ越し元のデータを取り込む準備をする。
- wp-config.phpを適当に名前を変更する (ex:wp-config_install.php
- リモートタブの設定を選択
- 引っ越し元の情報を設定する
- 「設定の入力」を選択
- プロトコルをFTPにして引っ越し元の情報を入力
- リモートタブのダウンロードを選択
- 続行 !! 一方にしか無いファイルの削除はチェックしない
- ダウンロードが終わるのを待つ
プロトコルの「Web配置」ができればSQLも調整して根こそぎローカルにもってきてくれるんで楽なはずなんだけど、今回のロリポップは駄目だった。WebDAVでも駄目。まあ大抵はFTPでしか繋がらなくてSQLは別途持ってくる必要があるのだろう、今回はバックアップのプラグインを入れていたので楽だといいけど。
ダウンロードが完了したらちょっと慎重に。
- ダウンロードしたwp-config.phpを適当な名前に (ex:wp-config_download.php
- 前に変更したwp-config_install.phpを念のため複製してwp-config.phpに
- 問題がなければここで最小化しておいたブラウザのログイン画面をリロードし、旧サイトのアカウントでログインする。
- WordPressやプラグインのアップデート
- プラグインが全部無効化されているので慎重に有効化
- データベースを戻す
以上でパソコンのローカル環境で旧サイトのWordPressが再現される。
あとはAzureに発行すればok ... のはずだったんだけど。
実際は違うサイトを上書きしちゃった次第。
Azureサイトはスナップショット機能とか無いのかな。
今度、調べるとしよう。