テーマのプラグ可能な機能をオーバーライドする方法は？

私が遭遇したすべてのドキュメントは、プラグインを介してプラグイン可能な関数をオーバーライドすることについて説明しています。

代わりにテーマ開発を行っている場合はどうなりますか？

私のfunctions.phpにはget_user_by()、で定義されている関数をオーバーライドする別のファイルが必要ですpluggable.php。

if( function_exists() )呼び出しを省略すると、「再宣言できません...」というエラーが表示されます。

if( function exists() )呼び出しを含めると、エラーは発生しませんが、プラグイン可能なバージョンが存在するため、もちろん、関数は無視されます。

WordPressの起動順序に関するDominicのすばらしい投稿に基づいて、テーマなどの前にpluggable.php読み込まれることが明らかであるfunctions.phpため、エラーが説明されています。

だから問題は-テーマと一緒にバンドルまたはインストールする必要のあるプラグインを作成することに頼らずに、テーマ内からその優れたプラグイン可能なアーキテクチャをどのように利用できるかということです。

追記：だから、議論はテーマがプラグインがすることをしようとするべきではないということだと思われます。しかし、その議論は（4桁のトラック番号によると）4年以上前のものです。今日のテーマ開発風景の複雑なトポロジーを考えると、この哲学がまだ当てはまるかどうか、何人かのヘビーヒッターから聞いてみたいです。それ以来、私たちが進化してきたと信じたいです。

コンテキスト：多くのカスタムメタデータ、管理バックエンドのカスタマイズ、ログイン/認証プロセス、機能を備えた、お客様向けの1回限りのCMSソリューションを開発しています。そしてもちろん、設計コンポーネントがあります- 。テーマ部分の出番だ事実は、これらは単純にしているされていない再利用可能なコンポーネント-彼らは別のクライアントに適用されることはありません、彼らはGPLの下に置かれることはありませんし、オープンソース化し、彼らが最もあり確かに他のWordPressデプロイメントに配布/インストールしないでください。せいぜい、将来のプロジェクトで活用するいくつかのベストプラクティスがありますが、それは厳密には参照/コピーアンドペーストジョブです。

これは私にとってプラグインの使用例のようには聞こえません。テーマがインストールされ、おそらくTwenty Elevenの子テーマ、スタンドアロンである可能性があります。そのfunctions.phpは、インクルードのボートロードで呼び出し、それぞれが問題のCMSの異なる側面を処理します。次に、テーマテンプレートファイルは、インクルードで定義されているカスタムの「テンプレートタグ」を使用します。プラグインなどの依存関係がアクティブ化されているテーマファイルを使用したくありません。システムに複雑さを組み込むのは意味がありません。もちろん、私はそれを必須プラグインフォルダに入れることができますが、それでもハックのように感じられます-現在、このプロジェクト用に行われたカスタマイズに関係するすべてのものがに含まれていwp-content/themes/my-theme/ます。また、一部のプラグインフォルダーでコンテンツを検索することも検討する必要はありません。

誤解しないでください。プラグインが大好きで、プラグインを使用して作成しています。そして、プラグインがサードパーティであり、妥当な期間内に展開できる可能性のあるベストプラクティスをはるかに超えている場合、私はプラグインをこのような高度にカスタマイズされたテーマ開発と組み合わせて使用​​します。ただし、1回限りのシナリオでコア機能を変更する必要がある場合は、アクションフック、フィルターフックに切り替え、ユーザーおよびプラグイン可能な機能に依存して、ユーザー側と認証側の両方にも対応できるようにしたいと考えています。

これを単一のクライアント用に構築する場合は、絶対にを利用する必要がありmu-pluginsます。

WordPressには、でできないことがたくさんありますfunctions.php。プラグ可能な関数はその1つですが、もっと明白なのは、前にいくつかのフック（アクションとフィルターの両方）が起動することfunctions.phpです。場合によっては、これらのフックは通常のプラグインの前にmu-plugins起動することもあり、その場合は、またはネットワークでアクティブ化されたプラグインを使用する必要があります。さらに他の場合では、muプラグインでさえ手遅れです。多分あなたは何かが必要ですsunrise.php。またはの何か（定数またはその他）wp-config.php。

プラグイン可能な関数にいくつかのフックを追加したいのですが、それらをオーバーライドしやすくするためです。もう1つのプラグイン可能な関数が再び存在する可能性はほとんどありません。それらはフックより前のものであり、古き良き（新式の）フックよりも利点がある状況はほとんど見たことがありません。

6年後も、Andy Skelton氏に同意します—「テーマの関数ファイルとプラグインの間には多くの違いがあります。そのままにしておきましょう。」

それはさておき、このような変化は決して起こりえません。それは多くのことを壊します。その本体で無数のテーマが関数を呼び出すと、やのようにまだロードされていないfunctions.php場合、致命的なエラーが発生します。それらはすべて失敗します。そして、それはプラグインも壊します、それは通常これらの関数の呼び出しを開始する可能性があります。（下に移動するだけで、コアの半分が壊れるかもしれません。少なくとも、カスタマイザが壊れるでしょう。）pluggable.phpcurrent_user_can()wp_create_nonce()plugins_loadedpluggable.phpwp-settings.php

最後に、pluggable.phpプラグインをロードすると同時にロードできるようにテーマに別のファイルを含めることができるため、プラグイン可能な関数をオーバーライドできるという必然的なアイデアがあります。これは悪い考えですが（このコメントの最初の4段落を参照）、互換性はありません。setup_themeフックまでは、スタイルシートとテンプレートの値をフィルタリングすることで、ロードするテーマをオーバーライドできるためです。

残念ながら、WordPressがどのように構築されているかを考えると、これは適切ではありません。良いことは、それを行うには無数の（より良い）方法があることです。

（もともとここに投稿：http : //core.trac.wordpress.org/ticket/2479#comment:5）

一度限りのプロジェクトのコンテキストでは、必須のコードをにドロップすることが絶対に適切mu-pluginsです。「すべてを1か所にまとめる」ことが懸念される場合は、テーマディレクトリにmu-pluginsドロップインへのシンボリックリンクを作成して、テーマディレクトリを検索すると表示されるようにします。

ロードシーケンスの早い段階で、これを達成する方法を思いつきません。

正しいソリューションに最も近いのは、wp-config.php（コードまたはユーザーに要求することによって）カスタムインクルードを追加することですが、そのバンドルプラグインと比較することはおそらくより意味があります。