スターターテーマvs親テーマ？長所と短所

私が働いている会社の他のウェブサイトの例として使用されるテーマを作成しています。別のプロジェクトでは、Hybrid Parent Themeを使用し、構築は非常に簡単でしたが、Webサイトを維持するのは非常に困難でした。

別の開発者がテーマをコピーしてそこから作成する、スターターテーマのアプローチを好みます。Parent-> Childは、開発者がコードをめちゃくちゃにする自由を与えすぎます。例えば、私は子供に何かが呼び出されているのか、親に呼び出されているのか知りませんでした。

私はあなたから聞きたいです：

• 親テーマの方が良いときは？
• スターターテーマの方が良い場合は？
• それぞれの長所と短所は何ですか？

ありがとう。

Rarstに完全に同意します。ちょっとしたものを追加したいだけです。

注：親テーマとフレームワークを区別しています。私の回答では、TwentyElevenのような親テーマを検討します。このテーマは主に特定のWebサイト用に作成され、フレームワークよりもフックが少ないものです。

スターターテーマ：

長所

• HTMLレベルで簡単にカスタマイズできます。<div>特定の要素のためのオープンなカスタムCSSクラスのようなものを意味します。これは、親テーマが提供する多くのものが必要ない（または少なくとも親テーマ/フレームワークを使用する場合は、それらを削除するためにフックする必要がある）個人用ブログの最小限のテーマを作成するための良い方法です。iframe親テーマを使用するよりもはるかに簡単に、別のWebサイトを参照するHTMLのようなHTMLの特別な部分や単に「Helloテキスト」をエコーすることもできます。
• 小さなことを変更するためだけに、親テーマからテンプレートファイルを複製する必要はありません。
• フックマップ、カスタム構文、カスタム関数などのような新しいものを学ぶ必要はありません。これらのことは開発者が愛するものですが、すべてのユーザーではありません。

短所

• それはだとしてスターターあなたが怠け者ならあなたがいることを行うにはしたくないかもしれないCSS、カスタムテンプレート、など：あなたは、あなたのテーマを成し遂げるために多くのことをしなければなりません！

親テーマ：

長所

• style.css色やフォントサイズなど、細い線を変更するだけで簡単に調整できる完成したデザインです。
• であるあなたはそれがなどのコメントテンプレート、シングルページテンプレート、のようなものを気にせずにすぐにあなたのことができることを意味し、完成したテーマ
• 誰かがあなたのために作ってくれました！

短所

• 親テーマは、要件にほぼ一致する場合は適切であると考える必要があります。そのため、調整をできるだけ少なくすることができます。そうでなければそれは悪夢です
• カスタマイズの能力は高すぎません。ここのフレームワークで見ることができるフックシステムを意味するわけではありません（以下のフレームワークを参照）。強くカスタマイズしたい場合は、ほとんどのテンプレートファイルを書き直す必要があります。つまり、テーマを再作成することになります。これは、親テーマを使用する目的ではありません。

フレームワーク：

長所

• すべてが利用可能です。フレームワークはオールインワンソリューションとして作成されることが多いため、あらゆるタイプのWebサイトを作成する優れた機能を備えています。カスタムロゴが必要ですか？カラーピッカー？ドラッグドロップ？テーマのレイアウト？...すでに手に持っています。
• 慣れていれば、ウェブサイトをより速く構築できます
• フレームワークが提供する多くのものを変更するためにユーザーが多くの場所にフックできる完全なフックシステムを持っています
• 高度なカスタマイズ：フックシステムだけでなく、Catalystなどの多くのフレームワーク、Headwayを使用すると、CSSやフックに触れることなく、管理者のほぼすべての要素をカスタマイズできます。

短所

• ユーザーは、フレームワーク（フックシステム、その機能、設定、さらには新しい用語に慣れる）を効率的に使用するために学習する必要があります。私はこれをフレームワークの最大の欠点と考えています。WPにはすでに多くの学習すべきことがあり、すべてのユーザーがWPをよりよく使用するためだけに新しいことを学びたいわけではないからです。これらのことは開発者が愛するものですが、すべてのユーザーではありません。ユーザーは、を使用するだけで、学習やカスタマイズはしません。
• 冗長コード：フレームワークの一部が重複を引き起こすWP機能と一致しています。例を示すことができますgenesis_meta()（私たちが持っているので必要ありませんwp_head）。
• パフォーマンス：フレームワークには必要なすべてのものがあるため、>>使用しない可能性があるadmin / frontendに必要なすべてのファイルをロードする必要があります。この点で、私はハイブリッドコアがファイルをロードする方法（require_if_theme_supports関数を使用して）を好みます
• 多くの場合、デフォルトの外観は最小限で見栄えが悪いです。私たちはデザインを完成させるために多くの努力をしなければなりません。スターターテーマを使用している場合もプロセスは同様ですが、スターターテーマのようなカスタムテンプレートの代わりにフックを使用します。
• フレームワークは、フレームワークを構築するさまざまな方法につながる独自の哲学を持っています=>多くのフレームワークにつながります=>どれが私たちに最適かわかりません（特に、プレミアムの場合）。上で述べたように、フレームワークは開発者にとって良いものであり、開発者はコードを深く調べてそれがどのように優れているかを確認する必要があるので、それはあまり良くありません！フレームワークがプレミアムの場合、そのドアが検索されます。

最後に：すべてのスターターテーマと親テーマとフレームワークは、最終的な結果を達成するためにカスタマイズするのが簡単であれば、どのサイトでも使用できます。すべての状況に対して1つの解決策があるわけではありません。最も手助けしてくれるものを選択する必要があります。おそらく今回はスターターテーマが適切ですが、別の時点ではフレームワークです。ちなみに、これらすべてを使用することで、テーマを作成するときだけでなく、多くの状況で役立つ多くの経験を得ることができます。

テーマのワークフローのバランスは、いくつかの要素の組み合わせです。

• コードの量、サイトごとに
• サイト間で共有されるコードの量
• 上流の変更を組み込む

これらはそれぞれ重要であり、重要ではない場合があります。

親テーマのモデルを満たす合理的にこれらのすべてではなく、非常にうまく。共有コードと個々のコードを明確に分離できるだけでなく、アップストリームの直接的な更新（サードパーティの親テーマを使用している場合）も得られます。要件が通常より大きくなると、バラバラになり始めます-サードパーティの親テーマに簡単に混在させることができない多くの個別コードまたは多くの共有コード。

一方、スターターテーマは非常に特殊なモデルです。それは個々のサイトを支持しますが、上流の変更と共有コードを嫌います。あなたがスターターテーマをあなた自身のものにするとすぐに-コードを出し入れするすべての負担はあなたにあります。

新しい傾向は、フレームワークが親テーマを完全に実行するのではなく、プラグインのようなコンポーネントに分離することです。親テーマとしてハイブリッドに精通している場合は、ハイブリッドコアを調べてください。このアプローチは基本的に親/子の上での改善であり、テーマ全体ではなくフレームワークに制限されることにより、アップストリームの更新が容易になります。

一言で言えば（ここで少し主観的になります）：

• スターターは個々のサイトに適合
• 親/子はあまりカスタマイズされていない複数のサイトに適合
• フレームワーク/親/子は、あらゆるものに適応できますが、開発にもより関与します

親テーマを使用する主な理由は、更新を容易にするためです-テーマを取得して直接編集した場合、元のテーマが更新された場合は、行った変更を再適用する（または元の変更をマージする）必要があります変更したテーマに戻します）。