そのために定数を使用しないでください。グローバル定数は使用しないでください。
定数には、クラス/インターフェース定数とグローバル定数の2種類があります。
クラスまたはインターフェースの定数は問題なく、場合によっては役立ちます。過度に単純化した例:
interface Requirements
{
const MIN_PHP_VERSION = 5.4;
public function php_is_good();
}
class Theme_Requirements implements Requirements
{
public function php_is_good()
{
return version_compare( PHP_VERSION, self::MIN_PHP_VERSION, '>=' );
}
}
ただし、これらの定数は常に公開されていることに注意してください。それらを後で変更すると、それらに依存するコードが壊れる可能性があります。
これはグローバル定数の場合はさらに悪くなります。以下を想像してみてください:
define( 'THEME_URI', get_template_directory_uri() );
そして、デフォルトのヘッダー画像の関数:
function get_default_header_image()
{
return THEME_URI . '/img/default-header.jpg';
}
この関数は、制御できないものについての仮定を行います。定数のさまざまな値でその関数をどのようにテストしますか?できません。
定数が存在しないディレクトリまたは別の低速サーバーに設定されている場合に何が起こるかをテストするとします。ただし、定数を定義すると、その値を変更することはできません。すべてのテストを一気に実行することはできません。これにより、テストが必要以上に難しくなります。
そして、独自のデフォルト画像を使おうとする子テーマで、どのようにそれを実装しますか?定数は、親テーマによって設定されます。を使用してチェックを追加することもできますがdefined()
、その場合、その値が実際にどこに書き込まれたかを確認することが難しくなります。
関数を次のように書き直したほうがよいでしょう。
function get_default_header_image( $base )
{
return esc_url( $base ) '/img/default-header.jpg';
}
前に言ったように、定数はAPIです。APIは簡単に変更できるはずですが、PHPはアクセスをログに記録しないため、定数を廃止することは本当に困難です。そのため、ソースコードやドキュメントを非常に注意深く読んだ場合を除いて、非推奨メッセージが他の開発者に届くことはありません。私を信じてください、彼らはそうではありません。
get_stylesheet_directory_uri()
子テーマとget_template_directory_uri()
親テーマで使用します。どちらも実行時にフィルタリングできるため、すべてのテストを一度に実行できます。