WordPressのブログサイトをSSL化する①

2017/03/15 追記

3回目のチャレンジでようやく成功

2回目の時は1回目に確認し忘れたキャッシュプラグイン(WP Fastest Cache Premium)が吐き出す .htaccess の確認も忘れずに実施したが、そこに根本的な原因はなかった(と思う)

結局1,2回目の失敗原因は不明

多い時だとリアルタイムで500くらい同時アクセスのあるサイトなので、追究するのがリスキーでできなかった

3回目はテーマをダウンロードし直して、子テーマ作ってきれいにしてから下記手順でやりなおしたら上手くいきました(3回目は少しレベルアップしてちょっとだけやり方変えたんで別記事で書きます)

関連記事:https://ctrl–z.com/2017/03/ssl-https-2/

Exray というテーマを借りてたんだけどいじくり倒してたんで、何かクリティカルな構文ミスがあったんだと思う←なおせないならいじるなという話orz


結果
失敗しました(1回目)
ん~というかURLを http ⇒ https はコンプリートしたんだけど、ものぉすごぉく遅くなっちゃった
キャッシュプラグイン(WP Fastest Cache Premium)を入れる前と同じかそれ以下になってるんでキャッシュが効いてない感じだけど原因不明
中身熟知しないで使ってるとこういう時ダメなんだよなぁ
この手の不具合を追究してるとキリがなくてWPやめたくなっちゃう

やる気満々で下の記事を書いていたのだがまことに残念な結果に。。

まぁなにかの参考になるかもしれないから興味ある方はどうぞ

/***** この記事書き終わって最後にふと思ったんだけど.htaccessのキャッシュプラグインが記述する部分が上手く書き換わってなかったんじゃないかと気づく。そこだけでも確認してみれば良かったorz *****/

以下、本文


今回ウチで一番稼いでくれているWordPressサイトをSSL化(https)する事にした

先々週あたりGoogle大先生がアルゴリズムのそこそこ大きい変更をしたという噂を聞いたがその影響なのか、先週からPVが半分近くになって泣いている

非SSL通信である事が関係してるかわからないけど、世間ではSSLデフォの波が押し寄せてきているので、やらない訳にはいかんくなったという状況

記事数は400弱だけど1記事が結構なボリュームで、DBエクスポートしてみたらテキストファイルで74MBもあるんで正直、あんまり触りたくなくて。。

そんなんでダラダラとSSL化を引き延ばしてしまったのだが今回そのような事情で重い腰を上げたという訳

以前から考えてはいたので、手順はそれほど迷わず以下の通りに確定

①DBバックアップ
②.htaccessバックアップ
③DB内のURL置換
④WP管理画面のURL変更
⑤301リダイレクト処理(.htaccess)
⑥Googleアナリティクス変更
⑦Googleサーチコンソール変更(httpの既存サイトを削除してhttpsを新規作成)

環境はCPIのレンタルサーバーで当然相手はLinuxでこちらはWindows7

LinuxのPCもあることはあるのだが、なにせ使い慣れていないんでトラブった時にあたふたするのが目に見えてる
親和性はベストではないかもしれないが、やはりこういう時こそ手慣れたPCでやるのが良いんだろうなとおじさん考えました

今回、一番悩んだのがDB内のURLをどうやって置換するか

DBダンプ(エクスポート)してローカルに落としてエディタで置換するのが一番早いかと思ったけど、Linux ⇒ Windows ⇒ Linux というのがどうも気になって、できれば避けたい

SSHでリモートサーバーにログインして、MySQLのコマンドで直接やるのが一番良いと思ったのだが、CPIってSSH経由で操作できる範囲が狭いみたいで、コマンドがきかなかった(熟知していないのでやり方悪いのかもだけど他のサーバーで試したらできたので、恐らく制約かと。。間違っていたらごめんなさい※Poderosa使用)

phpMyAdminからクエリで置換していくという手も考えたけど、DB全体を文字列で一括置換というSQLコマンドは存在しないらしく(たぶん)、対象のテーブルをピックアップして全部のカラムに対して置換をかけるというなんとも手間のかかる作業なのでそれも断念

もちろんWordPressのプラグインを使っちゃうというのもあるんだけど、中身がどうなってるかわからないからなぁと。
恐らくは↑の手作業をグリグリっとスクリプトがやってくれるだけだとは思うがトラブった時に何が悪いのかわからないのは嫌なので、これもやっぱり不採用

