SnippetテーマカスタマイザーAMPで表示テーマカスタマイザー2015年4月末に、公式テーマガイドラインが変更になりました。APIの利用が、義務づけられるようになりました。新規にWordPressにホストされるテーマは設定値を、add_theme_page()を使って、設定する事は出来なくなっています出来なくなったといっても、公式テーマレビューのルールなので、その方法が全く閉ざされたわけではなく、プラグインを別途制作して、プラグインインストーラーをテーマに組み込むといった方法をとれば、可能ではあります。カスタマイズ」画面を開発者がカスタマイズしたりコントロールを追加できるようにします。“テーマカスタマイザー”)ではサイト管理者がテーマ設定や色調、ウィジェットを変更したり、これらの変更をリアルタイムでプレビューきます。カスタマイザーページの画面構成WordPress4.2.2時点のカスタマイザーは、デフォルトで、320px幅の設定用のサイドバーと、テーマのプリビュー画面で構成されます。このページは、レスポンシブレイアウトで設計されており、640pxをブレークポイントとして、それ以下のブラウザサイズでは、プリビューが表示されず。ボタンによってプリビューに切り替えるように、構成されています。APIを持っています。テーマ開発者は、必要に応じてこれらのAPIをうまく使いこなす必要があり、ユーザーにとっては、よりシンプルな操作で、様々な設定を行うことが出来るようなる反面、ハードルは高くなります。等の関数で取得できる形式で保存されます。optionとして保存する事もできます。みたいになってしまいがちだと思いますが、意外と違うものなので、気に留めておいた方がよさそうなところもあります。従来は、テーマで使用可能な、optionフィールドは、一つという事に制限されています。テーマの開発者は、このフィールドに、設定値を配列などで保存し、取得や、変更は、開発者が工夫した関数などによって行われていました。関数で実装したものです。theme_modは、オプションフィールドのキーに、テーマスラッグが動的に付加されるように実装されています。保存場所は、どちらも、optionテーブルですtheme_modと、optionは何が違うのか?theme_modは、あくまでそのテーマ(チャイルドも含めて)に依存する情報として保存されるのに対して、optionは、テーマに依存しない情報として保存される点にあります。一般的にチャイルドテーマは、親テーマの機能を引き継いて、オリジナルのカスタマイズを簡単に行う事が出来ると言われていますが、theme_modを利用した場合には、テンプレートは、引き継がれますが、親テーマの設定は引き継がれなくなります。チャイルドテーマの設定値は、theme_modを使った場合は、親テーマのデフォルト値がセットされます。optionを使った場合は、親テーマの現在の設定値がセットされるという違いが発生します。あなたが、オリジナルのテーマを作成しているとします。そのテーマはWEBサイトで問題なく動作しています。ある時点で、WEBサイトのレイアウトに改良の余地がある事が判明し、改善を行おうとしています。ローカルで、チャイルドテーマを作成し、必要な部分の修正を行う事になるでしょう。ロゴの設定や、カテゴリ毎のヘッダー画像の設定を行っていたとします。theme_modを使っていれば、チャイルドテーマに切り替えた途端、ロゴの設定やカテゴリのヘッダー画像の再設定を行わなければならなくなります。(子テーマと、親テーマのオプション値が別々に扱われるので)optionを使っていれば、親テーマの設定が引き継がれるので、単に子テーマに切り替えるだけで変更が終了します(メニュー、ウィジェットの設定などコアで行っているヘッダー画像などは、設定しなおさなければなりませんが、、、)カスタマイザーから、簡単に設定が可能な項目数が多いほど、チャイルドに切り替える場合に、optionを使うか、theme_modを使うかで、使い勝手が異なってくることでしょう。これは、カスタマイザー以前では、大半がoptionを使っていたので、親の設定を自動的に引き継いでいたころの挙動とはかなり異なってくるという事です。theme_modを使用した場合は、親テーマの設定を引き継がないという点は、チャイルドテーマの使用用途として、親テーマで運用中のサイトを、チャイルドテーマを使って、カスタマイズし、アップデートをうまく進めようといった場合は、注意が必要です。同時に公式テーマディレクトリにホストされているようなテーマを考えてみましょう。この場合は、親テーマとは異なるオリジナル性が必要とされるため、大抵の場合親テーマのオプション設定とは異なる設定が必要になってくるでしょう。この事を考え合わせると、とても微妙な問題を含んでいます。APIがもたらすものユーザーは、テーマの設定変更を、リアルタイムで目で見て確認することが出来るようになります。これまで、開発者が思い思いに作り上げてきたテーマオプションページと異なり、テーマ毎のUIが統一される方向に向かっていくだろうと考えられます。「テーマはシンプルなほうがいい」という事が言われますが、ユーザーは、設定値をプリビューを確認しながら簡単に変更が出来るようになり、テーマそのものの構造的なシンプルさとは違った意味で、ユーザーは、シンプルさを体感できるようになるだろうと思います。APIは、公式テーマガイドラインで必須条件になったので、利用者も増大し、更に開発が加速する事は明白で、また、悪いものでは全くない。タグを付けるには、アクセシビリティレビューを受けなければならないといった。条件付きの達成項目でもよいのではないかと、個人的には、急激な変化に戸惑うところはある。テーマ開発者にとってみれば、これまで独自の工夫を行い、安定動作をしていたものを、テーマカスタマイザーに全面的にに変更しなければならないというのは、同情に値します。私は、ルールを作る側の人間でもなく、単にテーマ開発者です。課題を乗り越えることだけに集中するつもりです。wordpress.orgにホストしているRaindropsというテーマで、例示した例のような使用条件の場合に、親テーマのオプション値をチャイルドテーマに、Opt-inで一括インポートする機能が必要なのではないかと、考えています。設定値をチャイルドテーマでインポート可能にするカスタマイザーのスイッチを実装しました。)更新するためには設定を保存した後にブラウザのリロードが必要です。勉強しなくちゃなりません。勉強の紙くずを、メモに残していこうと思います。);}Raindrops1.433で保存フィールドの切り替えができるようになりました。Raindrops1.433にて、optionとtheme_modの切り替え機能を実装できました。'theme_mod';と記述する事で、optionフィールドを、theme_modに変更する事が出来ます。現在の保存先は、テーマカスタマイザーに以下のように表示されます。コメントは受け付けていません。tenman.info。