This post is also available in: 日本語 (Japanese)
この記事は WooCommerce 開発者ブログの「Deprecation in WooCommerce Core」を日本語訳したものです。
ここから=================
非推奨とは、後方互換性を損なうことなく、またはその使用を完全に禁止することなく、機能の使用を阻止する方法、または実践する方法です。以下はWikipedia の Deprecationから引用しました。
廃止されたソフトウェア機能はソフトウェアに残っていますが、代わりの機能を推奨する警告メッセージが表示されることがあります。 廃止予定ステータスは、将来その機能が削除されることを示す場合もあります。 機能は直ちに削除されるのではなく、旧バージョンとの互換性を提供し、影響を受けたコードを新しい標準に準拠させるための時間をプログラマに与えるために推奨されています。
関数、メソッド、または機能が推奨されない理由はさまざまです。 いくつか例を挙げると:
- もう使用しない関数を削除したいかもしれません。
- 関数の動作方法を変更したり改良したりすることもできますが、後方互換性を損なうため、古い関数を廃止する必要があります。
- 命名規則を標準化する必要があるかもしれません。
- 同様の機能をマージして、異なる場所で同じコードを再利用しないようにする機会があります。
WooCommerce 2.7 では、新しい CRUD システムのおかげで、かなり非推奨を行っています。可能であれば、開発者に新しいCRUDオブジェクトを使用させたいが、開発者が移行する時間があるように、データにアクセスする従来の方法を壊したくない。
WooCommerce の古いバージョンと最新バージョンをサポートする必要があるため、拡張機能の更新プロセスが難しくなる可能性があることを最初から理解していますが、通知は理想的ではなく、魅力的ではないことを強調したい。
店主への警告: 廃止予定の警告は店舗が壊れていることを意味するものではなく、単にコードを更新する必要があることを通知するものです。
どのように機能を非推奨するのですか?
WooCommerce では何かを非推奨にするときは、開発者に明確にし、下位互換性を維持するためにいくつかの措置を講じます。
- 関数/メソッドに docblock を追加して、その関数が非推奨となったバージョンを示します。 例えば
@deprecated 2.x.x
- 我々は、どのバージョン、どのような機能、どのような置換えが利用可能であるかを示す独自の
wc_deprecated_function
関数を使用して警告通知を追加します。 それ以上のことは少しあります。 - コードベース全体で非推奨の関数の使用法を削除します。
関数またはメソッド自体はコードベースから削除されません。 これにより、削除されるまで下位互換性が維持されます(通常、1年以上、または将来の主要リリースがいくつかあります)。
私は上記の wc_deprecated_function
について言及しました。これは _deprecated_function
WordPress 関数の独自のラッパーです。 これは、AJAXイベント中の WP_DEBUG
モードに関係なく、表示の代わりにログエントリを強制し、AJAX要求が通知の結果として破られないことを除いて、非常によく似ています。
非推奨の関数が呼び出されたらどうなりますか?
拡張機能やテーマで廃止予定の関数が使用されている場合は、次のような警告が表示されることがあります。
注意:バージョン2.1以降、 woocommerce_show_messages は非推奨です! 代わりに wc_print_notices を使用してください。 /srv/www/wordpress-default/wp-includes/functions.php on line 3783
これは非推奨にされているもの、いつ、どこで、どのような置換が利用可能であるかを示します。
通知と警告は通常インラインで表示されますが、それらを収集するために使用できるプラグインがいくつかあり、サイトのフッターにうまく表示されています。 個人的には、私は Query Monitor を使用します。
本番環境での警告(店主がこれを読んでいます!)
PHPの通知と警告(またはそれに関するエラー)を表示することは、プロダクションストアではお勧めできません。 悪意のあるユーザーが使用できる設定に関する情報を表示できます。 それらがパブリックビューから隠され、必要に応じてログに記録されるようにしてください。
WordPress では、 wp-config.php
ファイルのいくつかの定数を追加または変更することでこれを行うことができます。
define( 'WP_DEBUG', false );
一部のホストでは、ホスト設定のためにエラーが引き続き表示されることがあります。 それらを強制的に表示しないようにするには、これもあなたの wp-config.php
ファイルに追加することができます:
@ini_set( 'display_errors', 0 );
通知を表示する代わりにログに記録するには、次のようにします。
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
WordPress エラーログのデフォルトの場所は wp-content/debug.log
です。
開発者としての非推奨の扱い
単に最新のバージョンをサポートし、廃止予定のコードを直ちに削除するのは良いことですが、これはしばしば不可能です(個人的にプラグインを作成している場合を除きます)。 完璧な世界では、WordPressにはバージョン管理システムがあります。これにより、あなた自身のプラグインのどのバージョンXバージョンがサポートされ、WordPressが適切なバージョンがインストールされているかを定義できます。 悲しいかな、このメカニズムは存在しないので、近づいていくことは少し難しいかもしれません。
したがって、あなたが提供しているプラグインのタイプによって、廃止予定に対するあなたのアプローチは異なる場合があります。
基本的な例としては、 function_exists
と method_existscalls
を使用して条件付きでコードを実行する方法があります(インストールされているバージョンの検出よりも優先されます)。
たとえば、CRUD アップデートでは、使用していた製品 ID を取得していたとします。
$id = $product->id;
2.7で警告が表示されるので、これを次のように交換することができます:
if ( method_exists( $product, 'get_id' ) ) { $id = $product->get_id(); } else { $id = $product->id; }
簡潔にするために:
$id = method_exists( $product, 'get_id' ) ? $product->get_id() : $product->id;
これは可能な限りIDを取得する最新の方法を使用します。 あなたが上記のロジックの多くをしたプラグインを持っていたなら、あなたは次のようないくつかの他のアプローチを使うことができます:
- 利用可能なものに基づいて正しい値を返すように、コード内にラッパー関数を持つ。
- バージョンに基づいて異なるファイルやクラスを持つので、サポートが簡単に削除されたときに削除できます。
- プラグインがミッションクリティカルでない場合は、最小バージョンが2.7未満の場合はカスタム機能を無効にし、アップグレード前に警告を表示します。
実行されているバージョンを知りたいシナリオを実行する場合は、定数とバージョンの比較を使用できます。
if ( version_compare( WC_VERSION, '2.7', '<' ) ) { // Older than 2.7 } else { // 2.7+ }
私たちは今後数週間、私たちが独自の拡張機能をどのように更新しているかを示す例を掲示します。 乞うご期待!
Comments