web-dev-qa-db-ja.com

自分のプラグイン間の共通機能

私は、新しい投稿タイプを作成するとき、設定ページを作成するとき、そして新しい分類法を作成するときに、プラグインを作成する必要があることを読みました。だから私はそれをやりました。しかし、私は自分のプラグインの中に汎用化されている可能性のある、あるいは同一の機能を持っています。この例はデータベースに保存する機能です。 PHPにそのようなものがある場合、すべてがグローバルスコープに含まれるように思われるので、私たちは共有機能を持つ別のプラグインを作成するべきですか、それともfunctions.phpファイルに共有機能を入れるべきですか？

pluginsplugin-developmentfunctions
4
ptf

1。

まず第一にfunctions.phpはテーマ用であり、プラグインとは異なるものです。

WordPressでは、テーマを使用する必要があります プレゼンテーションのみ、機能のプラグイン 。

必要に応じて機能のためにテーマを使用できますが、使用しないでください。実際、テーマとプラグインはphpファイルであり、WordPressリクエストの特定の瞬間にロードされます。 （WordPressは、テーマ用のfunctions.phpとプラグイン用のメインプラグインファイルの1つのファイルのみを読み込み、必要な他のすべてのファイルを読み込みます）。

問題は、WordPressでは、プラグインの数に制限はありませんが、テーマは1つしか持てないことです。したがって、テーマを変更したい場合にfunctions.phpの機能を使用すると、失われます。つまり、機能をプラグインに配置し、プレゼンテーションのみにテーマを使用する方が良い理由です。

2。

はい、WordPressコアのすべてがグローバルネームスペースにあり、グローバル変数の大規模な使用がありますが、それはコアであり、同じルールに従うように強制する人はいません。ネームスペースを使用できます（PHPバージョンは5.3+）であり、グローバル変数も使用しません。WordPressプラグインをロードすると、PHPファイルがロードされるため、バージョンを指定することは何でもできます。 PHPの機能：必要に応じて、すべての機能を自分で記述できますが、それは意味がありません。すべての機能があるため、WordPressを使用します。必要なものがコアでカバーされている場合は関数/クラスを使用しますが、PHPがしないことを行うWordPressコードを自由に記述してください。そして、それを行うには、あなたが知っているPHPテクニックを自由に使用してください。

3。

あなたの質問を読みます

この例は、データベースに保存する関数です

データベースに保存する内容とその理由はわかりませんが、WordPressentities：post、taxonomy terms、meta、options、ユーザー、一時的な... WordPressには、すべてのデータベースを保存および取得する関数が既にあるため、そのためのカスタム関数を記述する必要はありません。 カスタムテーブル を意味する場合

  • WordPressでカスタムテーブルを使用すると便利な場合がありますが、アプリケーションに必要なカスタムテーブルが多すぎる場合は、おそらくWordPressが適切な基盤ではないため、非常に素晴らしいフレームワークがあります（ Symphony 、 Laravel 、 Sylex など）
  • カスタム機能を作成する前に、利用可能な巨大なWordPressプラグインを見てください。おそらく、必要なことをすでに実行しているプラ​​グインがあります
  • カスタムWordPress機能を作成する場合、スタンドアロンアプリケーションではないことに注意してください。これはWordPress内で他のテーマやプラグインとともに使用されるため、アプリケーションの健全性を維持するためにいくつかの共存規則に従います。例えば特定のタスクには正しいフックを使用します。または、特定のタスクについて何かを言うために、カスタムテーブルを作成する必要がある場合は、 db_delta を使用します
  • ある機能のためだけにプラグインを作成することは良い考えだとは思いません。別のプラグインを使用するには少し手間がかかり、1つの機能のためだけに価値はありません。プラグインで使用するsome汎用関数がある場合は、それらすべてを含むプラグインを作成することもできます...

4。

次に、プラグインから別のプラグインに共通の機能を抽出する方法について説明します。はい、それは実行可能であり、私見では、それは完全に公平です。異なる方法があります：

4.1：異なるプラグインを作成してすべてインストールする

既に述べたように、プラグインはWordPress bootstrapの特定の時間にrequire_onceを使用してロードされるphpファイルです。したがって、実際には2つのプラグインがインストールされると、 2つのファイルが同じプラグインにあり、自分でロードした場合、または2つのファイルがWordPressによってロードされた場合の違いはありません。どのファイルが最初に読み込まれ、どのファイルが後で読み込まれるかはわかりませんが、WordPressフックのおかげで、すべてのプラグインが読み込まれたことがわかり、その時点から処理を開始できます。もちろん、別のプラグインに配置された機能を使用する前に、プラグイン/機能が利用可能であることを確認してください。概念実証コード：

// plugin-one.php

namespace PluginOne

class Foo {
  function do_something () {
    return 'Foo!';
  }
}

// plugin-two.php

namespace PluginTwo

class Bar {
  function do_something ( PluginOne\Foo $foo ) {
     echo $foo->do_something();
  }
}

add_action('plugins_loaded', function() { 
  // when WordPress fires 'plugins_loaded' all plugin files are required
  // so we can check if the class PluginOne\Foo exists and use it
  if ( class_exists( 'PluginOne\Foo' ) ) {
    $bar = new Bar;
    $bar->do_something( new PluginOne\Foo );
  }
});

4.2：作曲家

Composer について使用/聞いたことがあるかどうかはわかりません。これは、依存関係管理ツールです。

別のプラグインを必要とするプラグインを作成する必要がある場合、両方がComposerをサポートしている場合、すべてのことはcomposer.jsonファイルに行を追加するだけです。

プラグインにComposerを使用する方法は複雑ではありませんが、ここで答えるには複雑すぎます。

最近数か月でComposerへの関心はWordPressコミュニティで育ちました（PHPコミュニティでは少し前に育ちました）。 。外観を開始 composer.rarst.net 、それは Rarst 、oneによって共有されるリソースですこのサイトの改造の。

6
gmazzap