web-dev-qa-db-ja.com

テーマオプションのベストプラクティス（前方互換性）

だからここに私が思っているのは...

あなたはみんなOption-treeとテーマ作者が彼らのテーマオプションページのために使用している同様のフレームワークについて知っています。また、3.4 WordPressから彼らのカスタマイズAPIが導入されたことを皆さんも知っています。明らかに、彼らはテーマ作者にフレームワークの代わりにそれを使わせたいと思うでしょう。それはネイティブなので、そして明らかにこれは良い方法になります。

しかし、それらは1つの問題です... WPカスタマイザは十分なスペースを提供していません。あなたがこれらのようなオプションがあると想像してみてください。

enter image description here

それらすべてをカスタマイザにインポートする方法を考えることができます。これは、ソーシャルリンク、レイアウトオプション、背景パターンオプションなどにも当てはまります...

私が考えることができる1つの方法はこれらのために別々の管理者ページを作成することです...しかしあなたがそのアプローチを得るならばあなたはあなたのオプションのための少数の異なるページをもたらすでしょう。

それで我々は何をすべきですか？

あなたの考えを教えてください。

theme-developmentthemestheme-options
4
ZK_

スペースが唯一の問題である場合は、カスタマイザーパネルの幅を通常の300ピクセルから500ピクセルに拡張するために、これらの行を使用して管理領域にCSSファイルを単純にエンキューできます。

.wp-full-overlay-sidebar {width 500px !important;}
.wp-full-overlay.expanded {margin-left:500px !important;}

あのね、jsファイルをエンキューして、幅の異なるボタンを挿入することもできます。カスタマイザAPIは、必要なすべてのフィールドを含めるのに十分な柔軟性があります。ですから、スペースは大きな問題ではありません。

本当の問題は、カスタマイザに組み込むものとその整理方法です。たとえば、Anthony Hortinによる この優れた概要 を読んでください。テーマ開発者は、カスタマイザで自分のクライアントに対処するのに最適なオプションと、オプションページに残すべきオプションを検討する必要があります。

1
cjbj