7のイベントを再登録するWindows7/8/10でRustを別ドライブに展開する際のTIPSPHP+SQLでMySQLのInnoDBのテーブルに複合キーかつ連番のINSERTを実装するネイティブなPHPでselectタグやradioボタンの選択状態をどう表現するかエンターキーによる入力項目のフォーカスの移動をWeb系システムに実装してみるCattleMute>WordPress>テーマカスタマイザーのスタイルを外部CSSにする2017.09.20テーマカスタマイザーのスタイルを外部CSSにするリニューアル用のテーマを作っているときに、当お題目をやろうとして悩んだこと。通常、WordPressでテーマカスタマイザーでは、$wp_customizeを使ってカスタマイズ項目を並べていく。こいつを実際にユーザーが見るページに反映させようとすると、wp_headかwp_footerにフックして<style></style>を出力。カスタマイザーで設定したスタイルをこの中に書いていかなければならないと言う状態になってしまう。自分もこのならいに則って今まで同じようにしぶしぶCSSを前時代的に書き出ししていた。wp_headにフックした際はこれだと設定できるスタイル項目を増やすと<head></head>の中でえらい文字数になる。いって、wp_footerでフックしようものなら、transitionとかを行っている要素部分で遅延したアニメーションが発生してしまう。カスタマイザーを本格的に使い出すようになって、ああこれどうしようもねーやみたいなことを思っていたが、同時にこれはとても引っかかっていた部分だ。今回のリニューアルで、その辺も少しステップアップしようかと思い、このスタイルを外部CSSとして扱うようにしたいと思った。俺が知っている情報と、プラグイン情報しか出ねぇ・・・いやいや、それでも同じようなこと考えてる人は絶対にいるだろうし、少しはあるでしょ?と思って10分ほど調べてみたがうんともすんとも。いう手順でそいつを書き出すかをまずは練った。従来通りの方法で、$wp_customizeを使って項目に設定したスタイルシートの文字列を作っておく。そいつをset_theme_modでテーマ用のオプション値(theme_mod)へ保存させる。どのタイミングで保存させるか?そりゃもちろんテーマカスタマイザーで保存をした後でしょう。オプション値を参照させて外部CSS内のスタイルシートの文字列を動的に出力する。3を飛ばして1→2→4→5はうまく行った。問題は3のテーマカスタマイザーで保存をした後にどうやってテーマ用のオプション値(theme_mod)を挿入&更新してやるか。ここが俺の一番の問題だった。WordPressのことならなんでも書いてるWordPressのコーデックスへGO。customize_registerだとかcustomize_preview_initその他ちょこっとしか書いてなかった・・・。いやいや、カスタマイズAPIの使用法のことなんかどうだっていいんだ・・・。こんなのTwentyFifteenからコピーできるし。いうわけでカスタマイザーのフックをWordPressの公式(英語)で再度お勉強。辞書を片手に読む始末。前のMagento2で導入したり弄ったりしていた間は多少なりと辞書なくても読めるようにはなっていた。時が過ぎたせいでボケた。・・・やっと見つけたよ。「customize_save_after」ってフックあるじゃん。これで俺の思っている外部CSSが実現できる・・・ということで、ここからソースコード。$wp_customizeでテーマカスタマイザーでのオプション値の挿入&更新は問題なく設定できるようにしておくことが前提なので割愛。テーマカスタマイザーとかの設定をfunctions.phpに直書きしている事前提で話は進めようと思う。(自分はお作法にならってカスタマイザー関係はインクルードしてるけど。'theme_customize_save_after');まずは、一番悩んだ部分からだ。「customize_save_after」でフックしてオプションの保存を実行する。上記の書き方で、$wp_custmizeでset_theme_modでのオプション値更新が来た後にテーマオプション値の’site_styles’がセットされる。'theme_customize_styles');#theme-customize-preview-stylesは、自分はライブプレビューの際に’postMessage’を使用してスタイルシートをJS使って追記させているから。それはどうでもいいが、それより大事なのが、get_template_directory_uri().’/theme-css.php’のところ。こいつが、テーマオプション値の’site_styles’を元にして動的に生成される外部CSS。そいつを読み込んでいる。get_theme_mod('site_styles');上記を「theme-css.php」という名前でfunctions.phpと同階層へ配置。require_once()でインストールしているWordPressのwp-load.phpを読み込む。【wp-load.phpのあるディレクトリ】とは書いているが、普通にWordPressを使っている場合、十中十でwp-load.phpはWordPressをインストールしたディレクトリ直下にある。これはインストールしたディレクトリからfunctions.phpを見た場合であれば、WPディレクトリ→wp-contentディレクトリ→themeディレクトリ→テーマ本体のディレクトリとなる。当該の部分の指定は相対パスで「dirname(__FILE__).’/../../..’」となる。これで「theme-css.php」で、get_theme_modの他、WordPressの関数が全て使用可能になる。これがキモだが、この「theme-css.php」というPHPファイルにはtext/cssヘッダーを付けてブラウザ側にはCSSと認識させる(昔からよくある技法)。書いたPHPのコードはちゃんと実行される。以上で、自分の求めていた動作ができるようになった。・・・やはりまだ引っかかるのが、冒頭でも書いたように同じようなこと考えてる人は絶対にいるはずなのに中々それを公開してらっしゃるサイトが見つからないこと。あるWeb制作でのワンオフ型のテーマ作成だと、時短のためにBootstrapにテンプレート関数ぶっこんで行くだけだし、そもそもテーマカスタマイザー自体がワンオフ型の制作には使わない機能なのかもね。PHPを外部CSSとして扱う手法は昔からあるし、わざわざ書く必要がないからみんな書いてないだけかもしれないけど。PM面白い記事だなと思いました。私はインラインに吐き出す方法を調べていたので、むしろファイルに出来るんだーって感心しました。テーマカスタマイザーを使うようになると色々悩みますよね・・・ただ、気になったのはそこまでやるならtheme-css.cssにしちゃえば良いのでは?と思いました。都度cssを吐き出させれば影響も無いのでは?ともかく、ありがとうございました。PMコメントいただきありがとうございます。実はコメントのいただいた通り、当時は実体ファイルの書き出しをできないかとも頭の片隅で考えていました。fopenやfwrite等でCSSファイルを生成して書き込むのは確かにカンタンです。WPではMovableType等のCMSと違ってファイルを書き出すタイミングが常に択一・一様というわけはないので、特にカスタマイザーのようにタイミングが不定(手軽に更新できる)だとファイルにデッドロックが生じやすいのです。他にもブラウザキャッシュの問題等もあって、しっちゃかめっちゃかになった記憶があります。スクリプト系で独自のアプリを作るときにファイルを読み書きする際は、ファイル名を一旦ハッシュ化したり、日付時刻や処理者名等にしてしまって最終的に挿げ替えてそれを回避するのですが・・・。そこまでの機能をテーマ側にガリガリとコード書いてパフォーマンスを悪くしたり、リスクを組み込むのも気が引けました。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。