にしし ふぁくとりー(西村文宏 個人サイト)

Presented by Nishishi via Movable Type. Last Updated: 2017/08/12. 14:00:27.

Sakura Scope (2017年06月)

ちょっと倒錯気味な、ただの日記です。(^^;)
これはやばいと思われた場合は、お早めに閲覧を中止されることをお勧め致します。

エンジニアのためのWordPress開発入門

技術評論社から今年頭あたりに出た解説書「エンジニアのためのWordPress開発入門」、読みやすくまとまっていて、情報量も多くて、とても役に立つ本でした。
WordPressを使ってウェブサイトを丸ごと(=WordPressの独自テーマを1から)作ろうとする場合や、WordPressのシステムを使って何らかのサービスを開発しようとするような、WordPressの仕組みを把握して何を触ればどうできるのか?を全般的に知りたい場合に便利だと思います。

エンジニアのためのWordPress開発入門

解説文が読みやすいですし、一覧を示す箇所では表で見やすくまとめられていますし、後から資料として参照する場合にも役立ちそうです。

: : :

以下は、単なる自分用のメモ(後から参照するために付箋を貼付した場所のメモ)です。(^_^;;;

  • 第1章 WordPressとは
  • 第2章 環境の準備
  • 第3章 基本機能
    • p.25 : デバッグなどに関連したWordPressの定数
  • 第4章 プラグインによる機能拡張
    • p.67 : BackWPupプラグイン (WordPressファイル一式、データベースなどの定期バックアップができるプラグイン)
    • p.97 : WP Total Hacksプラグイン (WordPressでよく実施するカスタマイズを管理画面上から設定できるプラグイン)
    • p.101 : その他の便利なプラグイン
  • 第5章 WordPressの基本アーキテクチャ
    • p.113 : 投稿タイプの追加
    • p.145 : 2つのメインクエリ変数 $wp_query・$wp_the_query
    • p.151 : WP_Queryオブジェクトのクエリフラグを確認するメソッド (is_singleとかis_pageとかの一覧と説明)
    • p.155 : テンプレート階層図
    • p.157 : テンプレートタグとループ (簡単なテンプレートの例(メインループ、部分テンプレートのロードなど))
    • p.162 : get_posts()を使ったループ (ソース例)
  • 第6章 テーマの作成・カスタマイズ
    • p.177 : テンプレートの書き方 (メインループ the_post()で取得可能なデータ一覧)
    • p.178 : メインループの記述例
    • p.179 : the_post()のコール後にサブループで使用可能な関数一覧
    • p.192 : 作成したテーマのチェック
  • 第7章 プラグインの作成と公開
  • 第8章 投稿データと関連エンティティ
    • p.214 : 投稿タイプの登録例
  • 第9章 投稿データの検索・取得
    • p.272 : ページ送りに関連するパラメータ一覧
    • p.277 : setup_postdata()関数の使用例
    • p.279 : クエリフラグを取得する主なメソッド一覧
    • p.280 : ページ送り関連情報の取得(ページ送り関連のプロパティ一覧)
    • p.286 : pre_get_postsアクションの基本的な使用例 (メインクエリ中のWP_Queryに対して行える操作)
    • p.287 : 検索結果から固定ページを除外するソース例、アーカイブの種類に応じた表示件数の設定ソース例
  • 第10章 ユーザーと権限
  • 第11章 管理画面のカスタマイズ
    • p.310 : トップメニューの各メニューを隠す主なAPI、トップメニューを隠すソース例
    • p.314 : メニューの並び替えソース例
  • 第12章 その他の機能やAPI
    • p.341 : 主なサニタイズ関数一覧
    • p.342 : 出力値のサニタイズ(解説と書き方)
    • p.349 : 登録したJavaScriptを必要なときのみ出力 wp_register_script()、wp_enqueue_script()
    • p.358 : 範囲を囲うショートコード
    • p.360 : ウィジェットエリアの登録

これからWordPressを直接カスタマイズして何かを作ろうとしたり、WordPressのテーマを1から作ろうとする場合には、読んでおくと役に立つのではないかなと思います。

うちのサイトを概ねHTTPS化した(SSL証明書は年額1,152円で安かった)

うちの個人サイトが概ねHTTPSでアクセスできるようになった気がします。まだ深部までは確認できていないんですけども。少なくとも主要なコーナー内のページは大丈夫そうです。たぶん。^^;
今の時点では、HTTP→HTTPSの強制リダイレクトはしていませんから、従来通りHTTPでアクセスした場合はHTTPのままです。ブラウザのアドレス欄に https://www.nishishi.com/ のように、httpsと打てばHTTPSでアクセスできます。
すると、ブラウザのアドレス欄にめでたく鍵マークが付加されます。もちろんレベル1(最も低いレベル:ドメイン認証)のSSL証明書ですから、鍵マーク以外は何も付きませんけども。

HTTPSでのアクセスが可能になった。

SSL証明書を取得したのは昨年末なので、もう半年前になるんですが。(^_^;)

HTTPS化作業で面倒なのは

SSL化(HTTPS化)作業で面倒なのは、参照するファイルのURLをプロトコル名「http://」から書いてしまっている場合ですね。以下のような感じで。

href="http://www.example.com/hoge/file.js"

画像の読み込みが「http://」で書かれている場合なら、単に鍵マークに警告が付加されるだけで表示自体に問題はありません。
しかし、CSSやJavaScriptの読み込みが「http://」で書かれている場合は、そのファイルが読み込まれないので困ります。

それでも、自サイト内にあるファイルであれば、以下のどれかに修正すれば解決はします。数が多いと大変ではありますが、対処は可能ですね。

  • 相対パスでの記述に変える:href="./file.js"
  • 絶対パスでの記述に変える:href="/hoge/file.js"
  • プロトコル名を省略した絶対URIでの記述に変える:href="//www.example.com/hoge/file.js"

問題は、外部サイトに存在するファイルを読み込みたい場合です。
これはもう、その外部サイトがHTTPSで読み込ませてくれないなら諦めるほかないわけですが。(^_^;;;
1つずつ、http://をhttps://に修正してアクセスしてみて、ちゃんと反応が返ってくるかを確認して修正するしかないですね。
一部非対応のサービスがあったので、それはもうすっぱり諦めて使うのをやめました。(先方サービスの放置具合からして、たぶん今後もSSL対応はなされなさそうだったので。^^;)

なお、「HTTPSページ内で、HTTPなファイルを読み込む」と警告が出たり読み込めなかったりしますが、その逆の「HTTPページ内で、HTTPSなファイルを読み込む」には何ら問題はありません。
なので、HTTPSで読み込める外部サイトのファイルは、全てhttps://から書いて読み込めば良いでしょう。

SSL証明書は、GeoTrustのRapidSSLをさくらインターネット経由で契約

SSL証明書は、GeoTrustのRapidSSLで取得しました。さくらインターネット経由で契約すると3年で3,456円でしたので、年額換算1,152円でそこそこ安かったので。
とりあえず取得したのは www.nishishi.com に対してだけなので、サブドメインや他のドメインはまだHTTPのままです。
Let's Encryptで無料のSSL証明書を試そうかなとも思ってはいます。他のドメインで。ただ、3ヶ月毎の更新は面倒だなとは思いますが。

サブドメイン単位の証明書だと、ウェブサイト内のコーナーをディレクトリではなくサブドメインで分けているような構造のサイトはSSL対応が大変ですね。(^_^;) ワイルドカード証明書を取得すればサブドメインを一括して含められますが、料金がそこそこしますし。
ここ最近になって一気にSSL化が進んだのは、間違いなくGoogle(Chrome)の新方針の影響ですよね。
Googleパワーで、もっとSSL証明書の維持費が安くなってくれれば良いんですけども。というか、Googleが無料にしてくれても良いんじゃ……。(^_^;;;

Chromeでの「保護されていない通信」警告

しかし私が直接「ああ、これはもうSSL対応しないとダメだな」と思ったのはFirefoxの警告(下図)でしたが。^^; さすがに入力欄にこんな警告(「安全ではない」に加えて「漏洩する可能性があります」とまで)を出されたら、避けたいと思いますよね……。^^;;;

Firefoxでの「漏洩する可能性があります」警告

どういう基準で判定しているのか分かりませんが、ログイン画面だけでなく、ただのBBSの投稿欄でもこのように表示される項目がありました。
まあ、Googleも最終的には警告対象を全サイトに広げたいと言っていますから、いずれはこのようにあらゆるページで警告されるようになるのでしょうけども。

独自ドメインで運営されているサイトはともかく、プロバイダ提供スペースやその他の無料スペースではどうなるんでしょうかね? 早々にSSL対応しないと、ユーザが他のサービスに引っ越してしまう気がしますが。

何らかの事情でSSL対応を中止する可能性があるなら、302でリダイレクトする方がいい?

今のところ私のサイトでは、HTTPでもHTTPSでもどちらでもアクセスできます。特に強制的なリダイレクトはしていません。
サイト内の全ページで本当にHTTPSで問題ないかどうかが確認できていませんから。(^_^;)
rel="canonical" でも、まだHTTP側のURLを書いていますから、たぶん検索結果にもHTTP側がヒットし続けるのではないかと思います。(rel="canonical"を書いていないページも多々ありますが。)

最終的に、HTTPでのアクセスを可能にしていると不利になってきた場合にはリダイレクトを設定するとは思います。
ただ、少なくとも最初の実験段階のうちは、HTTP→HTTPSのリダイレクトは、301よりは302の方が無難そうですね。

HTTPステータスコード301でリダイレクトすると、リダイレクト先URLをブラウザがキャッシュするので、次回からは元サーバにアクセスすることなくリダイレクト先URLに直接アクセスされるようになります。
つまり、もし http://www.nishishi.com/ から https://www.nishishi.com/ へ301でリダイレクトさせると、たとえリダイレクトの設定を解除しても、(1度リダイレクトしたことのあるブラウザでは)http://側のリンクを踏んだとしても、キャッシュされた情報を参照して問答無用でhttps://側にアクセスしてしまいます。
こうなると、何らかの原因でSSLを廃止したときに困ってしまう気がします。
まあ、SSLを廃止しなければ良いのですが。(^_^;)
(302でリダイレクトした場合にはブラウザはリダイレクト情報をキャッシュはしないようなので、SSLを廃止した場合には元のURLにアクセスできます。)

ググってみたところ、HTTP→HTTPSのリダイレクトでは、301でも302でも検索対策上の差はないっぽいので。
もちろん余計なリダイレクトは発生しない方が望ましいわけですが。要は、検索結果にはHTTPS側が出ていれば余計なリダイレクトは発生しないわけですから、問題はないかな?とも思います。

さくらインターネットでSSIを使う際、include virtualは絶対パスでの記述が必須

さくらインターネットのカスタマーセンターから、サーバが高負荷になっているとの警告が届きました。
サーバの過負荷解消のために、当該ファイルのパーミッションを000に変更して実行を一時的に制限したとのこと。
当該ファイルというのは、プログラムではなく単なるSHTMLファイルです。ただのHTMLですが、SSIを使って他のファイルを合成しています。

サーバのコントロールパネルからリソース情報のグラフを見てみると、確かにCPU使用時間がどかんと増えていました。

CPU使用時間

また、サーバのエラーログを確認すると、以下のようなエラーが1秒間に686回も発生していました。
そりゃ高負荷になりますよね……。

Request exceeded the limit of 10 subrequest nesting levels due to probable confguration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
unable to get information about "products.shtml" in parsed file /home/***/www/products.shtml

(24)Too many open files: file permissions deny server access: /home/***/www/products.shtml
unable to include "./common/ssi/submenubar-products.html" in parsed file /home/***/www/products.shtml

上記で問題になっている products.shtml は最終更新が2015年のファイルだったので、もう2年以上そのままです。その間、少なくとも高負荷で警告されるほどのエラーはありませんでした。
実は、この手のエラーが発生して負荷が高まったのは今回が初めてではありません。
ただ、ファイルの読み込みが無限ループになっちゃっているらしいということは分かるものの、なんで「ただ外部ファイルを合成しているだけのSSIで発生するのか?」が分からなかったので根本的な解決ができていなかったのですが。

今回のカスタマーセンターからの警告文には、対処方法も書いてあったので、ようやく分かりました。

SSIでファイルを合成するときにinclude virtualを使うなら、対象ファイルは絶対パスでの指定が必須

どうやらSSIでinclude virtualを使う際には、合成ファイルを絶対パスで指定しなければならないようです。
私は、一部のページではinclude virtualの値を相対パスで記述していました。これが原因だったようです。
早速、include virtualの記述を以下の通り絶対パスに書き換えました。

危 <!--#include virtual="./path/to/include.txt" -->

正 <!--#include virtual="/path/to/include.txt" -->

この場合は単に「.」記号1つを消しただけですが。
相対パスではなく「/」で始まる絶対パスになっています。

そもそもなぜ相対パスでincludeすると無限ループに陥るの?

ただ、なぜ相対パスでファイルを合成すると無限ループのエラーが発生するのかが分かんなかったのですが。
ググってみると理由を解明した方がいらっしゃいました。

→「さくらインターネットに怒られた件」(@ClockRoom)

どうやら、SSIのinclude virtualで相対パスを使って合成しているウェブページに、PATH_INFO付きでアクセスされたときに、なぜか自分自身がインクルードされることによって無限ループが発生するようだとのこと。
なんでそうなるのかは分かりませんが……。
とりあえず、SSIでファイルを合成するときには、絶対パスで書かないと無限ループが起きてしまう可能性がある、ということは分かりました。^^;

たいてい合成したいファイルは「離れた場所にある合成ファイル用のディレクトリ」にまとめてあるので、絶対パスを使っています。
ただ、最上階層に置いてあるファイルでは、何故か(自身のディレクトリより下位にあるだけなので)相対パスを使っていたのでした。

うーむ。まさかこんなことが原因だったとは。
しかし原因が分かってスッキリしました。
今後も気をつけよう。(^_^;)

2017年06月
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

他の月

--- 当サイト内を検索 ---