web-dev-qa-db-ja.com

私のコードをどこに置くか：pluginまたはfunctions.php？

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

そのトピックについては、 are _ { manyケース _、そして多くの 議論 _があります。私は意見ではなく事実に基づいて答えを求めています。

それはこれらの点（そしておそらくそれ以上）をどのように扱うかを説明するべきです：

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

双方に賛否両論がしばしばあります。私たちの最も人気のある質問 あなたのfunctions.phpファイルのためのコードのベストコレクション は少なくとも議論の余地がある答えとしてたくさんのコードスニペットを得ました。
初心者が理解できる基準、おそらくチェックリストが必要です - 理由があります。

メタサイトのChip Bennettによる関連質問も参照してください。 特に「プラグインなしで」解決策を求める質問

関連： ここで見つけたコードスニペットはどこにありますか、それともWeb上の他の場所にありますか？

custom-post-typesplugin-developmenttheme-developmentwidgetsshortcode
86
fuxia

私はこの質問から始めるでしょう： 機能は表示コンテンツの、または生成/管理コンテンツの、サイトの、またはユーザーID）に関連していますか？

機能性 関連性がない 特にコンテンツの表示）に関連するものであれば、プラグインテリトリーの範囲内です。このリストは長いです。

  • Core WPフィルタ（正規リンク、ジェネレータ、その他のHTMLメタなどのwp_headの内容を変更する、など）
  • サイトファビコン
  • コンテンツ後のショートコード
  • 投稿共有リンク
  • Google Analytics（および類似の）フッタースクリプト
  • SEOのツール/コントロール
  • 等.

機能 関連している がコンテンツの表示になっている場合、それはテーマに含まれている候補になっています。この時点で、 @ Raf912のテーマ切り替え基準に戻ります） ： テーマを切り替えたときに機能を見逃してしまいますか？ その質問に対する答えが いいえ の場合、機能はテーマに属します。

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

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

カスタム投稿タイプ

たとえば、カスタム投稿タイプは、テンプレート階層が単一投稿タイプ アーカイブインデックスページ および 単一投稿ページ の場合の動作方法を考えると、コンテンツの生成と表示のちょっとユニークな組み合わせです。 CPTのコンテンツ生成の側面は、通常、それらをPlugin Territoryに正当に配置します。ただし、プラグインでは、特定のテーマのデザイン/レイアウト/スタイルに本質的に適合するテンプレートページを定義することはできません（特にCPTが通常のタイトル/コンテンツ/メタ以外に表示される場合、またはカスタム分類に関連付けられている場合）。

長期的に見て、この格差の解決策である私見は、与えられた種類のコンテンツ（不動産リスト、カレンダーイベント、電子商取引商品、書籍/メディアライブラリのエントリなど）のCPTの定義に関する標準的な慣習/合意を得ることです。 。）このようにして、テーマ開発者はテーマテンプレートファイルでそのCPTのデザイン/レイアウト/スタイルを定義する柔軟性を維持しながら、ユーザー生成コンテンツは特定のCPTの標準/規約定義を実装するテーマ間で移植性を保ちます。

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

同様に、ソーシャルメディアのプロファイルリンクは、現在のテーマではほとんどどこにでもあるが、presentationof content）とは無関係であるため、プラグインテリトリーであると私は通常言う。コアのどこかで定義されていますが、現在のところこれらのリンクを定義するための標準的な/合意された方法はありません。テンプレートに？など.

長期的に見ても、この格差の解決策は、これらのリンクが定義されている場所をコアで定義するか、またはテーマ開発者コミュニティが独自の合意を開発することです。それまでの間、それはそれぞれのテーマの中で定義されたままにしておくこと以外には本当に何もありません。

71
Chip Bennett

コードが最適な場所に配置されている簡単なテスト

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

  • あなたはその機能性を逃しますか、ブログがきちんと動いていないか、または古いテーマの断片（例えばショートコード）が残っていますか？

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

    • いいえ：functions.phpに残してください

例：ショートコードを書く。テーマを切り替えた後、プレーンショートコードはあなたの投稿に残されます。だからそれはより良いプラグインに配置されるでしょう。

最後のコメントを一覧表示する関数を書きます。テーマを切り替えた後は、他のテーマにも同等の機能があるため、すべて問題ありません。

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

49
Ralf912

この質問に簡単に答えることはできないと思いますが、その決定に役立つフローチャートを作成できると思います。これはそのようなフローチャートの大まかな概要です。提案でコメントする！

  • このコードはWordPressのシングルサイトインストールでホストされるべきですか？
    • はい - サイトのテーマは大幅なデザイン変更や機能の変更によって変わるだけですか？
      • はい - 問題のコードは 現在の設計に固有のものです ？
        • はい：functions.php
        • いいえ：プラグイン
      • いいえ（頻繁にまたは気まぐれに変化します） - プラグイン
    • いいえ（マルチサイト） - マルチサイトインストールをホスティングしていますかORプラグインを許可するホスティングマルチサイトソリューションですか？
      • はい：問題の機能は このサイトに固有のものですか？ またはネットワーク内の他のサイトで使用できますか
        • このサイトに特有のもの：functions.php
        • 複数のサイトで共有 - すべてのサイトでそれを強制しますか？
          • はい：mu-pluginsディレクトリに保存されているか、ネットワークで有効化されているプラ​​グイン
          • いいえ：これは 無関係の サイトのネットワークですか？ （例：異なるクライアント）
            • はい：クライアントAが、クライアントB、C、およびD用に書いたプラグインを見たりアクティブにしたりした場合、それは悪いことであるか、それとも専門的でないことでしょうか。 （例えば、サイトを破壊したり、望ましくない機能を引き起こしたりする可能性があります）
              • はい：functions.php
              • いいえ：プラグイン
            • いいえ：おそらくプラグイン
      • いいえ（VIPのようなプラグインを許可しないサービスによってホストされています）：functions.phpを使用してください
  • 親テーマ - 時には共有機能を使う場合は、親テーマを作成してその機能を親テーマのfunctions.phpファイルに入れるほうがよいでしょう。
  • 大規模なマルチサイトインストールのプラグインディレクトリはすぐに手に負えないものになる可能性があるため、低い割合のサイト（たとえば1％未満）で使用される共有機能がfunctions.phpファイルで複製するのが最善の方法です。
17
Matthew Boynes

ここから テーマ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パーマリンク設定
5
Brad Dalton

私はこれが死んだ馬であり、Chipがそれをほぼカバーしていることを知っていますが、少し考えを加えたいと思いました。

あなたが生計を立てているプログラミングをする そしてあなた自身が期限内にワードプレスサイトに取り組んでいるのに気づいたなら、あなたはそれが本当に時間がかかることに気付くでしょう。

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

あなたが準定期的にwordpressに取り組んでいるなら、/ - 真剣に次のことをすることを検討するべきです ：

  1. プラグインスケルトンを作成する

これは、有効化、無効化、バージョンの更新、管理パネルの構築、アンインストールなど、プラグインに関して一般的に必要なことすべてを処理するはずです。

あなたがこれをする時間を作るならば、あなたは見つけるでしょう：

  • プラグインを介して機能を追加するのに余分な時間がかかることはもうありません。
  • 必要に応じて他のプロジェクトで再利用するためのプラグインの堅実なリストを作成し始めることができ、長期的に見て自分自身の時間を大幅に節約できます。
  • あなたがより多くの可視性が欲しいならば、あなたはそれらを公に利用可能にすることができます

これで物事を適切に構築できます - そして - 将来のプロジェクトをより早く完成させることができます.

  1. テーマスケルトンを作成する

これはテーマで一般的に必要とされるすべてを扱うべきです：

  • よく使うスタイルを含むコアスタイルシート（リセットなど）
  • テンプレートに必要なものすべてを扱う適切なindex.phpファイル
  • Functions.phpファイル - あなたはそれをほとんど使うことはないでしょう、しかしそれはまだ役に立ちます。

それが終わったら、あなたの主要テーマを使用する子テーマスケルトンを構築します。

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

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

上記の手順を実行した場合は、以下の作業を行うことができます。

  • PHP、WordPress、JavaScript、CSS、および/またはmySQLに慣れるために、新しい自由な時間を過ごしてください。これらの知識を深めるほど、作業が早くなります。
  • 改善すべきものが見つかったら、プラグイン、テーマ、および子テーマのスケルトンを更新します。あなたがどれほど優れていようとも、学び続けるなら、あなたは改善がなされることに気付くでしょう。

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

4
Privateer

簡単な答えはこれです。

コードは特定のテーマに組み込まれた機能のいずれかに依存していますか？もしそうなら、テーマを入れてください。

このコードをサイト間およびテーマ間で転送可能にしますか？もしそうなら、プラグインを入れてください。

答えが上記の両方にノーであれば、それからそれが再設計のための時間であるときに、5年後のサイトを描きます。あなたが書いているコードの機能は、次回のデザインアップデートで生き残るものでしょうか。もしそうなら、プラグインを入れてください。

また、あなたが子供のテーマを使用していなくて、あなたがテーマを更新することを計画しているならば、私はあなたがプラグインを使うことも提案するでしょう。

2
CO4 Computing