https化の最大の難関は内部リンクの修正、Search-Replace-DB-masterで克服

2017.12.09

この記事は約6分で読めます。

Googleがウェブサイトのhttps化を推奨している、という記事を読んだのはいつのことだったのか？それ以来、ずっと気になっていた826村のhttps化（SSL化とも言うらしい）がこのほどようやく完了したので、備忘録的にその道のりを記しておきたい。

これまで気になりながらも手を付けることができなかったのは、SSL化に際しては「SSLサーバー証明書」を取得する必要があり、その費用が年間数万円以上もかかるということで、二の足を踏んでいた。

ところが、その最大の足かせであった経費が無料でも、できるらしいという記事を発見して急ぎ挑戦した次第。私がお世話になっているサーバーはXSERVERなのだが、ここにはなんと「無料独自SSL」の追加設定が可能になっていたのだ。

この記事の目次

Xサーバーの「無料独自SSL設定」を利用
内部リンクの確認と変更に四苦八苦
1. Search Regex、Search & Replaceでトライしたのだが
  1. 私の環境では2つとも機能しなかった
Search-Replace-DB-masterで内部リンクを修正
1. Search-Replace-DB-masterの使い方

Xサーバーの「無料独自SSL設定」を利用

エックスサーバーの無料独自SSL設定

設定方法は、まるで簡単！！
マニュアルに丁寧な説明があるので、その通りに手順を踏むと1分もかからずにSSLを追加設定でき、私の環境では、約10分後にはhttps://8263.jpでアクセスすることができた。

内部リンクの確認と変更に四苦八苦

https://8263.jpでアクセスすることができたとは言え、常時SSL化はこれからが天王山だった。サイトにアクセスすると、ページは表示されるが、どこを探しても安全であるというお墨付きが出てこない。

SSL化に際して参考にしたサイトによると、https化が首尾よく行くとサイトのURL欄には、クロームの場合「保護された通信」という表示が出、ファイヤフォクスでは緑色のカギマーク、マイクロソフト・エッジでは黒い線でカギマークが付くというのが、それが出てこない。参考までに、完了した暁のURL欄のキャプチャを下に掲載しておく。

SSLページのChromeの表示

SSLページのFirefoxの表示

SSLページのEdgeでの表示

クロームのデベロッパーツールで調べると、原因はhttpsサイトであるにもかかわらず、httpのリンクが混在しているという指摘だった。

Chromeデベロッパーツールの指摘

ヘッダーに使用している画像のリンクがhttp://になっているので、ここをデベロッパーツールの指摘通りにhttps://に修正したら、「保護された通信」のお墨付きが現れた。やれやれ！

ところが、画像を貼り付けるためのリンク　src=”8263.jp/・・・/やページリンクの　href=”8263.jp/は、サイト内には数えきれないほどある。それらをひとつづつ手作業で修正するのは厄介、到底出来っこない！

なんとか手間を省く方法はないものか？

探してみると、やはりあった。

Search Regex、Search & Replaceでトライしたのだが

先人たちのお勧めはSearch Regexというプラグイン。早速インストールしてトライしてみたが、私の環境では動作せず、何回やってもエラー。一度に全部するのではなく、数を絞って少しづつというアドバイスを見つけたので、その方法を試してみても駄目だった。

私の環境では2つとも機能しなかった

次に探し当てたのがSearch & Replace。
Search Regexでは、にべもなくエラーが出たが今度は、そこそこ動く。dry run（お試しコース）では、Replaceではこのようになります、までは行くが、本番実行段階でエラー。何回やってもダメだった。

Search-Replace-DB-masterで内部リンクを修正

諦めかけていたところに、Search-Replace-DB-masterと遭遇した。

Search-Replace-DB-master

終わってみればそう難しくはなかったが、データベースをいじるスクリプトというのでドキドキするのは確か。

Search-Replace-DB-masterの使い方

ダウンロードと使い方は、次の通り。

サイトに行って、3つの項目にチェックしたうえで、名前やメルアドを記入すると、Eメールでダウンロードリンクが送られてくる。
英語のメールなので、どれが目当てのバージョンのダウンロード用のリンクなのか分かりづらいが、根気よく探すと大丈夫のはず。
ダウンロードしたZipファイルを解凍すると『Search-Replace-DB-master』というフォルダが現れる。
FTPソフトで『Search-Replace-DB-master』をフォルダごとアップロード。アップ場所は、ワードプレスが格納されている階層。つまりwp-adminやwp-contentと同じ階層。
FTPで見た階層構造
アップロード後、https://ドメイン/Search-Replace-DB-masterにアクセス
アクセスすると、数の画面が出てくるので、赤枠のところに記入。
上に置き換えたいURL、下にこれから使いたいURLを記入。

seach / replaceの画面

※データベース名、ユーザー名、パスワードなどはスクリプトが自動で取得してくれる。
記入を終えたら、実行乾燥をクリック。実行乾燥には思わず吹き出してしまったが、多分英語バージョンのDRY RUN（お試し実行）を機械的に直訳したものだろう。
置き換えのお試し、本番実行、削除ボタン
「実行乾燥」では置き換わらず、置き換え候補が示されるので、確認後「ライブ実行」ボタンをクリックして、置き換え完了。
忘れてならないのは、最後の仕上げ。「私を削除する」ボタンの実行。スクリプトをこのまま置いておくのは危険なので、必ず削除すること。

Search-Replace-DB-masterのおかげで、内部リンクの更新も無事に済み、サイト内のすべてのページがSSL化された、はず！

確認したページではすべてグーグルクロームで「保護された通信」のお墨付きが出た。万歳！

この後、ワードプレスの設定で、WordPress アドレス (URL)とサイトアドレス (URL)をhttps://8263.jpに変更し、さらにはhttpをhttpsにリダイレクトするためやHSTSのために.htaccessファイルに手を加える設定、またサーチコンソールの設定などがあったが、それらは割愛する。

とにかくやるべきことはいっぱいあったが、一番厄介だったのはURLの変更だった。