web-dev-qa-db-ja.com

WordPressのプラグインとテーマのオートロードと名前空間：うまくいくか？

誰かがプラグインやテーマの中で オートロード やPHP名前空間を使っていませんか

それらを使うことについての考え？害はありますか？落とし穴？

注：名前空間はPHP 5.3以降のみです。この質問では、PHP 5.3以上を持っていることがわかっているサーバーを扱うことになるでしょう。

plugin-developmenttheme-development
69
chrisguitarguy

さて、私は名前空間とオートロードに頼るのに十分なサーバーを制御していた2つの大きなプロジェクトを持っていました。

まずは。オートロードは素晴らしいです。 requireを心配しないことは比較的良いことです。

これが私がいくつかのプロジェクトで使ってきたローダーです。最初にクラスが現在のネームスペースにあることを確認し、そうでない場合は保釈します。そこから、クラスを見つけるための単なる文字列操作です。

<?php
spl_autoload_register(__NAMESPACE__ . '\\autoload');
function autoload($cls)
{
    $cls = ltrim($cls, '\\');
    if(strpos($cls, __NAMESPACE__) !== 0)
        return;

    $cls = str_replace(__NAMESPACE__, '', $cls);

    $path = PLUGIN_PATH_PATH . 'inc' . 
        str_replace('\\', DIRECTORY_SEPARATOR, $cls) . '.php';

    require_once($path);
}

名前空間なしで使用するためにこれを容易に適合させることができます。プラグイン/テーマのクラスに統一して接頭辞を付けると仮定すると、その接頭辞をテストするだけで済みます。次に、クラス名にアンダースコアを使用してディレクトリ区切り文字のプレースホルダとして使用します。たくさんのクラスを使っているのであれば、おそらくある種のクラスマップオートローダを使いたくなるでしょう。

名前空間とフック

WordPressのフックシステムは call_user_func （およびcall_user_func_array）を使用して機能します。これは、関数名を文字列として取り、do_action（およびその後call_user_func）関数呼び出しが行われたときに呼び出します。

名前空間では、名前空間を含む完全修飾関数名をフックに渡す必要があります。

<?php
namespace WPSE\SomeNameSpace;

add_filter('some_filter', 'WPSE\\SomeNameSpace\\the_function');
function the_function()
{
   return 'did stuff';
}

あなたがこれをしたいならば、おそらく__NAMESPACE__マジック定数を自由に使用するほうがよいでしょう。

<?php
namespace WPSE\SomeNameSpace;

add_filter('some_filter', __NAMESPACE__ . '\\the_function');
function the_function()
{
   return 'did stuff';
}

あなたがいつもあなたのフックをクラスに入れるならば、それはより簡単です。クラスの標準的なcreateインスタンスと$thisを持つコンストラクタ内のすべてのフックは問題なく動作します。

<?php
namespace WPSE\SomeNameSpace;

new Plugin;

class Plugin
{
    function __construct()
    {
        add_action('plugins_loaded', array($this, 'loaded'));
    }

    function loaded()
    {
        // this works!
    }
}

私のように静的メソッドを使用する場合は、配列の最初の引数として完全修飾クラス名を渡す必要があります。これは大変な作業ですので、__CLASS__という定数かget_classという魔法を使うことができます。

<?php
namespace WPSE\SomeNameSpace;

Plugin::init();

class Plugin
{
    public static function init()
    {
        add_action('plugins_loaded', array(__CLASS__, 'loaded'));
        // OR: add_action('plugins_loaded', array(get_class(), 'loaded'));
    }

    public static function loaded()
    {
        // this works!
    }
}

コアクラスの使用

PHPのクラス名解決は少し不思議です。コアWPクラス（以下の例ではWP_Widget）を使うつもりなら、useステートメントを提供しなければなりません。

use \WP_Widget;

class MyWidget extends WP_Widget
{
   // ...
}

あるいは、完全修飾クラス名を使用することもできます - 基本的には単にバックスラッシュを付けるだけです。

<?php
namespace WPSE\SomeNameSpace;

class MyWidget extends \WP_Widget
{
   // ...
}

定義する

これはより一般的なPHPですが、私にはちょっと気になりました。

あなたのプラグインへのパスのように、あなたがよく使うものを定義したいと思うかもしれません。 defineステートメントを使用すると、defineの最初の引数に明示的にネームスペースを渡さない限り、ルートネームスペースにものが入ります。

<?php
namespace WPSE\SomeNameSpace;

// root namespace
define('WPSE_63668_PATH', plugin_dir_path(__FILE__));

// in the current namespace
define(__NAMESPACE__ . '\\PATH', plugin_dir_path(__FILE__));

PHP 5.3 plusを使用して、ファイルのルートレベルでconstキーワードを使用することもできます。 constsは常に現在のネームスペース内にありますが、defineを呼び出すよりも柔軟性が劣ります。

<?php
namespace WPSE\SomeNameSpace;

// in the current namespace
const MY_CONST = 1;

// this won't work!
const MY_PATH = plugin_dir_path(__FILE__);

あなたが持っているかもしれない他のどんなヒントも追加してください。

87
chrisguitarguy

これが2017年の回答です。

オートロードは素晴らしいです。名前空間は素晴らしいです。

