SSL設定がスクロールすると外れてしまったので修正してみた。

noimage

防備録として。

テーマを変えたからか、カスタマイズのやり方がまずかったのか分からないですが、何故かSSL設定が、postページで一定条件を満たすと外れてしまう現象がおこりました。

TOPや固定ページでは起こらないのに、記事ページでそれが強制的に発生します。

 

発生する条件としては、

  1. 記事の単独ページ(single.php)でしか発生しない。
  2. ページを読み込んだ時はちゃんとhttpsになっている。
  3. 前後記事のナビが出るタイミングで鍵マークが強制的に外れてしまう。
  4. 一度外れたらリロードしない限り戻らない。

という感じでした。

 

以上の条件から、怪しいと思っていた部分は記事のナビゲーション関係とアドセンスだったのですが、どちらも該当していないことを確認。

デベロッパーで頑張って原因を探ってみたら、犯人は外部リンクでした。

ただ、どこでそのリンクを引っ張って使用しているのかが分からず、直接URLをhttpからhttpsに修正することが出来なくて詰む。

でも、コレを放置していても解決にはならないので、とにかく出来ることをやってみようというわけで、httpsの設定を見直すことに。

 

やったことその①:http→httpsに置き換えるプラグインを試す。

httpとhttpsが混在しているということは、どこかにhttpが紛れ込んでいるということなので、まずは、テーマを変えたときにhttpになってしまっているところがあるか、そしてそれを置き換えられるかを試しました。

SSL設定の時にhttp→https修正はSearch regexというプラグインを使用すると良いよと紹介されていたので、このプラグインを使ったことはありますが、今回は修正が出来なくても置き換えることが出来れば良いので、置き換え/解除が出来るというReal-Time Find and Replaceというプラグインを使用することにしました。

設定はとても簡単で、インストール→設定画面でhttpとhttpsを入力し、設定ボタンを押せばOK

だったのですが……このプラグイン、相性が悪いらしくて、入れた瞬間レイアウトがぶっ壊れました

なのでさっくりサヨウナラ。

となると、今度は選択肢から除外したSearch regexを使用して、どこにあるのかを調べることにしたのですが、検索したら関係ないものもバンバン引っかかるので、速攻で使用を停止しました。

この作業は、こちらのサイトさんを参考に行いました。自分の場合は原因が別にあったので解決しませんでしたが。

「このサイトへの接続は完全には保護されていません」の対処法|おじログ

SSL化したwordpressサイトでアドレスバーに「このサイトへの接続は完全には保護されていません」と表示されていたので、その原因と対処法を調べてみました。原因はいくつかあるようですが、今回の場合は「画像」が原因でした。

 

やったことその②:アドセンスのコードを確認する。

次に行ったことは、アドセンスのコードを確認することです。

外部リンク関係なら、一番可能性が高いのがココだと思ったので、アドセンスにログインして、広告のコードを確認いたしました。

が、ここはちゃんと、『//~』から始まるものに設定されていたので、コレは該当していないことを確認

作業自体は、コチラのサイトさんを参考に行っています。

 

やったことその③:デベロッパーで原因を探る。

怪しいと思っていた項目はどちらも該当しないことを確認したので、もう一度デベロッパーを見て見ることにしました。

警告は「mixed content」となっており、HTTPとHTTPSが混在しているから修正してと注意を受けている状態です。

ただ、何度見ても修正が必要ですとなっているURLの頭はhttpsとなっていたので、ここで混乱していました。(多分見間違えたんだと思われる)

そして、そのURLが一体どこに使用されているのかが全く分からないのが一番の問題です。

 

やったことその④:.htaccessにリダイレクト設定を追加する。

どこに原因があるのか特定出来ないのなら、いっそのこと.htaccessでリダイレクト設定を行えばいいんじゃね?という安直な考えから、ダメ元でやってみましたが……結果は何も解決しなかったです

でもまた、こういった作業をすることもあるかもしれないので、参考にさせてもらったサイトをペタリ。

WordPressの常時SSL化では、.htaccessの順序に注意! | Cherry Pie Web

WordPressサイトを常時SSL化する際、.htaccessによるリダイレクトができなくなってしまいました。

 

解決した方法:安全なリクエストに替えるようにブラウザへ指示する要素をヘッダーに追加した。

もう、コレ自力で直せないのかもしれない……と、諦め始めたときに見つけた方法が、リクエストの切り替え要素をヘッダーに書き込む方法です。

見つけたサイトはコチラ。

質問の回答にはこう書かれています。

Upgrade Insecure Requests を使用することで、安全でないリクエストを安全なリクエストに替えるようにブラウザへ指示することが可能です。

HTTP ヘッダに Content-Security-Policy: upgrade-insecure-requests を指定するか、<head> セクションに下記 <meta> 要素を追記することで有効になります。

設定する方法は2つあるらしいのですが、Content-Security-Policy: upgrade-insecure-requests を指定するにはどうすれば良いのか分からなかったので、手っ取り早くmeta要素で追記することにしました。

上記コードを<header>〜</header>の間に埋め込んで、修正ファイルをアップロードしてみたところ……

 
無事に鍵マークが復活したぁぁああああ!!!

漸く、警告文を消すことが出来ました。コレで鍵マークが復活だよ。良かった。

スポンサーリンク