コードを配置する場所：pluginまたはfunctions.php？

プラグインまたはテーマに属するコードの種類を決定するための簡単なスキームはありfunctions.phpますか？

あります 多く の場合、多くの議論そのトピックについては、ワードプレスの内部の仕組みに関するいくつかの誤解がある主な理由は、。私は意見ではなく、事実に基づいて答えを求めています。

これらのポイント（およびおそらくそれ以上）の処理方法を説明する必要があります。

• カスタム投稿タイプと分類
• お問い合わせフォーム
• ショートコード
• カスタムウィジェット
• add_theme_support( 'automatic-feed-links' );
• カスタムmeta要素のようなSEO機能
• テーマスイッチ

多くの場合、両方の長所と短所があります。functions.phpファイルの最も人気のあるコードのベストコレクションには、少なくとも議論の余地のある答えとして多くのコードスニペットがあります。
初心者が理解できる基準、おそらくチェックリストが必要です。それには理由があります。

メタサイトのChip Bennettによる関連する質問も参照してください。「プラグインなしで」ソリューションを具体的に求める質問

関連：ここで見つけたコードスニペットをWeb上のどこに配置しますか？

私はこの質問から始めます：機能はコンテンツのプレゼンテーションに関連していますか、それともコンテンツ、サイト、またはユーザーIDの生成/管理に関連していますか？

機能がコンテンツの表示に特に関連していない場合、プラグインテリトリー内にあります。このリストは長いです：

• コアWPフィルターの変更（wp_head標準リンク、ジェネレーター、その他のHTMLメタなどのコンテンツ
• サイトファビコン
• コンテンツ後のショートコード
• 投稿共有リンク
• Google Analytics（および同様の）フッタースクリプト
• SEOツール/コントロール
• 等

機能がコンテンツの表示に関連している場合、それはテーマに含まれる候補です。この時点で、私はに戻るでしょうRaf912のテーマスイッチの基準@：あなたがテーマを切り替えたときに機能を欠場でしょうか？その質問に対する答えがnoの場合、機能はテーマに属します。いくつかの例：

• WPコアギャラリーCSSの削除/オーバーライド
• 投稿の抜粋の長さ、「続きを読む」テキストなどのフィルタリング
• 経由で実装されたものadd_theme_support()（これは明らかなはずです）
• カスタムCSS

通常、これら2つの質問は、かなり明確な差別化ラインを提供します。ただし、例外があります。

カスタム投稿タイプ

たとえば、カスタム投稿タイプは、テンプレートの階層が単一投稿タイプのアーカイブインデックスページと単一投稿ページで機能する方法を考えると、コンテンツ生成とプレゼンテーションのユニークなハイブリッドのビットです。CPTのコンテンツ生成の側面では、通常、プラグインテリトリー内に配置されます。ただし、プラグインは、特定のテーマのデザイン/レイアウト/スタイルに本質的に適合するテンプレートページを定義できません（特に、CPTが通常のタイトル/コンテンツ/メタ以外を表示する場合、またはそれに関連付けられたカスタム分類がある場合）。

長期的には、この格差の解決策であるIMHOは、特定の種類のコンテンツ（不動産リスト、カレンダーイベント、eコマース製品、書籍/メディアライブラリエントリなど）のCPTの定義に関する標準的な規則/コンセンサスを持つことです。）。そのようにして、ユーザーが生成したコンテンツは、特定のCPTの標準/慣習の定義を実装するテーマ間で移植可能になり、テーマ開発者は、テーマテンプレートファイルでそのCPTのデザイン/レイアウト/スタイルを定義する柔軟性を保持します。

ソーシャルメディアリンク

同様に、現在のテーマではソーシャルメディアプロファイルのリンクはほぼすべての場所に存在するが、それらはコンテンツの表示とは何の関係もないため、プラグインテリトリーであると通常言います。最善の解決策は、これらのプロファイルをコアのどこかに定義することです。ただし、これらのリンクを定義するための標準/コンセンサス手段は現在ありません。それらはサイト設定レベルで最もよく定義されていますか、それともユーザーごとに定義されていますか？ユーザーごとの場合、どのユーザーのメタがテンプレートで公開されますか？等

繰り返しになりますが、この格差に対する解決策は、コアがこれらのリンクを定義する場所を定義するか、テーマ開発者コミュニティが独自のコンセンサスを開発することです。それまでは、各テーマ内で定義されたままにする以外に何もありません。

コードを最適に配置する簡単なテスト：

• functions.phpにコードを書きます
• テーマを切り替える

• 機能が欠けている、ブログが適切に機能していない、または古いテーマの断片（ショートコードなど）が残っていますか？

  • はい：プラグインに入れます

  • no：functions.phpに残します

例：ショートコードを記述します。テーマを切り替えた後、投稿にはプレーンショートコードが残ります。そのため、プラグインに配置する方が適切です。

最後のコメントをリストする関数を作成します。テーマを切り替えた後、他のテーマに同等の機能があるため、すべてが問題ありません。

それは本当にコードとそれが何をするかに依存します。一部のコードはテーマのスタイリングまたはコンテンツにのみ影響し、他のコードはブログ投稿を変更します。

この質問に対する簡単な答えはないと思いますが、決定を支援するためにフローチャートを作成できると思います。このようなフローチャートの大まかな概要を以下に示します。提案にコメントしてください！