あなたはそれを自分でロールバックすることができますが、2017年にあなたのPHP要件を処理するために壮大でどこにでもある Composer を使うのが最も理にかなっています。 Composerは PSR-0 と PSR-4 オートロードの両方をサポートしますが、前者は2014年以降廃止予定であるため、PSR-4を使用してください。それはあなたのディレクトリの複雑さを軽減します。

それぞれのプラグイン/テーマをそれぞれ独自のGithubリポジトリに保存し、それぞれ独自のcomposer.jsonファイルとcomposer.lockファイルを持ちます。

これがプラグインに使用するディレクトリ構造です。 （awesome-pluginという名前のプラグインは実際にはありませんが、そうするべきです。）

plugins/awesome-plugin/bootstrap.php
plugins/awesome-plugin/composer.json
plugins/awesome-plugin/composer.lock
plugins/awesome-plugin/awesome-plugin.php
plugins/awesome-plugin/src/*

plugins/awesome-plugin/vendor/autoload.php
plugins/awesome-plugin/vendor/*

適切なcomposer.jsonファイルを提供すると、Composerはここでネームスペースとオートロードを処理します。

{
    "name": "awesome-company/awesome-plugin",
    "description": "Wordpress plugin for AwesomeCompany website, providing awesome functionality.",
    "type": "wordpress-plugin",
    "autoload": {
        "psr-4": {
            "AwesomeCompany\\Plugins\\AwesomePlugin\\": "src"
        }
    }
}

composer installを実行すると、vendorディレクトリとvendor/autoload.phpファイルが作成されます。これにより、src/内のすべてのネームスペースファイル、およびその他の必要なライブラリが自動ロードされます。

それからメインのプラグインファイル（私たちにとってはawesome-plugin.phpです）の一番上に、あなたのプラグインメタデータの後に、あなたは単に必要です：

// Composer autoloading.
require_once __DIR__ . '/vendor/autoload.php';

...

ボーナス機能

必須ではありませんが、最初からComposerを使用するには、 Bedrock Wordpressの定型句を使用します。それから、Composerを使用して、上記で作成した独自のプラグインを含め、Composer経由で必要なプラグインを組み立てることができます。さらに、 WPackagist のおかげで、Wordpress.orgの他のプラグインが必要になります（以下のcool-themeとcool-pluginの例を参照）。

{
  "name": "awesome-company/awesome-website",
  "type": "project",
  "license": "proprietary",
  "description": "WordPress boilerplate with modern development tools, easier configuration, and an improved folder structure",
  "config": {
    "preferred-install": "dist"
  },
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org"
    },
    { // Tells Composer to look for our proprietary Awesome Plugin here.
        "url": "https://github.com/awesome-company/awesome-plugin.git",
        "type": "git"
    }
  ],
  "require": {
    "php": ">=5.5",
    "awesome-company/awesome-plugin": "dev-production", // Our plugin!
    "wpackagist-plugin/cool-plugin": "dev-trunk",       // Someone else' plugin
    "wpackagist-theme/cool-theme": "dev-trunk",         // Someone else' theme
    "composer/installers": "~1.2.0",     // Bedrock default
    "vlucas/phpdotenv": "^2.0.1",        // Bedrock default
    "johnpbloch/wordpress": "4.7.5",     // Bedrock default
    "oscarotero/env": "^1.0",            // Bedrock default
    "roots/wp-password-bcrypt": "1.0.0"  // Bedrock default
  },
  "extra": {
    // This is the magic that drops packages with the correct TYPE in the correct location. 
    "installer-paths": {
      "web/app/mu-plugins/{$name}/": ["type:wordpress-muplugin"],
      "web/app/plugins/{$name}/": ["type:wordpress-plugin"],
      "web/app/themes/{$name}/": ["type:wordpress-theme"]
    },
    "wordpress-install-dir": "web/wp"
  },
  "scripts": {
    "test": [
      "vendor/bin/phpcs"
    ]
  }
}

注1：コメントはJSONでは無効ですが、わかりやすくするために上記のファイルに注釈を付けました。

注2：簡潔にするため、定型的なBedrockファイルの一部を切り取っています。

注3：最初のcomposer.jsonファイルのtypeフィールドが重要なのはこのためです。 Composerは自動的にそれをweb/app/pluginsディレクトリにドロップします。

13
haz

私はオートロードを使用しています（私のプラグインにはクラスの負荷があります - これにはTwigが含まれているためもあります）が、私の注意を引く問題はありませんでした。

あなたが名前空間をサポートしないphpインストールを使用する必要がこれまでにないと確信しているならば、再びあなたは大丈夫です（現在のワードプレスのブログの70％は名前空間をサポートしていません）。注意すべき点がいくつかあります。

私は覚えているようですが、通常のphpでは名前空間は大文字と小文字を区別しませんが、iisでfastcgi phpを使用する場合です。

また、現在開発中のコードが> 5.3.0でしか使用されないと確信している場合でも、それほど豪華ではないプロジェクトでコードを再利用することはできません - それが私がしていない主な理由です。内部プロジェクトで名前空間を使用しました。私は、名前空間が that を追加しないことを発見しました。それらへの依存関係を削除しなければならないという頭痛の種と比較した場合。

4
Daniel Chatfield