名前の衝突を避ける

名前の衝突は、プラグインが他のプラグインと同じ名前の変数、関数、またはクラスを使用しているときに発生します。

幸いなことに、以下の方法を使用することで名前の衝突を避けることができます。

手続き型コーディング方法

デフォルトでは、すべての変数、関数、クラスはグローバル名前空間で定義されており、これはプラグインが他のプラグインによって設定された変数、関数、クラスを上書きする可能性があることを意味します。関数やクラスの内部で定義された変数は影響を受けません。

すべてにプレフィックスを付ける

すべてのグローバルにアクセス可能なコードにはユニークな識別子をプレフィックスとして付けるべきです。プレフィックスは他のプラグインとの競合を防ぎ、変数を上書きしたり、関数やクラスを誤って呼び出したりするのを防ぎます。

他のプラグインとの競合を防ぐために、プレフィックスは少なくとも4文字以上であるべきですが、5文字を推奨します。一般的な英単語の使用は避け、代わりにプラグインに特有の何かを選んでください。WordPress.orgだけでも数万のプラグインをホストしています。私たちのサーバーの外にはさらに数十万のプラグインがあります。競合に遭遇することは避けられません。

これを行う良い方法はプレフィックスを使用することです。たとえば、プラグインが「Easy Custom Post Types」と呼ばれている場合、次のような名前を使用できます：

  • function ecpt_save_post()
  • define( ‘ECPT_LICENSE’, true );
  • class ECPT_Admin{}
  • namespace EasyCustomPostTypes;
  • update_option( 'ecpt_settings', $settings );

WordPressプロジェクトの一部としてコードを作成しているため、コアWordPressと競合する可能性の高いプレフィックスの使用を避ける必要があります。これには、`````（ダブルアンダースコア）、wp、WordPress、または`````（シングルアンダースコア）が含まれますが、これに限定されません。

「サブ」プラグイン（たとえば、WooCommerce拡張）用のコードを作成している場合、彼らの通常の/一般的なプレフィックス（つまり、Woo、WooCommerce）の使用も避ける必要があります。

クラスや名前空間の内部で使用することはできますが、スタンドアロンの関数/名前空間/クラスとしては使用できません。

翻訳のために_n()や()を使用している場合、それは問題ありません。私たちはあなたが作成したプラグインのための関数についてのみ話しています。WordPressのコア機能ではありません。実際、これらのコア機能があるからこそ、あなた自身のプラグインでこれらのプレフィックスを使用しない必要があるのです！ユーザーのためにWordPressを壊したくはないでしょう。

覚えておいてください：良いプレフィックス名はあなたのプラグインに特有で独自のものです。これにより、デバッグ時にあなた自身と次の人を助け、競合を防ぐことができます。

プレフィックスを付ける必要があるコードには以下が含まれます：

  • 関数（名前空間がない場合）
  • クラス、インターフェース、トレイト（名前空間がない場合）
  • 名前空間
  • グローバル変数
  • オプションとトランジエント

既存の実装を確認する

PHPは、変数、関数、クラス、および定数の存在を確認するためのいくつかの関数を提供しています。これらはすべて、エンティティが存在する場合にtrueを返します。