こうなるとやはり最初にあげたDBエクスポートしてローカルでテキストエディタで置換というのが最もシンプルなのかなぁと

問題は74MBもあるファイルを何で扱うか

手元にあるエディタでは開くだけでも数分かかり、置換が正しく行われるか怪しいので248GBまで扱えるという最強エディタEmEditorを使ってみることにした

永久ライセンスが18000円とテキストエディタとしてはかなり高額だが、30日間の試用期間があるので、とりあえず今回は試用で使ってみた

まぁ~チョッパヤだね

74MBのファイルが一瞬で開いた。さすが

.htaccessの変更は以下の構文を”# BEGIN WordPress”の前に挿入(実際はWP Fastest Cache Premiumのヤツが長々と# BEGIN WordPressの前に挿入されているので、その更に前に挿入予定)

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
</IfModule>
これも環境によって無限ループになる事があるようなので、要注意ですよ
※結果、これで現在は上手くいってる 2017/03/15 追記

関連記事:https://ctrl–z.com/2017/03/ssl-https-2/

手順をさらってみる

①CPIの管理画面からバックアップ用のDB作成

下の*****_dbが既存DB、*****_bup0219がバックアップ用

②phpMyAdminで既存DBの内容をバックアップ用DBにコピー

既存DBの管理画面から操作タブを選択してコピー先にバックアップ用DBを指定
バックアップ完成(+で開くと既存と全く同じ構成になってる)

③既存DBをエクスポートしてローカルに落とす

74MB弱。デカすぎw

④テキストエディタで http:// ⇒ https:// に一括置換する

他のURLまで書き換わらない様に http://example.com の様にドメインまで指定する

関連記事:https://ctrl–z.com/2017/03/ssl-https-2/


あとは書き換えたSQLファイルで既存DBをリストアすればOK

MySQLってインポートで上書きにはならないから、一度テーブルをすべて削除して、インポートする

そして、アクセスの少ない明け方4時頃を狙ってDBリストアした

WPの管理画面の設定⇒
WordPress アドレス (URL)
サイトアドレス (URL)
については、確認したらhttpsに変わっていた

そりゃそうだ、DB内のURL全部書き換えたんだから、ここも変わってなきゃおかしい

結果

URLの書き換えは上手くいった

しかし、何故かキャッシュプラグインが効いてないようで、ページ開くのに10秒とかそれ以上かかってしまう

全てのキャッシュを削除はやってみたが改善せず

CDNも変えてみたりしたけど変わらず

正直なにが悪いか全く思いつかなかったので、とりあえず戻すしかない

再度、既存DBのテーブルをすべて削除して、バックアップ用DBの管理画面に入り、操作タブからコピー先に既存DB指定をして実行

戻しは上手くいった

もちろんページの表示スピードも従来通りに戻っている

そんな訳で現状、SSL化は仕切り直しと相成りました。osamushi

関連記事:https://ctrl–z.com/2017/03/ssl-https-2/

Forbidden You don’t have permission to access / on this server. とは

wordpressで運用している検証サイトをサーバー移行してみた

対象フォルダをzip圧縮して、データベースは phpMyAdmin から sql エクスポートして、移行先サーバーにすべてをインポートして完了(ダウンロード、アップロードはブラウザ経由)

検証用サイトなんで、22MB程のサイズで難なく完了と思いきや

開いてみると下記の通り

Forbidden
You don’t have permission to access / on this server.

クライアントからのリクエストに対して、サーバーが403エラーを返しているという事

permission(許可)が不十分

閲覧禁止とか訳される事もあるかな

ファイル・フォルダのパーミッションはもちろん変更していないので問題ないはずなのに。。

でも、一応対象フォルダのパーミッションを確認してみた

おぉ~なんと変わっちゃってるじゃないか

750じゃ開けないよね

コレって移行先サーバー(今回はさくらのレンサバ)でzipを解凍したのだが、その場合、最上位フォルダは750に設定されるようになってるのかもね(たぶん)

755に変更

はい解決

さくらのレンタルサーバーの場合ファイルマネージャから簡単にパーミッションを変更できる

対象フォルダを右クリックしてフォルダメニューを出す

プロパティを選択するとパーミッション設定画面ポップアップが出てくる

ffftpとかでも同じような操作で簡単に変更できるよね

よくみかけるのはサーバーメンテナンスで403が返ってくるケース

メンテナンス中、ユーザーからのアクセスを避ける為にサーバー側で上位フォルダの閲覧権限を狭くしてるんだろうね