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作成
②phpMyAdminで既存DBの内容をバックアップ用DBにコピー
③既存DBをエクスポートしてローカルに落とす
④テキストエディタで http:// ⇒ https:// に一括置換する
関連記事：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
