設定APIを使用するのが適切な場合と、テーマカスタマイザーを使用する方が適切な場合はいつですか？

午前中ずっとGoogleで検索してみましたが、この問題に関するよく考えられた最新のガイダンスを見つけることができませんでした。言うのはまだ早いですが、テーマカスタマイザーは、Squarespaceのような編集機能を取り入れるための示唆的な最初のステップだと感じています。テーマカスタマイザーを支持して設定APIを廃止する計画を知っている人はいますか？ゆっくりと進んでいくべきでしょうか、それとも設定APIに固執する方が良いでしょうか？彼らは隣り合って住むことができますか？もしそうなら、責任の分担はどこにありますか？

質問の前提には欠陥があります。カスタマイザーのAPIはないオプションの APIのではなく、オプションのプレビュー API。Customizer APIは、Settings APIまたはTheme Mods APIに依存して、2つのAPIのいずれかを介して追加された既存の設定のコントロールを登録します。

カスタマイザーはない-とすることはできません -登録/定義新しいすでに設定APIやテーマモッズAPIのいずれかを介して登録されていない設定を。別の言い方をすると、カスタマイザーAPIは、設定をデータベースに直接追加したり、データベースから直接設定を取得したりするAPIではありません。むしろ、カスタマイザーAPI は、設定APIまたはテーマMods APIのいずれかを使用して、データベースに設定を保存したり、データベースから設定を取得したりします。

したがって、カスタマイザーAPIは、既存のオプションAPIの 1つに代わるものではありません。むしろ、設定ページの代替です。カスタマイザーは、設定がSettings APIまたはTheme Mods APIのどちらを介して登録されているかを気にしません。そのような設定は、Customizerで混合して一致させることができます。実際、ほとんどの場合、このような設定は混在しており、カスタムヘッダーとカスタムバックグラウンドはテーマMods、サイトタイトルと説明はSettings APIです。

カスタマイザーAPIを介して設定とコントロールがどのように登録されるかを正確に理解するには、Ottoの優れたチュートリアルを読むことをお勧めします。

• テーマカスタマイザーを独自のテーマで活用する方法
• テーマカスタマイザーパートDeux：オプションページの削除
• テーマカスタマイザーのカスタムコントロールを作成する

だから、問題はないのいずれか/または指定のAPIに関して。適切などちらかまたは両方の質問は次のとおりです。

• 使用のいずれかの設定API やテーマモッズAPIする既存の設定を登録介して、プレビューにカスタマイザーのAPI
• 使用のいずれかカスタマイザのAPI やカスタムテーマの設定ページにユーザーを許可するのconfigureテーマオプション。

簡単なこともあります：Settings APIはTheme Customizerではありません。両方とも、タスクごとに異なります。

設定API

プラグインを書いているか、視覚的なフィードバックを必要としないオプションのないテーマを持っていますか？このオプションを選択してください。

テーマカスタマイザー

ユーザーが見ることができる視覚的な影響を持つオプションが必要ですか？このオプションを選択してください。