スターターテーマ対親テーマ？長所と短所
私は働いている会社のための他のウェブサイトのための例として使用されるテーマを構築しています。別のプロジェクトでは、私たちはHybrid Parent Themeを使用していて、作成は本当に簡単でしたが、Webサイトを維持するのは本当に困難でした。
他の開発者がテーマをコピーしてそれから作成するスターターテーマのアプローチが好きです。 Parent-> Childは、開発者がコードをめちゃくちゃにするための自由度が高すぎます。例えば、私が何かが子供または親のどちらで呼ばれているのか知りませんでした。
私はあなたから聞きたいのですが。
- 親のテーマが良いときは？
- スターターテーマが優れている場合
- それぞれの長所と短所は何ですか？
ありがとう。
Rarst に完全に同意します。ちょっとしたものを追加したいだけです。
注：親テーマとフレームワークを区別します。私の答えでは、主に特定のWebサイト用に作成され、フレームワークよりもフックが少ないTwentyElevenのような親テーマを検討します。
スターターテーマ：
長所
- HTMLレベルで簡単にカスタマイズできます。特定の要素のカスタムCSSクラスである
<div>のようなものを意味します。親テーマが提供する多くのものを必要としない個人用ブログの非常に最小限のテーマを作成するのに良い方法です（または、少なくとも親テーマ/フレームワークを使用する場合、それらを削除するにはフックする必要があります）。また、別のWebサイトを参照するiframeや、親テーマを使用するよりもはるかに簡単な「Helloテキスト」など、HTMLの特別な部分をエコーすることもできます。 - 小さなことを変更するだけのために親テーマからテンプレートファイルを複製する必要はありません。
- フックマップ、カスタム構文、カスタム関数などの新しいことを学ぶ必要はありません。これらのことは開発者が愛するものですが、 all ユーザーではありません。
短所
- スターターなので、CSS、カスタムテンプレートなど、テーマを完成させるために多くのことを行う必要があります。怠けすぎている場合は、そうしたくないかもしれません。 ！
親テーマ：
長所
- 色、フォントサイズなどを変更するなど、
style.cssの小さな行を変更することで簡単に調整できる完成したデザインがあります。 - Is は完成したテーマです。つまり、コメントテンプレート、単一ページテンプレートなどを心配せずにすぐにテーマを作成できます。
- 誰かがあなたのために built を持っています！
短所
- 親テーマは、要件にほぼ一致する場合は、適切と見なす必要があります。そのため、可能な限り微調整することができます。さもなければ、それは悪夢です
- カスタマイズの能力は too highではありません。ここのフレームワークで見ることができるフックシステムを意味するものではありません（以下のフレームワークを参照）。強くカスタマイズしたい場合は、ほとんどのテンプレートファイルを書き換える必要があります。これは、テーマを再作成することを意味し、それは親テーマを使用する目的ではありません。
フレームワーク：
長所
- すべてが利用可能です。フレームワークは、多くの場合、オールインワンソリューションとして作成されるため、あらゆるタイプのWebサイトを作成する優れた機能を備えています。カスタムロゴが必要ですか？カラーピッカー？ドラッグドロップ？テーマのレイアウト？ ...すでに手元にあります。
- Webサイトをより速く構築する if 使い慣れている
- ユーザーがフレームワークが提供する多くのものを変更するために多くの場所でフックできる完全なフックシステムを持っています
- 高度なカスタマイズ：フックシステムだけでなく、Catalyst、Headwayなどの多くのフレームワークでは、CSSやフックに触れることなく、管理者のほとんどすべての要素をカスタマイズできます。
短所
- ユーザーhas toフレームワークを学習し（システムをフックし、その機能、設定、さらには新しい用語に習熟し）、それを効率的に使用します。 WPには学習すべきことがたくさんあり、WPをより良く使うためだけにすべてのユーザーが新しいことを学びたいわけではないので、私はこれをフレームワークの最大の欠点と考えます。これらは開発者が愛するものですが、すべてのユーザーがそうするわけではありません。ユーザーは、使用だけで、学習もカスタマイズもしない人です。
- 冗長コード：フレームワークの一部は、重複を引き起こすWP機能と一致しています。例として
genesis_meta()を使用できます（wp_headがあるため必要ありません）。 - パフォーマンス：フレームワークには必要なものがすべて揃っているため、管理者/フロントエンドに必要なすべてのファイルをロードする必要がありますが、これらはまったく使用しない可能性があります。この点では、Hybrid Coreがそのファイルを読み込む方法を好みます（
require_if_theme_supports関数を使用して） - 多くの場合、デフォルトの外観は最小限で不適切です。設計を完成させるには、多くの作業が必要です。スターターテーマを使用している場合のプロセスは似ていますが、スターターテーマのようにカスタムテンプレートの代わりにフックを使用します。
- フレームワークには、フレームワークを構築するさまざまな方法につながる独自の哲学があります=>多くのフレームワークにつながります=>どのフレームワークが最適かはわかりません（特にプレミアムの場合）。上記で述べたように、フレームワークは開発者に適しているため、開発者はコードを詳しく調べて、それがどのように優れているかを確認する必要があります。フレームワークがプレミアムなら、そのドアが見えます！
最後の事：すべてのスターターテーマと親テーマとフレームワーク /あらゆるサイトに使用可能 if 最終結果を達成するためにカスタマイズする必要があります。すべての状況に対応するソリューションはありません。どれが最も役立つかを選択する必要があります。おそらく今回はスターターテーマが良いのですが、もう1つはフレームワークです。ちなみに、それらすべてを使用することで、テーマを作成するときだけでなく、多くの状況で役立つ多くの経験を得ることができます！
テーマワークフローのバランスは、いくつかの要素の組み合わせです。
- サイトごとのコード量
- サイト間で共有されるコード量
- 上流の変更を組み込む
これらのそれぞれが重要になることがあり、これらのそれぞれが重要ではないことがあります。
親テーマモデルはこれらのすべてを合理的には十分に満たしていますが、 非常に /ではありません。共有コードと個々のコードが明確に分離されているだけでなく、直接的なアップストリームの更新（サードパーティの親テーマを使用している場合）が得られます。通常よりも要件が大きくなると、それはバラバラになり始めます。つまり、サードパーティの親テーマでは簡単に混在させることができない、大量の個別コードまたは大量の共有コードです。
一方スターターのテーマは非常に特殊なモデルです。それは個々のサイトを支持しますが、アップストリームの変更と共有コードを嫌います。スターターテーマを自分のものにするとすぐに、コードを出し入れする負担はすべてあなたにあります。
最近の傾向は、完全に親テーマを実行するのではなく、フレームワークをプラグインのようなコンポーネントに分離することです。あなたが親のテーマとしてHybridに精通しているならば、Hybrid Coreを調べてください。このアプローチは本質的に親子の上での改良であり、上流の更新は全体のテーマではなくフレームワークに限定されることによってより容易にされた。
一言で言えば（ここで少し主観的になります）：
- スターターは個々のサイトに適合
- 親子はあまりカスタマイズしなくても複数のサイトに適合
- framework/parent/childは何にでも適応することができますが、開発にはもっと複雑です。
親テーマを使用する主な理由は、簡単に更新できるようにすることです。テーマを直接編集して元のテーマが更新された場合は、行った変更を再適用する必要があります。変更したテーマに戻ります。