いやー、最近かなりバグの報告をいただいていて、なかなかブログの更新ができませんでした。
とにかく相手の症状を理解し、原因探し、解決策考え…。
なんとか最近落ち着きました。いやー、疲れました。
外国の方はあまりWordPress.orgのサポートフォーラムは使わないのでしょうか。。直接のメールの問い合わせが多かったです。
（2～5件/1日、でも英語での問い合わせはかなり大変）
今回もほぼすべてのプラグインをアップデートしました。
- Announce from the Dashboard
- Archive Posts Sort Customize
- Screen Options and Help Show Customize
- Media Insert from Themes Dir
- CUSTOM OPTIONS PLUS POST IN
- Post Lists View Custom
- Js Css Include Manager
- WP Admin UI Customize
一部のプラグインは機能追加を加えたりしています。
あと、全てWordPress 3.6 にて動作確認済みです。
更新するまでの経緯
ユーザーから寄せられるバグの症状をひとつひとつ見ていっても、なかなか”これだ”という原因が見つからず、よくある「他のプラグインの影響じゃないだろうか」という事を想定して原因を探っていました。
ただここで、症状を報告した方が色々試した結果「あなたのプラグインを使用している場合だけこういう症状が出ます」と調べていただたいた場合はありがたいです。
●●●のプラグインを一緒に使うとバグがありました～とか（バグではないですが）、使っていてこういうバグが出ますよーと教えてくれる場合は、なんとか改善の方法を検討をする事ができますが、「ヘイ、どうなってんだよ。動かないじゃないか」みたいな報告の場合、かなり厳しいです。
どうなっているのか調べたいけど、「動かない」とだけ言われても分からない。
分かるなら、直してますよ～。。 🙁
（そんなことはおいといて）
ただ今回、ひつとだけ、いつもと違うバグ報告をいただきました。
そのバグの原因を探る為に、プラグインの影響やテーマ、WordPressのバージョンやPHPの設定等をもとに原因を探っていたのですが、全く見当外れな所でした。。 😳
ちなみに、私は英語が得意ではありませんので、バグ報告をいただいた際に、「ごめんなさい、キャプチャを送っていただけませんか？」とお願いすることが時々あります。（というより、最近は画面を見せたほうがスムーズに解決すると感じています）
その際、「自分の画面はなるべく見せたくない」という方が多いと思います。
（特に管理画面に関しては）
なので、プラグインの設定画面”だけ”送ってもらう場合が多いので、その部分だけで原因がどこにあるのかを考えていました。。
これが、原因を探すことができない原因でした。。 😳
どんなに調べても、原因不明。
次に、バグ報告をいただいた方の中に、どでかい画面キャプチャを送っていただけた方がいました。
（操作している画面を動画で送ってくれた方もいました。これは非常に助かりました。 🙂 ）
そして、キャプチャと同じように設定したりしてみましたが、相変わらず。。
プラグインの設定画面に原因があると思いひたすら探っていましたが、やはり見つからず。
う～ん。分からない。（こういう時はノートPCを(￣ ￣ )ノ⌒）
一息ついて、ふと、キャプチャを再度よく見てみると、アドレスバーにhttps。
SSLでの管理画面への接続でした。
あ、確かにSSL環境での動作確認はしていなかったな～。でも、SSLでも使えるとは思うけどな。
とりあえず確かめてみないと分からないものは分からない。という事でxampp内のOpenSSLを利用して試してみました。
そして、やっと原因が分かりました。
SSLの場合だけ上手く動作しなかった
不正確ですが、一言で言うならこんな感じのバグです。
少しだけ正確に言うと、プラグインでJavascriptを読み込むように設定しています。
そのJavascriptでjQueryのSortableやDropable等を設定しているので、データが変化します。最終的にユーザーが保存するデータは、ソート後のデータです。
そしてそのソートを行う為には、その処理を記述しているJavascriptファイルが読み込み出来なければ、もちろんソートすらも出来ません。
そしてSSLの場合だけ、そのJavascriptファイルが読み込まれない、というバグでした。
ただ、よく分からないのが何故SSLの環境だけ？と思いました。
以前からSSLの環境でプラグインを使っている方はおそらくいると思うのですが、なぜ今になってそんなバグ…？ユーザーが増えてきたから？
と色々考えても仕方ないので、実際に試してみたら…動きました…。SSLでも。 😕
う～ん、やっぱりSSLでも動くよね。。
その後も色々試行錯誤＆バグ報告くれた方と色々とやりとりをしていて、やっと分かりました。
正確に言うと、「管理画面へのアクセスはSSL、フロントへは通常のhttp」。
「アクセス」。なるほど。気づきませんでした。 🙄
今回の方はおそらくですが、「サイトのURL(home)及びWordPressのURL(siteurl)もhttp、でも管理画面にアクセスするときだけはhttps」という環境で使っているのではないかと考えました。
SSLで試すという事で、私のほうでは動作確認の為に、WordPressのインストールからサイト及び管理画面の閲覧まで全てhttpsの環境で全て試していました。
おそらくこのバグ報告をくれた方は、インストール時はhttpでインストールしたのか、または途中でhttpに変更したのか。等をおこなったのではないかと思います。
何をしたのかはおいといて、そのような環境を想定して試してみることに。
そりゃ、いくらget_option(‘siteurl’)とかを使って、CSSファイルやJavascriptファイルを読み込もうとしても、アクセスしているプロトコルはhttpsだったら読み込めないよね。 😎
で、私の場合プラグインディレクトリ内のCSSやJavascriptファイルを読み込む際に、
WP_PLUGIN_URL . '/' . dirname( plugin_basename( __FILE__ ) ) . '/'
という風にプラグインディレクトリのURLパスを取得していました。
この WP_PLUGIN_URL が https:// で管理画面にアクセスした場合、https://にならずにhttp://のままでした。
get_option('siteurl') . '/wp-content' . '/plugins'
このように取得・設定している為です。
get_option(‘siteurl’)では、いくらhttpsでアクセスしても、一般設定にて設定されているhttpでのURLを取得するのでダメでした。
ただ私は詳しくは分かりませんが、分かることとしては、Google Chromeの場合、https:// で呼ばれる画面から http:// のファイルにアクセスさせない仕組みのような感じでした。（具体的には何の影響でそうなるのかは分かりません。セキュリティ的な意味合いな気はしますが）
なので、全プラグイン、WP_PLUGIN_URL は使わず、
plugin_dir_url(__FILE__)
これにしました。
これだと、set_url_scheme が間に入って、WP_PLUGIN_URLで取得したアドレスに対してhttpやhttpsも書き換えてくれるような感じでした。というか、こっちで動くならこっちのほうがいいですね。シンプル。 😮
（なんか、WordPressのデバッグ機能を有効にしたら「この関数よりこっちの関数のほうがいいですよ」みたいな表示を出してくれたら嬉しいな。。便利な関数があったとしても、存在が分かりません。。）
で、これで試してもらうと無事動作したようでした。
今回のケースはたまたまどでかいキャプチャと、動画ファイルをいただけたのでなんとか解決までに至りました。
めでたしめでたし 🙂