テーマでプラガブル機能を無効にするには？
私が遭遇したすべてのドキュメンテーションはあなたのプラグインを介してプラグイン可能な機能をオーバーライドすることを議論します。
代わりにテーマ開発をしているとしたら？
私のfunctions.phpはpluggable.phpで定義されているget_user_by()関数をオーバーライドする別のファイルを必要とします。
if( function_exists() )呼び出しを省略すると、 "Cannot redeclare ..."エラーが発生します。
if( function exists() )呼び出しを含めてもエラーにはなりませんが、もちろんプラグイン可能なバージョンが存在するため、関数は無視されます。
へのDominicの素晴らしい投稿 WordPressの起動順序 - /に基づいて、pluggable.phpがロードされているのは明らかです 以前 あなたのテーマのfunctions.phpなど、それでエラーが説明されています。
それでは、問題は、テーマにバンドルしたりインストールしたりしなければならないプラグインを書くことに頼らずに、どのようにしてそのテーマからその素敵なプラガブルアーキテクチャを利用できるかです。
その他の注意事項 ：つまり、テーマはプラグインの動作をやめようとすべきではないということです。しかし、その議論は4年以上前のものです（4桁の追跡番号によると）。今日のテーマ開発ランドスケープの複雑なトポロジーを考えると、この哲学がまだ適用されるかどうか私は何人かの大打撃者から聞きたいです。それ以来、私たちは進化してきたと信じています。
コンテキスト ：私はたくさんのカスタムメタデータ、Adminバックエンドのカスタマイズ、ログイン/認証プロセス、そして仕事をしながら、顧客のための一回限りのCMSソリューションを開発しています。そしてもちろん、designコンポーネントもあります - それがテーマの部分です。事実です、これらは単に not reusableコンポーネントです - それらは他のクライアントには決して適用されず、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の中には何か（定数など）もあります。
簡単に上書きできるようにするよりも、プラグ可能な関数にフックを追加したいと思います。私たちは二度と別のプラグイン可能な機能を持つことはないでしょう - それらはフックより前にあり、私はほとんど古き良き（新型の？）フックよりもそれらに利点がある状況を見たことがありません。
6年後のAndy Skelton氏にも同意します。「テーマの関数ファイルとプラグインの間には多くの違いがあります。それを維持しましょう。」
それだけでなく、このような変化は起こり得ませんでした。それは多くのことを破るでしょう。無数のテーマが、functions.phpの本体で関数を呼び出します。これは、pluggable.phpがまだロードされていない場合、致命的なエラーになります - current_user_can()、wp_create_nonce()のように。彼らはすべて失敗したでしょう。そしてそれはプラグインも壊してしまうでしょう、それは普通plugins_loadedでこれらの関数を呼び始めることができます。 （pluggable.phpをwp-settings.phpの下に移動するだけで、コアの半分が壊れてしまうでしょう - 少なくとも、カスタマイザは壊れてしまうでしょう。）
最後に、テーマにはpluggable.phpのような別のファイルを含めることができ、プラグインをロードすると同時にロードすることができるため、プラグイン可能な関数をオーバーライドできるという避けられない考えがあります。これが悪い考えであることを除けば（このコメントの最初の4段落を参照）、それはまだ互換性がありません。なぜなら、setup_themeフックまでは、スタイルシートとテンプレートの値をフィルタリングすることによってどのテーマをロードするかをオーバーライドできるからです。
残念なことに、これはWordPressがどのように設計されているかを考えると借用できないだけです。良いことは、それを行うには無数の（より良い）方法があるということです。
（もともとここに投稿された： http://core.trac.wordpress.org/ticket/2479#comment:5 ）
一回限りのプロジェクトでは、必用コードをmu-pluginsにドロップすることが絶対に適切です。 「一箇所にまとめて配置する」ことが問題になる場合は、テーマ内のシンボリックリンクをmu-pluginsドロップインに直接変更するだけで、テーマディレクトリを検索するときに表示されます。
ロードシーケンスの早すぎる、これを達成する方法を考えることはできません。
最も適切な解決策はwp-config.phpにカスタムインクルードを追加すること（コードまたはユーザに要求）ですが、そのバンドルプラグインと比較するとおそらくもっと意味があるでしょう。