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

いろいろあったけど、3回目でやっとSSL化が上手くいった

経緯は前記事に書いたので興味があればどうぞ

関連記事:WordPressのブログサイトをSSL化する①

さて、今回最終的に実施した方法を画像交えながら書いていきます

前記事と重複もあるけど悪しからず

まずは環境から

リモートサーバーはCPIのレンサバ

対象サイトはWordPress 4.7.3 Theme Exrayバージョン: 1.5.2(子テーマ)

手元はWindows7 SP1

ブラウザ:Google Chrome バージョン 56.0.2924.87 (64-bit)

FTPソフト:FFFTP Ver.1.99a

テキストエディタは今回、試用で使う EmEditor

SSLサーバーについては知識もなく面倒が嫌なので、CPIが提供しているCPI SSLサーバーを契約して設定済み

手順は前記事では下記のリスト通りだけど、DB書き換えるのでWP管理画面でのURL変更は不要です

大きく分けて6項目

WPフォルダのバックアップはSSHでもFTPでも、各レンサバの管理画面でもできるね

CPIの場合は毎朝3:00頃に自動バックアップされていて、簡単に戻せるので(時間はかかるけどね)今回はDBと.htaccess以外はバックアップしません

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

それでは説明しよう

まず、以降に登場する3つのDBを識別する為に定義する
・A_DB WPとつながっているアクティブなDB
・B_DB 書き換え前のA_DBをバックアップしたDB
・C_DB http://⇒https://書き換えDB


①DBをバックアップする

まずバックアップするにあたり、現状がエラーなく動いているかを確認する

確認用ブラウザを用意しておいて、キャッシュやクッキー、その他の履歴なども全部消してからトップページやアクセスの特に高いページなどを確認

アナリティクスやアドセンスの管理画面などで、対象サイトがアクティブに認識されているか確認

WPなどで更新のアラートが上がっていてもこの時点で上げてしまって不具合が起きると別問題が発生してしまうので、プラグイン含めすべての更新は無視

DBのバックアップは2つ作成する(ローカルのは作業用)

1)リモートサーバー上(B_DB)
2)ローカル作業用(C_DB)

CPIのレンサバではDBサーバーで直接DBを追加する事ができないので、サーバー管理画面から空のDBを2つ作成し(B_DB、C_DB用)、phpMyAdminでアクティブDBをコピーするというやりかたでいきます
(WEBサーバー同様、CPIのDBバックアップ機能によりバックアップされていますが、今回は使いません)

CPIサーバー管理画面 この時点ではBとCは空(実際のCPIサーバーではA_DBというDB名は付けられない)

空のDBを作ったら phpMyAdmin でアクティブDB(A_DB)の管理画面で「操作」タブを選択して、コピーを実施

バックアップ用空DB(B_DB)の名前を入力して、ラジオボタンとチェックボックスでオプションを選択する
・構造とデータ
・コピーの前に CREATE DATABASE する

phpMyAdmin 画面 A_DBをB_DBにコピー

 

コピーが終わったらリモートのバックアップは完了

次にローカル作業用のバックアップをとる為、エクスポートタブを選択

DBエクスポート

対象のDB(A_DB)を選択して、特に設定は気にせずデフォルトのままエクスポート

ローカルSQLファイル

このSQLファイルを書き換える訳だが見ての通り74MB近くもあり、普通のテキストエディタでは開けない(開けても作業における信頼性は低い)ので、今回は248GBまで扱えるというEmEditorを試用で使用wwする

それは後程

関連記事:WordPressのブログサイトをSSL化する①


②.htaccess のバックアップ

WPの最上位階層にある.htaccessファイルを念のためバックアップしておく

パーマリンクがデフォルトのままだったりするとこのファイルが存在しない場合もある、その場合は不要

これはFTPソフトでも、ファイル管理マネージャーなどが使える場合はそれでも簡単にできるね

確認が必要になるかもしれないので、ローカルに落としておこう

ちなみに、ファイル管理マネージャーとか一部のFTPソフトではこのファイルが見えない場合があるので要注意

FFFTPなら間違いない


③ダウンロード(エクスポート)したSQLファイルのURL置換

先ほど①でダウンロードしたSQLファイルを書き換える

テキストエディタの置換機能でファイル内の「http://example.com」という文字列をすべて「https://example.com」に置き換えるという方法

http://だけ指定すると本文内の無関係なURLまで書き換わってしまうのでドメインまで指定する必要があるで注意

EmEditor で置換

流石 EmEditor 152662個の置換が一瞬で終わった