すべての関数やクラスの周りに(!function_exists(‘NAME ‘)) {を使用することは素晴らしいアイデアのように思えますが、致命的な欠陥に気づくまでです。同じ名前の関数を持つ他の何かがあり、そのコードが最初に読み込まれると、あなたのプラグインは壊れます。関数やクラスを置き換えたり上書きしたりするためにif-existsを使用するのは、共有ライブラリのみに留めるべきです。

例

  1. // Create a function called "wporg_init" if it doesn't already exist
  2. if ( ! function_exists( 'wporg_init' ) ) {
  3.    function wporg_init() {
  4.    register_setting( 'wporg_settings', 'wporg_option_foo' );
  5.    }
  6. }
  8. // Create a function called "wporg_get_foo" if it doesn't already exist
  9. if ( ! function_exists( 'wporg_get_foo' ) ) {
  10.    function wporg_get_foo() {
  11.    return get_option( 'wporg_option_foo' );
  12.    }
  13. }

オブジェクト指向プログラミング方法

名前の衝突の問題に対処する簡単な方法は、プラグインのコードにクラスを使用することです。

使用したいクラスの名前がすでに使用されているかどうかを確認する必要がありますが、残りはPHPが処理します。

例

  1. if ( ! class_exists( 'WPOrg_Plugin' ) ) {
  2.    class WPOrg_Plugin {
  3.    public static function init() {
  4.    register_setting( 'wporg_settings', 'wporg_option_foo' );
  5.    }
  7.    public static function get_foo() {
  8.    return get_option( 'wporg_option_foo' );
  9.    }
  10.    }
  12.    WPOrg_Plugin::init();
  13.    WPOrg_Plugin::get_foo();
  14. }

ファイルの整理

プラグインディレクトリのルートレベルには、plugin-name.phpファイルと、オプションでuninstall.phpファイルを含めるべきです。他のすべてのファイルは、可能な限りサブフォルダに整理するべきです。

フォルダ構造

明確なフォルダ構造は、あなたや他のプラグインに関わる人々が類似のファイルを一緒に保つのに役立ちます。

参考のためのサンプルフォルダ構造は次のとおりです： 

  1. /plugin-name
  2.    plugin-name.php
  3.    uninstall.php
  4.    /languages
  5.    /includes
  6.    /admin
  7.    /js
  8.    /css
  9.    /images
  10.    /public
  11.    /js
  12.    /css
  13.    /images

プラグインアーキテクチャ

プラグインのために選択するアーキテクチャ、またはコードの組織は、プラグインのサイズに依存する可能性があります。

WordPressコア、テーマ、または他のプラグインとの相互作用が限られている小さな単目的プラグインの場合、複雑なクラスを設計する利点はほとんどありません。プラグインが後で大きく拡張されることがわかっている場合を除いて。

多くのコードを持つ大規模なプラグインの場合、最初からクラスを念頭に置いて始めてください。スタイルとスクリプトファイルを分け、ビルド関連のファイルも分けてください。これにより、コードの整理とプラグインの長期的なメンテナンスが助けられます。

条件付き読み込み

管理コードを公開コードから分離することは役立ちます。条件付きis_admin()を使用してください。ユーザーが認証されているか、管理者レベルのアクセス権を持っているかを示すものではないため、能力チェックを実行する必要があります。ユーザーの能力の確認を参照してください。

たとえば： 

  1. if ( is_admin() ) {
  2.    // we are in admin mode
  3.    require_once __DIR__ . '/admin/plugin-name-admin.php';
  4. }

直接ファイルアクセスを避ける

セキュリティ対策として、ABSPATHグローバルが定義されていない場合はアクセスを許可しないのが良い習慣です。これは、クラスや関数の定義の外にコードを含むファイルにのみ適用されます。たとえば、メインプラグインファイルなどです。

これを実装するには、ファイルの先頭にこのコードを含めます： 

  1. if ( ! defined( 'ABSPATH' ) ) {
  2.     exit; // Exit if accessed directly
  3. }

アーキテクチャパターン

可能なアーキテクチャパターンはいくつかありますが、大きく分けて3つのバリエーションに分類できます：

アーキテクチャパターンの説明

上記のより複雑なコード組織の具体的な実装は、すでにチュートリアルやスライドとして書かれています：

ボイラープレートの出発点

新しいプラグインを書くたびにゼロから始めるのではなく、ボイラープレートから始めることを検討しても良いでしょう。ボイラープレートを使用する利点の1つは、自分のプラグイン間で一貫性を持たせることです。ボイラープレートを使用すると、他の人がすでに慣れているボイラープレートを使用する場合、コードへの貢献が容易になります。

これらはまた、異なるが比較可能なアーキテクチャのさらなる例としても機能します。

もちろん、これらや他のものの異なる側面を取り入れて、自分自身のカスタムボイラープレートを作成することもできます。