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

https化完了

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

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

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

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の使い方

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

  1. サイトに行って、3つの項目にチェックしたうえで、名前やメルアドを記入すると、Eメールでダウンロードリンクが送られてくる。
  2. 英語のメールなので、どれが目当てのバージョンのダウンロード用のリンクなのか分かりづらいが、根気よく探すと大丈夫のはず。
  3. ダウンロードしたZipファイルを解凍すると『Search-Replace-DB-master』というフォルダが現れる。
  4. FTPソフトで『Search-Replace-DB-master』をフォルダごとアップロード。アップ場所は、ワードプレスが格納されている階層。つまりwp-adminやwp-contentと同じ階層。

    FTPで見た階層構造

  5. アップロード後、https://ドメイン/Search-Replace-DB-masterにアクセス
  6. アクセスすると、数の画面が出てくるので、赤枠のところに記入。
    上に置き換えたいURL、下にこれから使いたいURLを記入。

    seach / replaceの画面


    ※データベース名、ユーザー名、パスワードなどはスクリプトが自動で取得してくれる。
  7. 記入を終えたら、実行乾燥をクリック。実行乾燥には思わず吹き出してしまったが、多分英語バージョンのDRY RUN(お試し実行)を機械的に直訳したものだろう。

    置き換えのお試し、本番実行、削除ボタン

  8. 「実行乾燥」では置き換わらず、置き換え候補が示されるので、確認後「ライブ実行」ボタンをクリックして、置き換え完了。
  9. 忘れてならないのは、最後の仕上げ。「私を削除する」ボタンの実行。スクリプトをこのまま置いておくのは危険なので、必ず削除すること。

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

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

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

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

 

826ブログ
シェアをお願いします!
この記事を書いた人
yaziro3

このサイトの運営者yaziro3(ヤジローサン)です。
カトリック教会のこと、デジタルのことに関心を持つ還暦世代です。
yaziro3の名は、1549年聖フランシスコ・ザビエルを鹿児島に案内してきた薩摩の人・ヤジローに由来しています。

yaziro3をフォローする
教会のITサポート:826村

コメント