これをアップロードして書き換えるのだが、いきなりアクティブなDBを書き換えるのではなくて、①で作成した空のDB(C_DB)に一旦上げて、リモート上で書き換えを行う

ローカルからいきなり本チャンを書き換えてしまうと、もし万一通信障害などで上手くアップロードできなかった時にサイトに不具合が発生してしまう

リモート上で行えば、同サーバー内で書き換えができるので、リスクは半減する

まずは、phpMyAdminで空のC_DBを選択して、先ほどのローカルにあるSQLファイルをインポートする

インポートは特にオプションは選択せず、デフォルトで実施した

置換済みSQLファイルインポート

次に今インポートしたDB(C_DB)をアクティブDB(A_DB)に対してリストアする

既にデータが存在しているDBに対しては、上書きではなくて、テーブル単位で消してから書くという事をしないとエラーになる

phpMyAdminで上記でインポートしたDB(C_DB)を選択して、「操作」タブを選択して、コピーを実施

アクティブDB(A_DB)の名前を入力して、ラジオボタンとチェックボックスでオプションを選択する

・構造とデータ
・DROP TABLE/DROP VIEW(挿入前にテーブルを削除)

 

C_DB を A_DB にコピー

これが正常終了すれば主要の作業は完了

ここで一旦サイトを確認する

不具合があれば、すぐに①でリモートにバックアップしたB_DBをA_DBにコピーして元に戻す

手順は書き換えと同等

B_DBを選択して「操作」タブを選び、上記同様にA_DBを指定してオプションも同じ設定でコピーを実施する(不具合が無ければ元に戻っちゃうからやらないでね)


④301リダイレクト処理(.htaccess)

サイトに問題が無ければ、301リダイレクトを仕掛ける

301リダイレクトとは恒久的な転送で、一時的な転送302と区別されている

今回のような場合は、障害がない限りhttpに戻す事はないので301リダイレクトが正しい処置となる

.htaccessの先頭に下記の記述を追記するのだが、対象サイトの場合キャッシュプラグイン(WP Fastest Cache Premium)が独自の記述をしている為、干渉してしまう懸念があった

対策になるかは不明だけど、一旦プラグインを停止して独自の記述が削除されていることを確認してから下記を追記して、動作確認後にプラグインを有効化した

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
</IfModule>

結果、SSL通信にてサイトが正しく表示されている事を確認し、http://でアクセスしてもhttps://にリダイレクトされる事、キャッシュプラグインも正常に動作している事を確認した

ちなみに、この301リダイレクトのコードだが、この方法がすべてのサイトに有効か不明です

サーバーの仕様によっては無限ループになるなんて話も小耳にはさんだので、熟知していない人はググっていくつかのパターンを用意しておいた方が良いかもしれないね

さぁあともう少し


⑤Googleアナリティクス変更

Google Analytics の管理画面を開いて左のナビゲーションバー下の歯車アイコンをクリックして
プロパティ ⇒ プロパティ設定 ⇒ デフォルトのURL
をhttp://からhttps://に変更する


⑥Googleサーチコンソール変更(httpの既存サイトを削除してhttpsを新規作成)

GoogleサーチコンソールでURLを変更するというのは出来ないので、対象サイトを一旦削除して、htpps://で再度登録する

当然URLが変わるので、データはリセットされて「データはありません」状態から始まるけどそれはしょうがないね


全ての項目を熟知してる訳ではないので、不足や誤りがあるかもしれません

もし、この記事を参考にする場合は自己責任でおねしゃす。osamushi

関連記事:WordPressのブログサイトをSSL化する①

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/

PageSpeed Insightsでユーザーエクスペリエンス テストをしてみた

Googleのユーザー エクスペリエンス(UX)テストをしてみた
URL: https://developers.google.com/speed/pagespeed/insights/

この記事を書いている時点では、WordPress 4.7.2 Twenty Seventeen をカスタマイズ無しでキャッシュ以外のプラグインも無しのほぼ吊るしで使っているが、モバイル67点、PC75点だった

決してよい数字ではないよね

注意レベル?

当然のことながら、検索順位にも影響してくるからもう少し点数上げたいなということで、キャッシュのプラグインを強化した

WP Fastest Cache が使いやすいので元々導入しているが、有料版の WP Fastest Cache Premium にアップグレードした
※キャッシュ系プラグインは注意⇒ 英語(URL)の表示を折り返したい※キャッシュに注意!

他のサイトで使っていて実力は認識していたので、5000円弱のコストも特に高いとは思っていないので、すんなり導入