• このコードは、WordPressの単一サイトインストールでホストされますか？
  • はい-サイトのテーマは、機能の大幅な再設計と変更によってのみ変更されますか？
    • はい-問題のコードはこの現在の設計に固有ですか？
      • はい：functions.php
      • いいえ：プラグイン
    • いいえ（頻繁にまたは気まぐれに変更されます）-プラグイン
  • いいえ（マルチサイト）-マルチサイトインストールをホストしていますか、それともプラグインを許可するホスト型マルチサイトソリューションですか？
    • はい：問題の機能はこのサイトに固有ですか、それともネットワーク内の他のサイトで使用できますか？
      • このサイトに固有：functions.php
      • 複数のサイトで共有-すべてのサイトで強制しますか？
        • はい：プラグイン、mu-pluginsディレクトリに保存されるか、ネットワークで有効化されます
        • いいえ：これは無関係なサイトのネットワークですか？（例：異なるクライアント）
          • はい：クライアントAが、クライアントB、C、およびD用に作成したプラグインを表示またはアクティブにした場合、それは悪いまたは専門家ではないでしょうか？（たとえば、サイトを壊したり、望ましくない機能を引き起こす可能性があります）
            • はい：functions.php
            • いいえ：プラグイン
          • いいえ：おそらくプラグイン
    • いいえ（プラグインを許可しないVIPなどのサービスによってホストされます）：functions.phpを使用します

• 親テーマ-共有機能がある場合は、親テーマを作成し、親テーマのfunctions.phpファイルに機能を配置する方がよい場合があります。
• 大規模なマルチサイトインストールのプラグインディレクトリはすぐに手に負えなくなる可能性があるため、functions.phpファイルで複製するのが望ましいサイトの割合が低い（1％未満など）場合があります。

ここからテーマVSプラグイン

子テーマにカスタムコードを追加して、親テーマを更新するときにカスタムコードが失われないようにします。

すべてのカスタムコードを含むサイト固有のプラグインを作成することもできます。

コードとプラグインの記述に関しては、プラグインとその機能を使用できますが、ほとんどの場合、手作業のコーディングが最も簡単です。 'テーマ開発者です。

 function modify_contact_methods($profile_fields) {

// Add new fields
$profile_fields['twitter'] = 'Twitter Username';
$profile_fields['facebook'] = 'Facebook URL';
$profile_fields['gplus'] = 'Google+ URL';

return $profile_fields;
}
add_filter('user_contactmethods', 'modify_contact_methods');

http://codex.wordpress.org/Plugin_API/Filter_Reference/user_contactmethods

1. 新しいカスタム投稿タイプを追加- コード
2. ユーザーに新しいフィールドを追加-上記のコード
3. 新しいウィジェットの追加- コード
4. カスタムパーマリンクの追加-WordPressパーマリンク設定

私はこれが死んだ馬であり、Chipがそれをほとんどカバーしていることを知っていますが、いくつかの考えを追加したかったです。

生計を立てて、期限内にワードプレスサイトで作業していることに気付いた場合、それは本当に時間通りになっていることがわかります。

多くの場合、特に始めたばかりの人にとっては、必要なものをテーマに追加して完了と呼ぶ方がはるかに速く簡単です。

とはいえ、ワードプレスを半定期的に使用する場合は、次のことを真剣に検討する必要があります。

1. プラグインスケルトンを構築する

これは、アクティブ化、非アクティブ化、バージョン更新、管理パネルの構築、アンインストールなど、プラグインで一般的に行う必要があるすべてを処理する必要があります。

これを行う時間を作ると、次のことがわかります。

• プラグインを介して機能を追加するのに余分な時間はもうかかりません
• 必要に応じて、他のプロジェクトで再利用するためのプラグインの強固なリストの作成を開始でき、長期的には時間を大幅に節約できます。
• さらに可視性が必要な場合は、それらを一般公開することができます

物事を適切に構築し、将来のプロジェクトをより迅速に完了できるようになりました。

2. テーマスケルトンを構築する

これは、テーマで一般的に必要とされるすべてを処理するはずです：

• よく使用するスタイル（リセットなど）を含むコアスタイルシート
• テンプレートに必要なすべてを処理する適切なindex.phpファイル
• functions.phpファイル-ほとんど使用しませんが、まだ便利です。

それが完了したら、プライマリテーマを使用する子テーマスケルトンを構築します。

• 親テーマを参照するスタイルシートを追加します。
• functions.phpファイルを追加します

これらの2つのことを完了すると、人々のための新しいサイトの作成がはるかに速くなります。

上記を行うと、次の作業を行うことができます。

• PHP、WordPress、JavaScript、CSS、および/またはmySQLに精通して、新しく見つけた自由時間をお過ごしください。これらをより多く学べば、より速く物事を成し遂げることができます。
• 改善すべき点を見つけたら、プラグイン、テーマ、および子テーマのスケルトンを更新します。どんなに良い人であっても、学習し続けると改善が見られます。

そして、上記のすべてを行うと、Chipの答えが理想的であるだけでなく、最適になることがわかります。

簡単な答えはこれです。

コードは特定のテーマに組み込まれた機能に依存していますか？はいの場合は、テーマを入力します。

このコードをサイト間およびテーマ間で転送できるようにしますか？はいの場合、プラグインを入れます。

上記の両方の答えが「いいえ」の場合、5年後のサイトを再設計するときを想像してください。あなたが書いているコードの機能は、次の設計更新で生き残るものですか？はいの場合、プラグインを入れます。

また、子テーマを使用しておらず、テーマを更新する予定がある場合は、プラグインを使用することもお勧めします。