SSL化した(httpsで表示する)WordPressサイトの引っ越し(サーバーの移転)をしたので、その顛末記をシェアしたいと思います。
顛末というからには、想像していたようにようにはいかなかった、失敗談です……。
あ、いえ、経験値アップ談ということにしておきましょう(笑)。
実は私は、今回の前にも、SSL化したワードプレスサイトの引っ越しを経験済みでした。でもその時は、同じレンタルサーバー内での移転作業(旧式でレスポンスが悪かったものから新式への引っ越し)だったため、うまくいって当たり前だったのです。
WordPressを導入してから、かなり経験値を積んだつもりでしたが、今回の引っ越しでは、そのことがよーくわりました、はい。
◆ そもそも、なぜ、引っ越しだったのか?
理由はSSLです。
SSLには、レンタルサーバーの会社が独自に提供しているものと、第三者が提供しているものと、ふた種類あります。
移転元のサイトでは、後者のほうを使っていました。というか、それしか選択肢が現時点でもないのです。
当然それなりのコストがかかります。他の多くのレンタルサーバーでは、無料でSSLの機能が提供されていますから、フリーランスの身としては、高価なサービスを使い続けるのは分不相応だと判断して、移転を決意したというワケでした。
◆ SSLサイトの移転は、手順が重要!
私は、WordPressサイトの移転は、データベースとアップロードした画像ファイルさえ失わなければ、あとは何かあっても、最終的には手作業でなんとかなると考えています。
まあ、その程度の投稿数しかないということにもなりますが、ここで、ひとつ重要なことは、移転作業中のダウンタイムをできるだけ短くしなければならない、ということです。
ネットと仲良しの皆さんなら、以下のような画面に遭遇したことがあると思います:
こんなページが表示されてしまうのは、嫌ですよね?インパクトあり過ぎです。
でも、今回の移転作業ではいろいろと手こずってしまい、ほぼ三日間、このような表示のままになってしまいました。
◆ SSL化されたサイトの引っ越しは、単純にはいかない!
ウェブサイトを引っ越しする時には、使っている自分のドメインはそのまま使い続けるケースがほとんどだと思います。
その場合には、SSL「以前」であれば、
1.移転先のサーバーにも、使っている独自ドメインを設定
2.移転先にWordPressをインストールする
3.hosts ファイルを設定して、移転先のWordPressにアクセスできるようにしておく
4.データベースのテーブルの移動を始める…..
という手順で、ひとつひとつの工程の結果を確かめながら引っ越しすることができたわけです。で、移転先のWordPressが移転元と同じようにちゃんと動作していることを確認した時点で、ネームサーバーの向きを旧サイトから新サイトに変更してやれば、移転によるダウンタイムはゼロです。
ところが、SSL化されたサイトの場合は、そうは問屋が卸さないのです。理由は、移転先のサイトを前もってSSL化しておくことが、難しいからです。
まず、レンタルサーバーの会社が提供しているSSLの機能は、ネームサーバーの向きがそのサーバーを向いていないと設定できません。つまり、同一ドメインでの引っ越しの場合で、レンタルサーバーが提供するSSLを使うという条件の下では、SSLサイトからSSLサイトへという単純な引っ越しはできない、ということになります。
◆ ダウンタイムは避けられないのか?
ダウンタイムを回避するには、「レンタルサーバーが提供するSSLを使う」という条件を外して、先に説明したような第三者機関によるSSL認証を利用するしかありません。
ですがそうすると、今回の私の場合だと、何のために移転するのかわからなくなってしまいます。また、第三者による認証を使う場合でも、移転元と移転先との両方のサーバーで、対応する機能を持っていなければ実現しないようですので、移転先のサーバーを選ぶ段階からそのように計画していなければなりません。
というわけで、私に残された選択肢は、移転先については非SSLのままデータを移動しておいて、全てが出来上がったところで、移動元のSSLを外してネームサーバーの向きを変えて、ようやく移動先のサイトをSSL化することができる、というわけです。
この間に、サイトを訪問してきた人達には、先ほどの画像が表示されてしまうということになります。
◆ 実は、もうひとつあるダウンタイム
さて、ここまでで、SSL化されたウェブサイトの引っ越しをする場合には、一般的には、SSLサイト→非SSLサイトへの引っ越しとなってしまうことを説明しました。
そのことだけわかれば、後はデータベースの移動を・・・と、なれば良いのですが、そうはいきません。この方法だと、途中経過を確認しながら作業を進めることができません。
移動するデータベースの中身は、SSL化された状態のデータになってしまうため、そのままでは、非SSLの移転先では動作しないのです。このため、データベースのテーブル内のデータを移転先でのインポートを終えた後に編集するか、そうでなければ、全ての工程を終えて移転先のサイトをSSL化するまで動作の確認ができません。
データベースのテーブルを編集するためには、phpMyAdminを使うことになります。クエリ(命令文)を操ることができるならよいのですがが、データベースという言葉そのものに馴染みがない方の場合には、少々無理があります。
なので、結局のところ、移転元データベースのエクスポートをする時には、一時的にSSLを外すことが必要になります。具体的には、サイトの場所と、WordPressのインストール場所のhttpsをhttpに書き換えます。
さらに、内部リンクをhttpからhttpsに書き換えるプラグインを使用している場合には、それもオフにします。
こうしておいて、データベースのエクスポートを実行するワケですが、この間はもちろんダウンタイムになります。エクスポートが完了したら、すぐに元の設定に戻しておきましょう。
◆ インストールするディレクトリと、データベースの接頭語にも要注意
移転元と移転先とで、WordPressをインストールするディレクトリ(フォルダ)を同じにしないと、面倒なことになります。
今回の引っ越しでは、移転元では、/wordpress/ をルートの下に作ってあったのですが、移転先ではそれができない仕様になっていたため、余計な時間を使うことになりました。これもデータベース内のデータをクエリで書き換えることができるのであれば、簡単に問題は解決します。
逆に、移転元のほうでWordPressのインストール場所を書き換えてしまうと、書き換えた瞬間にWordPress管理画面にアクセスできなくなります。この場合もやはり、後でデータベースに直接アクセスして元に戻してやれば、またアクセスできるようになりますが、それよりは、あえてディレクトリを残したまま移転するほうがよいと思います。
そうすると、移転先では崩れた形のサイトが表示されてしまいますが、移転先の管理画面にログインして、WordPressのインストール場所を修正することで、サイトが正しく表示されるようになります。
◆ 接頭語を変える場合は、テーブル名を換えるだけではダメ!
そして今回、解決に最も時間がかかったのが、データベースの接頭語です。
ワードプレスをインストールする前に、データベースを自分で設定するようになっている場合、接頭語を指定したと思います。接頭語と言われても忘れてしまっている方がほどんどかも知れません。
私の場合は、サブドメイン用にセットアップしたデータベースには、わかりやすいようにとデフォルトのwp_ではなく、別の接頭語を使っていたのですが、移転先のサーバーでは、wp_指定になっていたのが想定外でした。
テーブルを移動するにあたっては、もちろん接頭語を書き換えてから移動しました。これでOKだと勘違いしてしまったのが、素人の証明です。テーブル名の変更だけでは不十分で、中身のデータにも接頭語が使われていることに、なかなか気付くことができませんでした。
このことが原因で発生した現象は、サイトはきちんと表示されているけれども、WordPressの管理画面にアクセスできなくなるというものでした。サーバーのサポートの方も前例がないということで、いろいろと調べて下さったのですが、お手上げ状態。
結局クリーンインストールからやり直そうとしたのですが、その前にusermetaのテーブルをながめてみたところ、そこで使われているデータにも接頭語が用いられていることに気づきました。それをwp_に書き換えることでようやく解決しました。
◆ まとめ
今回の引っ越しで学んだことは、WordPressで使われているデータベースについての知識があるかないかで、対応力に大きな差が出るということです。
私はたまたま、データベースとSQLについての一般的な背景知識程度はありましたので、なんとか対応できた状態です。
参考までにWordPressで使われているデータベース内の各テーブルに関しては、公式サイトに詳しい説明があります。でも、データベースをちゃんと操作できるようになるには、phpMyAdminの勉強が必要になります……。
……と、面白いのでドンドンと深みにハマっていくわけですね(笑)。
いや私の場合は、その前にcssだべ・・・となると、ホントに何が本業なんだかわからなくなってしまいます。
フリーランスのみなさん、どうぞご注意を!
コメントを残す