結果

ブラウザキャッシュの有効化とかCSS見直しとか、100点目指すのもそれほど難しくはなさそうなんだけど、WPやテーマのアップデートしたりすると、恐らくイタチゴッコみたいになるんで、このくらいで良いかと

このサイトはXサーバーのwpxクラウドというヤツでスピードも定評あるサーバーなので、レスポンスに関しては問題ないと思う(実際はサーバー側もWPに最適化されていてサーバー内部キャッシュも使われている)

キャッシュ系のプラグインで効果が大きいのは、PHPで一時的に作成したページをHTMLで吐き出して、リクエストに対しては静的ページを返す事でスピードも速くなるしCPUの負荷も減らしてくれる事だろうね

っと今回自力ではなくプラグインのお世話になっちゃったんで、技術的な話はないけど、正直、自力で何日もかけてやるより5000円払ったほうが早いよというつまらない話でした

おあとがよろしいようで。osamushi

英語(URL)の表示を折り返したい※キャッシュに注意!

HTMLは、英文の場合ワードの途中では折り返さないという思想で設計されている(と思う)

長い英文の区切れないワードの場合、サイトの幅を超えてはみ出しちゃう事になる

日本人かつ昭和人なオレは馴染みがないが、英語は言葉の途中で折り返す(次行へ送る)のは非推奨なので、ブラウザもそれに則ってリフローしない設計になってるという事なんだろうね
※基本は半角スペースがワード区切り

当然、URLもアルファベット(半角・1バイト文字)の羅列なので、英文とみなされ、なにもしなければ、webページの右端で折り返さず、言葉の区切りまでハミ出す

たとえ英語圏の人たちだって、こんなのイヤだよね

現状においては、様々な幅のデバイスで閲覧されるので、コンテンツ側で丁度よく折り返るように文章を調整するなんて事をしても無意味

それでこんな対応

CSSに以下を追記
body{
word-wrap : break-word;
overflow-wrap : break-word;
}

※ word-wrap は旧タイプで overflow-wrap は未対応ブラウザがあるみたい
いずれは overflow-wrap に置き換えられるみたいだけど両方書いておくのが良いらしい

しか~し!

オレが運営しているあるサイトで、この対策が効かなかった

追記しても折り返らなかったのだ

検証サイトで全く同じ環境を作ったのにもかかわらず折り返り、対象サイトでは折り返らない

結論から言います

Word Press のプラグインで WP Fastest Cache Premium というのを導入している

wpで吐き出す動的ページをキャッシュして静的ページで渡す、CPUの負担を軽くしてくれるヤツだ

そいつはCSSもキャッシュするのだが、通常のwebページなどは、設定によって定期的にキャッシュをクリアするがCSS/JSは手動でクリアしないと、差し替えてくれない仕組みになってた

そんなんで、時間が経っても変更したCSSが書き換わらず、break-word が効いてなかったのだ

そいつをクリアして無事URLが折り返ってくれた

チャンチャン

※wpのテーマによっては、英文が折り返るようにCSSが書かれているのもある

参考:https://w3g.jp/blog/confusing_word-break_word-wrap

Word Pressの子テーマ使用時の注意_001/Google AdSens

ワードプレスで子テーマを使っている時の注意点_001

子テーマを使う目的とは、親テーマを直接カスタマイズとか追記すると、アップデート時に上書きされて、デフォルトに戻ってしまう事を回避する為だよね

しかし Google AdSens の認証コードを貼りつける位置は、<head>タグの直後と指定されている

テーマを自作している場合なら良いけど、誰かの作ったテーマを使う場合は、必ずしも子テーマで追記したモノが期待した場所に挿入されるとは限らない

オレの場合、yhiraさん が配布してくれている Simplicity2 を使用しているサイトで、アドセンスの認証時にこの問題に直面した

<head>タグの直後でなくてもイケそうな気がするが、指定の場所以外に貼りつけて、認証は通ったとしても、その後 Google 側で変更があり不具合が起こるリスクもあるので、やはり指定されている方法で運用したい

なのでとりあえず、子テーマ(Simplicity2 child)では無く、親テーマ(Simplicity2)の header.php に Google AdSens の認証コードを直接貼りつけた

当然、親テーマのアップデート後に再度、追記をする必要がある

この程度なら自力でカスタマイズして解決できる気もするので、ヒマな時にチャレンジしてみよう

とりあえず、忘れない為に書いたとさ

Simplicity: https://wp-simplicity.com/